Noel wrote: >>>And I reiterate my suggestion that Avalon adopt JSR 77 and JSR 88 as >>>interfaces to be supported by our server-class container(s).
I wrote: >>I have no idea what those are :D.
Then he wrote: > Essentially, they are container methods standardized in JSRs. Geronimo > is based upon those JSRs as the primary interface between their > "kernel" and managed components.
I found some basic overviews:
* http://www.javaworld.com/javaworld/jw-06-2002/jw-0614-mgmt.html (JSR 77) * http://ishmael.forge.objectweb.org/ishmael-overview.pdf (JSR 88)
IMHO, that is *many* steps back from what avalon provides.
Particularly unimpressive is the JSR 77 functionality that roughly maps onto the avalon context/service manager:
// access the 'service manager' (1)
Context ctx = new InitialContext();
Object objref = ctx.lookup("ejb/mgmt/MEJB");
ManagementHome home = (ManagementHome)
PortableRemoteObject.narrow(objref,ManagementHome.class);
Management mejb = home.create();
String domain = mejb.getDefaultDomain();// figure out what the 'service manager' contains (2)
Set names = mejb.queryNames(
new ObjectName(domain + ":j2eeType=EJBModule,*"),
null);
Iterator itr = names.iterator();
while(itr.hasNext()) {
System.out.println(itr.next());
}// access object attributes (3)
while(itr.hasNext()) {
ObjectName name = (ObjectName)itr.next();
System.out.println("EJBModule: " + name);
ObjectName[] ejbs = (ObjectName[])mejb.getAttribute(name, "ejbs");
for(int i = 0; i < ejbs.length; i++) {
System.out.println(" EJB: " + ejbs[i]);
}
}// stop then start a mail server (4)
String domain = mejb.getDefaultDomain();
Set names = mejb.queryNames(new ObjectName(domain +
":j2eeType=JavaMailResource,*"),
null);
Iterator itr = names.iterator();
while(itr.hasNext()) {
ObjectName name = (ObjectName)itr.next();
mejb.invoke(name, "stop", null, new String[0]);
Thread.sleep(3000);
mejb.invoke(name, "start", null, new String[0]);
}(all samples taken from the aforementioned javaworld article)
Comments for each of the samples:
(1) this is so ugly my eyes nearly pop! Why is the component (EJB) responsible for creation of the context? Why is there some custom naming protocol for navigating that context? Why does it need to know about remoting/homing? Why is it responsible for creating the local stub? Why does it need to worry about what domain it is in?
With avalon, all those things are done for the component, transparently! The equivalent code, by the way, would be:
public void service( ServiceManager sm ) {}
(2) this would be equivalent to a
String[] ServiceManager.getHostedServices()
method which we've discussed previously and not implemented because, again, it blurs responsibility. The container should know what the component needs and provide it; the component should not adapt its behaviour based on a stupid container that can't provide everything it needs.
(3) I can only begin to wonder how horribly inefficient this piece of code is. The equivalent in avalon is something like
ObjectName[] ejbs = (ObjectName[])sm.lookup( "blah" ).getEjbs();
for(int i = 0; i < ejbs.length; i++) {
System.out.println(" EJB: " + ejbs[i]);
}not that you'll ever want to do something like this in avalon. It's just pointless.
(4) what's this? An EJB using some kind of management interface to the container to start and stop another EJB? Why would you want to do that? Anyway, you've just got to hate
mejb.invoke(name, "stop", null, new String[0]);
since we'd normally already have lookup()ed our component, the avalon equivalent would be something like
myMailService.stop();
but, of course, avalon doesn't allow you to do any of this, for good reasons I hope we don't need to repeat here.
== Quick recap so far ==
The Management interface central to JSR 77 allows you to interact with the EJB container. Despites several dozens of pages of specification, it is highly inferior to any IoC-style setup. It places lots of responsibility with the component (EJB) that just doesn't belong there.
== Why do this with avalon? ==
Obviously, that would be a strategic move with the hope of taking a piece of the J2EE developer pie. It might serve to further cooperation between avalon and geronimo, for example.
== Why not do this with avalon? ==
Because its a highly unnatural fit. We'd have to subvert the control in dozens of places, open up lots of things we've closed off for good reason, provide support for dozens of EJB-specific interfaces that make no sense in the first place (re: EOB), etc etc etc.
== My conclusion ==
Several years and dozens of specifications later, the EJB landscape is still the horrible, messy, big ball of mud that is the cause of programmer nightmare throughout the world. EJB sucks, and JSR 77 is no different.
Now bring on the flamethrower! Or better yet, show me something you'll be able to do using JSR 77 and JSR 88 support that you can't do now *and* that is also agreeably a good idea.
- LSD
PS: for people shocked by the washdown I give EJB here, make sure you don't read http://wiki.apache.org/avalon/AvalonYouMakeTheDecision :D
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
