You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2003/12/16 12:24:21 UTC
JSR 77 and JSR 88 support in avalon
(moved from pmc@ where it doesn't belong)
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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: JSR 77 and JSR 88 support in avalon
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> (moved from pmc@ where it doesn't belong)
>
> 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 agree with Noel.
>
>
> 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.
I think this assessment misses the point because its making the
assumption that the Avalon component model should map to 77/88. A
better approach is to consider a kernel as a manageble entity and to
consider the repository facility as depoyable unit supporting 88. This
provides the bridge between the 77/88 world while maintaining the finer
granularity (and clarity) offered by the Avalon model. The end result
is increasing the scope and value for users in both domains.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: JSR 77 and JSR 88 support in avalon
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 16 December 2003 19:24, Leo Simons wrote:
> IMHO, that is *many* steps back from what avalon provides.
+1
> (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?
Because it is EJB! And EJB HAS a past in vastly worse container systems
pre-dating Java, YHSHY (You haven't seen hell yet.)
> == Why not do this with avalon? ==
+1
> 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.
Pronto!
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org