what ignorant bile. You are showing a creator() most EJB code is about FINDERS. What an ignorant pig. We are talking about BEGINNER stuff here, not even that complex. Oh I get it, it is because ioc shit only deals with singletons and stateless stuff.

say don’t hold your breath. When they do I might reconsider my current position on EJB.

after pooping your pants like this I wouldn’t run around talking about big boy stuff like EJB.

someone set us up the J4EE patent

we get signal

main SCO turn on

we have two ‘j2ee’ classes exluding the servlets and jsps at the front end. one is a stateless bean and the other is it’s service locator.

the only other part that need manual maintainence are the domain objects, the pojo objects that perform operations on same. the transfer objects are generated from schemas with castor.

so we have ONE “ejb” class to maintain. which is a little plumbing (more than 8 lines) but it’s code that would have to be repeated no matter what the layer. and what gives us declarative transactions, proxies and pooling and distributed execution better than a j2ee container?

That’s creating a new instance though, isn’t it? How do I hook up with an existing component instance? You’re not suggesting every time I need to use a distributed object I have to create a new instance of it, so how does one find the existing pool that someone created in .NET if there’s no lookup involved? How do you differentiate between creating and finding?

> Oh, and your “8 line EJB” is not complete. You
> also need at least two more interfaces

Well he said the rest is metatags. Can only assume this means XDoclet, EJBGen or such. Tags work for both .NET and J2EE (it’s not in the J2EE spec but then there isn’t a spec of “light weight containers” either, and the .NET with its single vendor implementation leaves a lot to be desired).

Attributes like scalability and maintainability are measurable. Show a single large production site using the new “light weight containers” and go after them and ask for data.

As for your point on locking strategies — well what do you expect if you move between two implementations that must implement features not in the spec. Are you claiming I can port from one “light weight container” implementation to another without having to deal with these problems? I’d like to see that! Or are you claiming I can port from one .NET implementation to another without having to deal with the exact same issues? I’d like to see that too.

So far you’ve provided nothing that convinces me your “lightweight container” or POJO strategies solves any of these problems. It is easy to criticize J2EE spec but you’d be a lot more convincing if you’d actually provided some answers to the points you complain about.

The place that makes blogs look good.

There is marked improvement from EJB 1.0
to EJB 2.0, from JSP 1.0 to JSP 2.0 and so on.

Let’s not give up on these guys yet - they’ve
shown the ability to adjust based on user
feedback.

Linards,
your post makes me happy–reminding me that I will always have a job.

First, I take it english isn’t your first language–can’t hold that against you, but you should try harder.

Second, that’s what you get for letting wizards and tools design your app for you.

Try reading the spec. Then read a J2EE patterns book. Once you understand both, then perhaps you’ll understand why you look like a retard right now.

Yes, attributes are in JDK 1.5, but how long time will it take until they become part of J2EE? How long time before we won’t have to create the stupid home/remote-interfaces? I’d say don’t hold your breath. When they do I might reconsider my current position on EJB.

Oh, and your “8 line EJB” is not complete. You also need at least two more interfaces (and remember your actual bean is *not* allowed to implement the interfaces, noooo, that would be much to compile-time safe for the poor J2EE developer, he might be confused by the compiler errors and by the smart intentions in IDEA).

Riiight… You can use all sorts of clever hacks to work around some of the limitations. You can use XDoclet to generate that for you. That’s all smells for an underlying technology simply not up to the test.

Proof!? How can you *prove* anything in this business? We don’t even know what productivity *is*. Prove to me how EJB is better than not using it.

You managed to create a portable scaleable system with EJB? How did you manage to working around the completely different locking strategies that WebSphere and WebLogic uses (without falling down to non-portable extensions). The different pooling srategies, threading behaviour.

I’m not sure… But it sounds like you’re the one who hasn’t tried to implement a really scaleable system with EJB.

JSR-175 is in 1.5 if I recall, so your calls for progress have been taken a note of long time ago.

Yes and your POJO system serving 20 users was more portable (hah!), more scalable (sure!), and more maintanable (yeah if you are the single developer). Sure, we all buy that. Why don’t you come up with some concrete evidence to prove it. Show they’re for real and maybe people would actually take this POJO stuff seriously.

Well, for example using it:
Context ctx = new InitialContext();
J2EEObjectHome home = PortableRemoteObject.narrow(J2EEObjectHome.class, ctx.lookup(”someJndiName”)); // (where do I get the JNDI name from? I can’t even remember!)
J2EEObject o = home.create();
o.doSomething();

In C#:
new DotNetObject().DoSomething(); // only problem: ugly upper case on method name

Setting up declarative transaction:

In C#:
[Transaction(TransactionOption.Required)]
public class DotNetObject : ServicedComponent

Or setting up pooling:

In C#
[ObjectPooling(MinPoolSize=1, MaxPoolSize=100, CreationTimeOut=30)]
public class DotNetObject : ServicedComponent

I know that you can get around some of the limitations with XDoclet but in DotNet all that is built into the standard as a *supported* way of building components. Besides wasn’t Hanis point that you should *not* base your code on some cutting edge fuckwits spastic convolusions in front of a keyboard? (If you look at the XDoclet 1 codebase, that’s more or less what it is.)

Don’t get me wrong here, I love Java and J2EE, but the EJB mess really is completely pointless.

Now I’ve not even talked about whether you really need all that stuff from the start. I’ve built quite a few EJB-based systems in my days, and I’ve built quite a few “POJO” ones too. Guess which ones where more stable, portable, scalable, understandable, maintainable? The EJB system? Pfft, guess again.

And no, don’t ask me to format it. The rest is either meta tags or your component logic. Pretty simple. We have callbacks (look, its an IoC container!!!) for creation, removal, activation, passivation and per invocation context. What’s so damn difficult about it?