You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dhananjay Nene <dn...@dnene.com> on 2003/08/07 18:51:20 UTC
Aspect based design ?
Without getting into a debate of how Aspects will compete with or complement
EJBs, would it be a good idea to at least discuss how aspects could be used
to actually build much of the desired functionality. This surely would
complicate things given that the project might be using a lot of source from
initial contributions, but possibly a way could be found to continuously
refactor the same over a period of time. I am not sure whether one needs to
actually build an AOP engine like JBoss. Leveraging existing infrastructure
(AspectJ / AspectWerkz / Nanning) might not be a bad idea.
RE: OpenJMS and EJB MDBs
Posted by Tim Anderson <tm...@netspace.net.au>.
The OpenJMS folks (largely me :), are strapped
for time at the moment, but your wishlist is noted.
Of course, if anyone wants to contribute JCA support,
to OpenJMS, they're welcome.
Regards,
Tim
> -----Original Message-----
> From: Richard Monson-Haefel [mailto:Richard@Monson-Haefel.com]
> Sent: Saturday, 9 August 2003 5:08 AM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: OpenJMS and EJB MDBs
>
>
> Actually, I think all you need to do is to build a MDB container
> that supports J2EE
> Connector Architecture 1.5 facilities for asynchronous messaging.
> If you build it
> right, the MDB container would be capable of supporting any JMS
> implementation that
> properly implemented J2CA 1.5. Not just JMS, you can support any
> async messaging
> system like SMTP, SOAP, and what have you.
>
> OpenJMS works and is available, so if those folks build a J2CA
> 1.5 adapter, then we
> could just plug them into Geronimo and have support for JMS-based
> MDBs. I would
> also, as mentioned before, like to do the same or something
> similar with an e-mail
> system ... like James.
>
> Michael Turilin wrote:
>
> > Hello Richard,
> >
> > Is OpenJMS primary JMS implementation for Geronimo?
> >
> > Friday, August 8, 2003, 3:21:49 PM, you wrote:
> > RMH> A couple years ago I attempted to use OpenJMS to create a
> MDB container
> > RMH> system for OpenEJB. I couldn't do it because OpenJMS at
> that time did not
> > RMH> support JTA resource API - this predates J2EE Connectors
> 1.5. Does OpenJMS
> > RMH> support this now? Specifically can it act as a 2pc
> resource? If so, than
> > RMH> perhaps the best approach to building a MDB container is
> to create a J2EE
> > RMH> Connector for OpenJMS. That would allow it to be totally
> plugable rather
> > RMH> than tightly coupled - I figure that's the way we would go
> anyway, but I
> > RMH> wanted to raise the issue of OpenJMS not supporting (in
> the past) 2pc.
> >
> > --
> > Best regards,
> > Michael mailto:mtwork@hotbox.ru
>
> --
> Richard Monson-Haefel
> Author of J2EE Web Services (Addison-Wesley 2003)
> Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
> Co-Author of Java Message Service (O'Reilly 2000)
> http://www.Monson-Haefel.com
>
>
>
Re: OpenJMS and EJB MDBs
Posted by Richard Monson-Haefel <Ri...@Monson-Haefel.com>.
Actually, I think all you need to do is to build a MDB container that supports J2EE
Connector Architecture 1.5 facilities for asynchronous messaging. If you build it
right, the MDB container would be capable of supporting any JMS implementation that
properly implemented J2CA 1.5. Not just JMS, you can support any async messaging
system like SMTP, SOAP, and what have you.
OpenJMS works and is available, so if those folks build a J2CA 1.5 adapter, then we
could just plug them into Geronimo and have support for JMS-based MDBs. I would
also, as mentioned before, like to do the same or something similar with an e-mail
system ... like James.
Michael Turilin wrote:
> Hello Richard,
>
> Is OpenJMS primary JMS implementation for Geronimo?
>
> Friday, August 8, 2003, 3:21:49 PM, you wrote:
> RMH> A couple years ago I attempted to use OpenJMS to create a MDB container
> RMH> system for OpenEJB. I couldn't do it because OpenJMS at that time did not
> RMH> support JTA resource API - this predates J2EE Connectors 1.5. Does OpenJMS
> RMH> support this now? Specifically can it act as a 2pc resource? If so, than
> RMH> perhaps the best approach to building a MDB container is to create a J2EE
> RMH> Connector for OpenJMS. That would allow it to be totally plugable rather
> RMH> than tightly coupled - I figure that's the way we would go anyway, but I
> RMH> wanted to raise the issue of OpenJMS not supporting (in the past) 2pc.
>
> --
> Best regards,
> Michael mailto:mtwork@hotbox.ru
--
Richard Monson-Haefel
Author of J2EE Web Services (Addison-Wesley 2003)
Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.Monson-Haefel.com
Re: OpenJMS and EJB MDBs
Posted by Michael Turilin <mt...@hotbox.ru>.
Hello Richard,
Is OpenJMS primary JMS implementation for Geronimo?
Friday, August 8, 2003, 3:21:49 PM, you wrote:
RMH> A couple years ago I attempted to use OpenJMS to create a MDB container
RMH> system for OpenEJB. I couldn't do it because OpenJMS at that time did not
RMH> support JTA resource API - this predates J2EE Connectors 1.5. Does OpenJMS
RMH> support this now? Specifically can it act as a 2pc resource? If so, than
RMH> perhaps the best approach to building a MDB container is to create a J2EE
RMH> Connector for OpenJMS. That would allow it to be totally plugable rather
RMH> than tightly coupled - I figure that's the way we would go anyway, but I
RMH> wanted to raise the issue of OpenJMS not supporting (in the past) 2pc.
--
Best regards,
Michael mailto:mtwork@hotbox.ru
OpenJMS and EJB MDBs
Posted by Richard Monson-Haefel <Ri...@Monson-Haefel.com>.
A couple years ago I attempted to use OpenJMS to create a MDB container
system for OpenEJB. I couldn't do it because OpenJMS at that time did not
support JTA resource API - this predates J2EE Connectors 1.5. Does OpenJMS
support this now? Specifically can it act as a 2pc resource? If so, than
perhaps the best approach to building a MDB container is to create a J2EE
Connector for OpenJMS. That would allow it to be totally plugable rather
than tightly coupled - I figure that's the way we would go anyway, but I
wanted to raise the issue of OpenJMS not supporting (in the past) 2pc.
--
Richard Monson-Haefel
Author of J2EE Web Services (Addison-Wesley 2003)
Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.Monson-Haefel.com
Re: JNDI Impl
Posted by Richard Monson-Haefel <Ri...@Monson-Haefel.com>.
Ok, sounds good. We can work on it together (along with any others who want).
I'll take a look at your impl and see if I can't point you to mine (I did it 2
or 3 years ago so I'll have to look around a bit ;-)
Henri Yandell wrote:
> I'm happy to help with the JNDI if required. Moving Tomcat's JNDI impl to
> Commons has been a 'how the hell do I approach that' task on my list for a
> while.
>
> I've also got a peculiar JNDI implementation
> [http://www.osjava.org/simple-jndi] so might have some odd ideas to throw
> in.
>
> Hen
>
> On Thu, 7 Aug 2003, Richard Monson-Haefel wrote:
>
> > I created a JNDI implementation for the Environment Naming Context in
> > OpenEJB that was simple and fast. I think David Blevin's may have
> > modified it so that it plays nice with servlets in Tomcat or with
> > Tomcat's JNDI implementation. At any rate, I would be happy to recreate
> > a similar implementation for Geronimo. Should I plan on doing this?
> > Anyone object?
> >
> > --
> > Richard Monson-Haefel
> > Author of J2EE Web Services (Addison-Wesley 2003)
> > Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
> > Co-Author of Java Message Service (O'Reilly 2000)
> > http://www.Monson-Haefel.com
> >
> >
--
Richard Monson-Haefel
Author of J2EE Web Services (Addison-Wesley 2003)
Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.Monson-Haefel.com
Re: JNDI Impl
Posted by Richard Monson-Haefel <Ri...@Monson-Haefel.com>.
Henri,
Can you send me your impl?
Henri Yandell wrote:
> On Fri, 8 Aug 2003, Richard Monson-Haefel wrote:
>
> > These are excellent issues, Aaron.
> >
> > Speaking only for myself, I envisioned a development track as follows:
> >
> > 1st. Develop, or otherwise obtain, a simple in memory JNDI ENC that can be used
> > across J2EE components. Something very basic, immutable, bootstrapped off a flat
>
> On this now. Commons JNDI. Resolving the dependencies so it will at least
> compile and removing things like the MBean part for the moment. It'll go
> in the Commons-sandbox sometime next week I imagine.
>
> Alternative is my simple-jndi package [which already fulfills two of your
> criteria, simple and jndi being in the title!] which might be of interest.
> I'm just not sure if it's too simple in concept for your plans.
>
> +1 to your general development plan.
>
> Hen
--
Richard Monson-Haefel
Author of J2EE Web Services (Addison-Wesley 2003)
Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.Monson-Haefel.com
RE: JNDI Impl
Posted by "Noel J. Bergman" <no...@devtech.com>.
Henri,
There is also the ldapd.sourceforge.net project, which is interested in
coming to Apache, and contributing. We are looking at using it in James,
they already integrate with Avalon, and are geared for embedding.
--- Noel
Re: JNDI Impl
Posted by Henri Yandell <ba...@generationjava.com>.
I've commited the Tomcat JNDI implementation into
jakarta-commons-sandbox/naming. I had played around a bit, pushing some
standard looking components into a jndi sub-package but I've backed that
out currently as unimportant.
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/naming/
The maven project.xml works for building under maven b10. There are a lot
of Sun dependencies though, so you have to hunt them down. I'll try to
hook some urls to them to make life a little easier.
I'm no shakes at JNDI, just interested, so for me my next step is to
understand fully what is going on in the Tomcat JNDI [I've got a good
grasp, but have yet to work out how to pass in some xml configurations
etc]. If others have better drives etc, I'm happy to act as the Commons
gopher and deal with websites, releases, passing on the Commons/ASF way
etc.
cvs checking out via:
cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login
password: anoncvs
cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic checkout jakarta-commons/naming
Have at it,
Hen
On Fri, 8 Aug 2003, Henri Yandell wrote:
>
>
> On Fri, 8 Aug 2003, Richard Monson-Haefel wrote:
>
> > These are excellent issues, Aaron.
> >
> > Speaking only for myself, I envisioned a development track as follows:
> >
> > 1st. Develop, or otherwise obtain, a simple in memory JNDI ENC that can be used
> > across J2EE components. Something very basic, immutable, bootstrapped off a flat
>
> On this now. Commons JNDI. Resolving the dependencies so it will at least
> compile and removing things like the MBean part for the moment. It'll go
> in the Commons-sandbox sometime next week I imagine.
>
> Alternative is my simple-jndi package [which already fulfills two of your
> criteria, simple and jndi being in the title!] which might be of interest.
> I'm just not sure if it's too simple in concept for your plans.
>
> +1 to your general development plan.
>
> Hen
>
Re: JNDI Impl
Posted by James Strachan <ja...@yahoo.co.uk>.
On Friday, August 8, 2003, at 08:40 pm, Henri Yandell wrote:
> On Fri, 8 Aug 2003, Richard Monson-Haefel wrote:
>
>> These are excellent issues, Aaron.
>>
>> Speaking only for myself, I envisioned a development track as follows:
>>
>> 1st. Develop, or otherwise obtain, a simple in memory JNDI ENC that
>> can be used
>> across J2EE components. Something very basic, immutable, bootstrapped
>> off a flat
>
> On this now. Commons JNDI. Resolving the dependencies so it will at
> least
> compile and removing things like the MBean part for the moment.
Actually, the MBean parts could be very handy if you could keep them :)
> It'll go
> in the Commons-sandbox sometime next week I imagine.
Great.
James
-------
http://radio.weblogs.com/0112098/
Re: JNDI Impl
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 8 Aug 2003, Richard Monson-Haefel wrote:
> These are excellent issues, Aaron.
>
> Speaking only for myself, I envisioned a development track as follows:
>
> 1st. Develop, or otherwise obtain, a simple in memory JNDI ENC that can be used
> across J2EE components. Something very basic, immutable, bootstrapped off a flat
On this now. Commons JNDI. Resolving the dependencies so it will at least
compile and removing things like the MBean part for the moment. It'll go
in the Commons-sandbox sometime next week I imagine.
Alternative is my simple-jndi package [which already fulfills two of your
criteria, simple and jndi being in the title!] which might be of interest.
I'm just not sure if it's too simple in concept for your plans.
+1 to your general development plan.
Hen
RE: JNDI Impl
Posted by Henri Yandell <ba...@generationjava.com>.
Man I'm thick. Ignore the last email. The JNDI API interface is said
wrapper. *takes self outside to give self a kickin'*
On Fri, 8 Aug 2003, Henri Yandell wrote:
>
>
> On Fri, 8 Aug 2003, Noel J. Bergman wrote:
>
> > > 2nd. Develop, or otherwise obtain, a fow blown Java-based directory
> > system that
> > > supports the JNDI LDAP and RMI bindings.
> >
> > It already exists and wants to come to Apache. ldapd.sourceforge.net. I've
> > spoken to the team leader on and off for months. Myself and I believe some
> > of the Avalon guys are willing to co-sponsor its entry to Apache. I don't
> > know if people plan to bring in such things as sub-projects of Geronimo's
> > incubation, or as separate incubator projects, but that'll be a question for
> > elsewhere. I just want to make everyone aware of the project, which already
> > has substantial code, and an existing community trying to follow ASF rules.
>
> It seems like a potential perfect fit for 2. We'll still need a
> JNDI-wrapping layer I presume as ldapd is the LDAP spec and not JNDI.
>
> Hen
>
Re: JNDI Impl
Posted by Richard Monson-Haefel <Ri...@Monson-Haefel.com>.
Sounds like this LDAP project may be a good fit. We should look into it for the
future.
"Noel J. Bergman" wrote:
> Henri Yandell commented:
> > On Fri, 8 Aug 2003, Noel J. Bergman wrote:
>
> > > > 2nd. Develop, or otherwise obtain, a fow blown Java-based directory
> > > > system that supports the JNDI LDAP and RMI bindings.
>
> > > It already exists and wants to come to Apache. ldapd.sourceforge.net.
> I've
> > > spoken to the team leader on and off for months. Myself, and I believe
> some
> > > of the Avalon guys, are willing to co-sponsor its entry to Apache. I
> don't
> > > know if people plan to bring in such things as sub-projects of
> Geronimo's
> > > incubation, or as separate incubator projects, but that'll be a question
> for
> > > elsewhere. I just want to make everyone aware of the project, which
> already
> > > has substantial code, and an existing community trying to follow ASF
> rules.
>
> > It seems like a potential perfect fit for 2. We'll still need a
> > JNDI-wrapping layer I presume as ldapd is the LDAP spec and not JNDI.
>
> They already have the whole thing integrated with JNDI. Also, Alex and I
> have talked about their providing their data store backends as direct
> service providers for JNDI, liberated from the LDAP naming space, and he's
> interested.
>
> --- Noel
--
Richard Monson-Haefel
Author of J2EE Web Services (Addison-Wesley 2003)
Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.Monson-Haefel.com
RE: JNDI Impl
Posted by "Noel J. Bergman" <no...@devtech.com>.
Henri Yandell commented:
> On Fri, 8 Aug 2003, Noel J. Bergman wrote:
> > > 2nd. Develop, or otherwise obtain, a fow blown Java-based directory
> > > system that supports the JNDI LDAP and RMI bindings.
> > It already exists and wants to come to Apache. ldapd.sourceforge.net.
I've
> > spoken to the team leader on and off for months. Myself, and I believe
some
> > of the Avalon guys, are willing to co-sponsor its entry to Apache. I
don't
> > know if people plan to bring in such things as sub-projects of
Geronimo's
> > incubation, or as separate incubator projects, but that'll be a question
for
> > elsewhere. I just want to make everyone aware of the project, which
already
> > has substantial code, and an existing community trying to follow ASF
rules.
> It seems like a potential perfect fit for 2. We'll still need a
> JNDI-wrapping layer I presume as ldapd is the LDAP spec and not JNDI.
They already have the whole thing integrated with JNDI. Also, Alex and I
have talked about their providing their data store backends as direct
service providers for JNDI, liberated from the LDAP naming space, and he's
interested.
--- Noel
RE: JNDI Impl
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 8 Aug 2003, Noel J. Bergman wrote:
> > 2nd. Develop, or otherwise obtain, a fow blown Java-based directory
> system that
> > supports the JNDI LDAP and RMI bindings.
>
> It already exists and wants to come to Apache. ldapd.sourceforge.net. I've
> spoken to the team leader on and off for months. Myself and I believe some
> of the Avalon guys are willing to co-sponsor its entry to Apache. I don't
> know if people plan to bring in such things as sub-projects of Geronimo's
> incubation, or as separate incubator projects, but that'll be a question for
> elsewhere. I just want to make everyone aware of the project, which already
> has substantial code, and an existing community trying to follow ASF rules.
It seems like a potential perfect fit for 2. We'll still need a
JNDI-wrapping layer I presume as ldapd is the LDAP spec and not JNDI.
Hen
RE: JNDI Impl
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 2nd. Develop, or otherwise obtain, a fow blown Java-based directory
system that
> supports the JNDI LDAP and RMI bindings.
It already exists and wants to come to Apache. ldapd.sourceforge.net. I've
spoken to the team leader on and off for months. Myself and I believe some
of the Avalon guys are willing to co-sponsor its entry to Apache. I don't
know if people plan to bring in such things as sub-projects of Geronimo's
incubation, or as separate incubator projects, but that'll be a question for
elsewhere. I just want to make everyone aware of the project, which already
has substantial code, and an existing community trying to follow ASF rules.
--- Noel
Re: JNDI Impl
Posted by Richard Monson-Haefel <Ri...@Monson-Haefel.com>.
These are excellent issues, Aaron.
Speaking only for myself, I envisioned a development track as follows:
1st. Develop, or otherwise obtain, a simple in memory JNDI ENC that can be used
across J2EE components. Something very basic, immutable, bootstrapped off a flat
file (XML?), and fast. This will allow us to focus our attention only briefly on
the JNDI problem until after the first release of Geronimo. I think the best way
to proceed is to see if we can adapt Tomcat's JNDI impl (which sounds very similar
to the OpenEJB's) to be useful outside of Tomcat. Moving it to the commons
perhaps. This may be the fastest because (a) we don't have to develop the simple
JNDI ENC from scratch and (b) that code is already under Apache so its would be
nice to reuse it in Geronimo.
2nd. Develop, or otherwise obtain, a fow blown Java-based directory system that
supports the JNDI LDAP and RMI bindings. This service could be used as part of
Geronimo, or as a stand alone application. This would require some thought about
how persistence should work and if it should be based on CMP or something else ...
personally I think you can accommodate multiple solutions.
3rd. Replace the simple JNDI implementation with the advanced one from step 2 OR
support both ... personally for performance reasons I think that's the best way to
go is to support both. Those are my initial thoughts on the topic.
Aaron Mulder wrote:
> I'll suggest a couple things to think about for the JNDI
> implementation:
>
> 1) Should there be a remote JNDI? It's traditional, but not really
> required by the specs AFAICT, as long as you don't mind forcing all
> application clients to use a client container.
>
> 2) If so, should there be one JNDI impl with both local and remote
> features, or two separate impls, a remote-only and a local-only
>
> 3) If there is a remote JNDI, should it be "securable"? That is, should
> you be able to require people to log in in order to access it?
>
> Aaron
>
> On Fri, 8 Aug 2003, Richard Monson-Haefel wrote:
> > The JNDI implementation I wrote for OpenEJB was really simple. It used a
> > binary tree to locate sub contexts and cached lookups for speed. It wasn't a
> > full fledged JNDI implementation in that you could not dynamically bind or
> > unbind objects. The JNDI Environment Naming Context is supposed to be
> > immutable after server start up. That's why its possible to create a very
> > lightweight implementation that is easy to maintain and very fast.
> >
> > If you created a stand alone JNDI ENC it wouldn't be very useful outside of
> > the J2EE context. It may be better in the long run to have a complete JNDI
> > implementation which is based on something in the commons. For the short
> > term, however, we can use something more akin to what I created for OpenEJB
> > -- its doesn't take long to create and is flexible enough to play nice with
> > other systems.
> >
> > James Strachan wrote:
> >
> > > Just a thought - Richard do you think the JNDI is gonna need much hooks
> > > to Geronimo or will it be just a 100% vanilla JNDI.
> > >
> > > Am wondering if (say) Henri moved the JNDI to Jakarta Commons for us so
> > > its easy to reuse (thanks Henri!), we could then add any extra stuff we
> > > need inside Geronimo for now and if it turns out that some reusable
> > > code can be pushed back into Commons we can do that too.
> > >
> > > On Friday, August 8, 2003, at 08:04 am, Henri Yandell wrote:
> > >
> > > >
> > > > Additional:
> > > >
> > > > Am also a Commons committer, so can handle things like setting the
> > > > project
> > > > up and website etc.
> > > >
> > > > I believe the person to speak to about the Tomcat JNDI is Costin
> > > > Manolache. No idea if he's hooked into the Geronimo feed yet.
> > > >
> > > > Hen
> > > >
> > > > On Fri, 8 Aug 2003, Henri Yandell wrote:
> > > >
> > > >>
> > > >> I'm happy to help with the JNDI if required. Moving Tomcat's JNDI
> > > >> impl to
> > > >> Commons has been a 'how the hell do I approach that' task on my list
> > > >> for a
> > > >> while.
> > > >>
> > > >> I've also got a peculiar JNDI implementation
> > > >> [http://www.osjava.org/simple-jndi] so might have some odd ideas to
> > > >> throw
> > > >> in.
> > > >>
> > > >> Hen
> > > >>
> > > >> On Thu, 7 Aug 2003, Richard Monson-Haefel wrote:
> > > >>
> > > >>> I created a JNDI implementation for the Environment Naming Context in
> > > >>> OpenEJB that was simple and fast. I think David Blevin's may have
> > > >>> modified it so that it plays nice with servlets in Tomcat or with
> > > >>> Tomcat's JNDI implementation. At any rate, I would be happy to
> > > >>> recreate
> > > >>> a similar implementation for Geronimo. Should I plan on doing this?
> > > >>> Anyone object?
> > > >>>
> > > >>> --
> > > >>> Richard Monson-Haefel
> > > >>> Author of J2EE Web Services (Addison-Wesley 2003)
> > > >>> Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
> > > >>> Co-Author of Java Message Service (O'Reilly 2000)
> > > >>> http://www.Monson-Haefel.com
> > > >>>
> > > >>>
> > > >>
> > > >
> > > >
> > >
> > > James
> > > -------
> > > http://radio.weblogs.com/0112098/
> >
> > --
> > Richard Monson-Haefel
> > Author of J2EE Web Services (Addison-Wesley 2003)
> > Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
> > Co-Author of Java Message Service (O'Reilly 2000)
> > http://www.Monson-Haefel.com
> >
> >
--
Richard Monson-Haefel
Author of J2EE Web Services (Addison-Wesley 2003)
Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.Monson-Haefel.com
Re: JNDI Impl
Posted by David Jencks <da...@snappydsl.net>.
Based on my experience implementing distributed transactions in jboss
4, I'm in favor of
--all communications between vms going over a (securable) remoting
layer with pluggable transports. In JBoss 4 this was an abstraction of
jmx remoting, which seemed to work well to me.
--services (such as jndi) running on the local vm and requesting info
as needed from remote vms.
It wasn't too hard to pull back appropriate chunks of server
functionality so the client container was invisible to the client
program.
david jencks
On Friday, August 8, 2003, at 07:32 AM, Aaron Mulder wrote:
> I'll suggest a couple things to think about for the JNDI
> implementation:
>
> 1) Should there be a remote JNDI? It's traditional, but not really
> required by the specs AFAICT, as long as you don't mind forcing all
> application clients to use a client container.
>
> 2) If so, should there be one JNDI impl with both local and remote
> features, or two separate impls, a remote-only and a local-only
>
> 3) If there is a remote JNDI, should it be "securable"? That is,
> should
> you be able to require people to log in in order to access it?
>
> Aaron
>
> On Fri, 8 Aug 2003, Richard Monson-Haefel wrote:
>> The JNDI implementation I wrote for OpenEJB was really simple. It
>> used a
>> binary tree to locate sub contexts and cached lookups for speed. It
>> wasn't a
>> full fledged JNDI implementation in that you could not dynamically
>> bind or
>> unbind objects. The JNDI Environment Naming Context is supposed to be
>> immutable after server start up. That's why its possible to create a
>> very
>> lightweight implementation that is easy to maintain and very fast.
>>
>> If you created a stand alone JNDI ENC it wouldn't be very useful
>> outside of
>> the J2EE context. It may be better in the long run to have a
>> complete JNDI
>> implementation which is based on something in the commons. For the
>> short
>> term, however, we can use something more akin to what I created for
>> OpenEJB
>> -- its doesn't take long to create and is flexible enough to play
>> nice with
>> other systems.
>>
>> James Strachan wrote:
>>
>>> Just a thought - Richard do you think the JNDI is gonna need much
>>> hooks
>>> to Geronimo or will it be just a 100% vanilla JNDI.
>>>
>>> Am wondering if (say) Henri moved the JNDI to Jakarta Commons for us
>>> so
>>> its easy to reuse (thanks Henri!), we could then add any extra stuff
>>> we
>>> need inside Geronimo for now and if it turns out that some reusable
>>> code can be pushed back into Commons we can do that too.
>>>
>>> On Friday, August 8, 2003, at 08:04 am, Henri Yandell wrote:
>>>
>>>>
>>>> Additional:
>>>>
>>>> Am also a Commons committer, so can handle things like setting the
>>>> project
>>>> up and website etc.
>>>>
>>>> I believe the person to speak to about the Tomcat JNDI is Costin
>>>> Manolache. No idea if he's hooked into the Geronimo feed yet.
>>>>
>>>> Hen
>>>>
>>>> On Fri, 8 Aug 2003, Henri Yandell wrote:
>>>>
>>>>>
>>>>> I'm happy to help with the JNDI if required. Moving Tomcat's JNDI
>>>>> impl to
>>>>> Commons has been a 'how the hell do I approach that' task on my
>>>>> list
>>>>> for a
>>>>> while.
>>>>>
>>>>> I've also got a peculiar JNDI implementation
>>>>> [http://www.osjava.org/simple-jndi] so might have some odd ideas to
>>>>> throw
>>>>> in.
>>>>>
>>>>> Hen
>>>>>
>>>>> On Thu, 7 Aug 2003, Richard Monson-Haefel wrote:
>>>>>
>>>>>> I created a JNDI implementation for the Environment Naming
>>>>>> Context in
>>>>>> OpenEJB that was simple and fast. I think David Blevin's may have
>>>>>> modified it so that it plays nice with servlets in Tomcat or with
>>>>>> Tomcat's JNDI implementation. At any rate, I would be happy to
>>>>>> recreate
>>>>>> a similar implementation for Geronimo. Should I plan on doing
>>>>>> this?
>>>>>> Anyone object?
>>>>>>
>>>>>> --
>>>>>> Richard Monson-Haefel
>>>>>> Author of J2EE Web Services (Addison-Wesley 2003)
>>>>>> Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
>>>>>> Co-Author of Java Message Service (O'Reilly 2000)
>>>>>> http://www.Monson-Haefel.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>> James
>>> -------
>>> http://radio.weblogs.com/0112098/
>>
>> --
>> Richard Monson-Haefel
>> Author of J2EE Web Services (Addison-Wesley 2003)
>> Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
>> Co-Author of Java Message Service (O'Reilly 2000)
>> http://www.Monson-Haefel.com
>>
>>
>
Re: JNDI Impl
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I'll suggest a couple things to think about for the JNDI
implementation:
1) Should there be a remote JNDI? It's traditional, but not really
required by the specs AFAICT, as long as you don't mind forcing all
application clients to use a client container.
2) If so, should there be one JNDI impl with both local and remote
features, or two separate impls, a remote-only and a local-only
3) If there is a remote JNDI, should it be "securable"? That is, should
you be able to require people to log in in order to access it?
Aaron
On Fri, 8 Aug 2003, Richard Monson-Haefel wrote:
> The JNDI implementation I wrote for OpenEJB was really simple. It used a
> binary tree to locate sub contexts and cached lookups for speed. It wasn't a
> full fledged JNDI implementation in that you could not dynamically bind or
> unbind objects. The JNDI Environment Naming Context is supposed to be
> immutable after server start up. That's why its possible to create a very
> lightweight implementation that is easy to maintain and very fast.
>
> If you created a stand alone JNDI ENC it wouldn't be very useful outside of
> the J2EE context. It may be better in the long run to have a complete JNDI
> implementation which is based on something in the commons. For the short
> term, however, we can use something more akin to what I created for OpenEJB
> -- its doesn't take long to create and is flexible enough to play nice with
> other systems.
>
> James Strachan wrote:
>
> > Just a thought - Richard do you think the JNDI is gonna need much hooks
> > to Geronimo or will it be just a 100% vanilla JNDI.
> >
> > Am wondering if (say) Henri moved the JNDI to Jakarta Commons for us so
> > its easy to reuse (thanks Henri!), we could then add any extra stuff we
> > need inside Geronimo for now and if it turns out that some reusable
> > code can be pushed back into Commons we can do that too.
> >
> > On Friday, August 8, 2003, at 08:04 am, Henri Yandell wrote:
> >
> > >
> > > Additional:
> > >
> > > Am also a Commons committer, so can handle things like setting the
> > > project
> > > up and website etc.
> > >
> > > I believe the person to speak to about the Tomcat JNDI is Costin
> > > Manolache. No idea if he's hooked into the Geronimo feed yet.
> > >
> > > Hen
> > >
> > > On Fri, 8 Aug 2003, Henri Yandell wrote:
> > >
> > >>
> > >> I'm happy to help with the JNDI if required. Moving Tomcat's JNDI
> > >> impl to
> > >> Commons has been a 'how the hell do I approach that' task on my list
> > >> for a
> > >> while.
> > >>
> > >> I've also got a peculiar JNDI implementation
> > >> [http://www.osjava.org/simple-jndi] so might have some odd ideas to
> > >> throw
> > >> in.
> > >>
> > >> Hen
> > >>
> > >> On Thu, 7 Aug 2003, Richard Monson-Haefel wrote:
> > >>
> > >>> I created a JNDI implementation for the Environment Naming Context in
> > >>> OpenEJB that was simple and fast. I think David Blevin's may have
> > >>> modified it so that it plays nice with servlets in Tomcat or with
> > >>> Tomcat's JNDI implementation. At any rate, I would be happy to
> > >>> recreate
> > >>> a similar implementation for Geronimo. Should I plan on doing this?
> > >>> Anyone object?
> > >>>
> > >>> --
> > >>> Richard Monson-Haefel
> > >>> Author of J2EE Web Services (Addison-Wesley 2003)
> > >>> Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
> > >>> Co-Author of Java Message Service (O'Reilly 2000)
> > >>> http://www.Monson-Haefel.com
> > >>>
> > >>>
> > >>
> > >
> > >
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
>
> --
> Richard Monson-Haefel
> Author of J2EE Web Services (Addison-Wesley 2003)
> Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
> Co-Author of Java Message Service (O'Reilly 2000)
> http://www.Monson-Haefel.com
>
>
Re: JNDI Impl
Posted by Richard Monson-Haefel <Ri...@Monson-Haefel.com>.
The JNDI implementation I wrote for OpenEJB was really simple. It used a
binary tree to locate sub contexts and cached lookups for speed. It wasn't a
full fledged JNDI implementation in that you could not dynamically bind or
unbind objects. The JNDI Environment Naming Context is supposed to be
immutable after server start up. That's why its possible to create a very
lightweight implementation that is easy to maintain and very fast.
If you created a stand alone JNDI ENC it wouldn't be very useful outside of
the J2EE context. It may be better in the long run to have a complete JNDI
implementation which is based on something in the commons. For the short
term, however, we can use something more akin to what I created for OpenEJB
-- its doesn't take long to create and is flexible enough to play nice with
other systems.
James Strachan wrote:
> Just a thought - Richard do you think the JNDI is gonna need much hooks
> to Geronimo or will it be just a 100% vanilla JNDI.
>
> Am wondering if (say) Henri moved the JNDI to Jakarta Commons for us so
> its easy to reuse (thanks Henri!), we could then add any extra stuff we
> need inside Geronimo for now and if it turns out that some reusable
> code can be pushed back into Commons we can do that too.
>
> On Friday, August 8, 2003, at 08:04 am, Henri Yandell wrote:
>
> >
> > Additional:
> >
> > Am also a Commons committer, so can handle things like setting the
> > project
> > up and website etc.
> >
> > I believe the person to speak to about the Tomcat JNDI is Costin
> > Manolache. No idea if he's hooked into the Geronimo feed yet.
> >
> > Hen
> >
> > On Fri, 8 Aug 2003, Henri Yandell wrote:
> >
> >>
> >> I'm happy to help with the JNDI if required. Moving Tomcat's JNDI
> >> impl to
> >> Commons has been a 'how the hell do I approach that' task on my list
> >> for a
> >> while.
> >>
> >> I've also got a peculiar JNDI implementation
> >> [http://www.osjava.org/simple-jndi] so might have some odd ideas to
> >> throw
> >> in.
> >>
> >> Hen
> >>
> >> On Thu, 7 Aug 2003, Richard Monson-Haefel wrote:
> >>
> >>> I created a JNDI implementation for the Environment Naming Context in
> >>> OpenEJB that was simple and fast. I think David Blevin's may have
> >>> modified it so that it plays nice with servlets in Tomcat or with
> >>> Tomcat's JNDI implementation. At any rate, I would be happy to
> >>> recreate
> >>> a similar implementation for Geronimo. Should I plan on doing this?
> >>> Anyone object?
> >>>
> >>> --
> >>> Richard Monson-Haefel
> >>> Author of J2EE Web Services (Addison-Wesley 2003)
> >>> Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
> >>> Co-Author of Java Message Service (O'Reilly 2000)
> >>> http://www.Monson-Haefel.com
> >>>
> >>>
> >>
> >
> >
>
> James
> -------
> http://radio.weblogs.com/0112098/
--
Richard Monson-Haefel
Author of J2EE Web Services (Addison-Wesley 2003)
Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.Monson-Haefel.com
Re: JNDI Impl
Posted by James Strachan <ja...@yahoo.co.uk>.
Just a thought - Richard do you think the JNDI is gonna need much hooks
to Geronimo or will it be just a 100% vanilla JNDI.
Am wondering if (say) Henri moved the JNDI to Jakarta Commons for us so
its easy to reuse (thanks Henri!), we could then add any extra stuff we
need inside Geronimo for now and if it turns out that some reusable
code can be pushed back into Commons we can do that too.
On Friday, August 8, 2003, at 08:04 am, Henri Yandell wrote:
>
> Additional:
>
> Am also a Commons committer, so can handle things like setting the
> project
> up and website etc.
>
> I believe the person to speak to about the Tomcat JNDI is Costin
> Manolache. No idea if he's hooked into the Geronimo feed yet.
>
> Hen
>
> On Fri, 8 Aug 2003, Henri Yandell wrote:
>
>>
>> I'm happy to help with the JNDI if required. Moving Tomcat's JNDI
>> impl to
>> Commons has been a 'how the hell do I approach that' task on my list
>> for a
>> while.
>>
>> I've also got a peculiar JNDI implementation
>> [http://www.osjava.org/simple-jndi] so might have some odd ideas to
>> throw
>> in.
>>
>> Hen
>>
>> On Thu, 7 Aug 2003, Richard Monson-Haefel wrote:
>>
>>> I created a JNDI implementation for the Environment Naming Context in
>>> OpenEJB that was simple and fast. I think David Blevin's may have
>>> modified it so that it plays nice with servlets in Tomcat or with
>>> Tomcat's JNDI implementation. At any rate, I would be happy to
>>> recreate
>>> a similar implementation for Geronimo. Should I plan on doing this?
>>> Anyone object?
>>>
>>> --
>>> Richard Monson-Haefel
>>> Author of J2EE Web Services (Addison-Wesley 2003)
>>> Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
>>> Co-Author of Java Message Service (O'Reilly 2000)
>>> http://www.Monson-Haefel.com
>>>
>>>
>>
>
>
James
-------
http://radio.weblogs.com/0112098/
Re: JNDI Impl
Posted by Henri Yandell <ba...@generationjava.com>.
Additional:
Am also a Commons committer, so can handle things like setting the project
up and website etc.
I believe the person to speak to about the Tomcat JNDI is Costin
Manolache. No idea if he's hooked into the Geronimo feed yet.
Hen
On Fri, 8 Aug 2003, Henri Yandell wrote:
>
> I'm happy to help with the JNDI if required. Moving Tomcat's JNDI impl to
> Commons has been a 'how the hell do I approach that' task on my list for a
> while.
>
> I've also got a peculiar JNDI implementation
> [http://www.osjava.org/simple-jndi] so might have some odd ideas to throw
> in.
>
> Hen
>
> On Thu, 7 Aug 2003, Richard Monson-Haefel wrote:
>
> > I created a JNDI implementation for the Environment Naming Context in
> > OpenEJB that was simple and fast. I think David Blevin's may have
> > modified it so that it plays nice with servlets in Tomcat or with
> > Tomcat's JNDI implementation. At any rate, I would be happy to recreate
> > a similar implementation for Geronimo. Should I plan on doing this?
> > Anyone object?
> >
> > --
> > Richard Monson-Haefel
> > Author of J2EE Web Services (Addison-Wesley 2003)
> > Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
> > Co-Author of Java Message Service (O'Reilly 2000)
> > http://www.Monson-Haefel.com
> >
> >
>
Re: JNDI Impl
Posted by Henri Yandell <ba...@generationjava.com>.
I'm happy to help with the JNDI if required. Moving Tomcat's JNDI impl to
Commons has been a 'how the hell do I approach that' task on my list for a
while.
I've also got a peculiar JNDI implementation
[http://www.osjava.org/simple-jndi] so might have some odd ideas to throw
in.
Hen
On Thu, 7 Aug 2003, Richard Monson-Haefel wrote:
> I created a JNDI implementation for the Environment Naming Context in
> OpenEJB that was simple and fast. I think David Blevin's may have
> modified it so that it plays nice with servlets in Tomcat or with
> Tomcat's JNDI implementation. At any rate, I would be happy to recreate
> a similar implementation for Geronimo. Should I plan on doing this?
> Anyone object?
>
> --
> Richard Monson-Haefel
> Author of J2EE Web Services (Addison-Wesley 2003)
> Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
> Co-Author of Java Message Service (O'Reilly 2000)
> http://www.Monson-Haefel.com
>
>
JNDI Impl
Posted by Richard Monson-Haefel <Ri...@Monson-Haefel.com>.
I created a JNDI implementation for the Environment Naming Context in
OpenEJB that was simple and fast. I think David Blevin's may have
modified it so that it plays nice with servlets in Tomcat or with
Tomcat's JNDI implementation. At any rate, I would be happy to recreate
a similar implementation for Geronimo. Should I plan on doing this?
Anyone object?
--
Richard Monson-Haefel
Author of J2EE Web Services (Addison-Wesley 2003)
Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.Monson-Haefel.com
Re: Aspect based design ?
Posted by James Strachan <ja...@yahoo.co.uk>.
On Friday, August 8, 2003, at 01:53 pm, Dhananjay Nene wrote:
>
>> On Friday, August 8, 2003, at 09:51 am, Stefan Arentz wrote:
>>
>>>
>>> On Thursday, August 7, 2003, at 19:30, James Strachan wrote:
>>>
>>> Personally I don't care much (yet) about a service for users of the
>>> servers but I think it should be given some serious thoughts for
>>> container development.
>>
>> Agreed. Though lets get the J2EE server ready first then lets figure
>> out how to weave J2EE aspects nicely into POJOs later on - or in a
>> separate parallel project.
>>
>> Incidentally if there was gonna be some J2EE aspects, they should
>> hopefully be mostly J2EE standard apsects and so work with any J2EE
>> container right? So maybe its time for a separate AspectJ2ee project?
>> I'm sure Geronimo could eventually supply some custom
>> Geronimo-specific
>> aspects later on down the road.
>>
> Assuming one started development without any existing code, AOP would
> deliver two advantages.
> a. For Developers - Offer a better mechanism of expressing cross
> cutting
> design constructs and thus the code
FWIW (whenever you get to see it) the initial Geronimo code already has
an interceptor stack - so its quite ready for use in an AOP framework.
> b. For Developers and End users - Offer a better mechanism of
> expressing
> geronimo features which can be perceived to be cross cutting for the
> users.
> The most obvious ones here are transaction / security / logging /
> persistence
> etc.
>
> An aspect based design would support a scenario where geronimo ships
> with
> j2ee aspects, and would allow "unsatisfied" users to tweak the aspects
> or
> write their own.
I agree in principle, Geronimo is already gonna have several modules
(core container, web container connector, WS connector etc). So why
don't we start an experimental AOP module? Then the folks developing
the AOP module can focus on AOP stuff and the Geronimo server
developers can focus on getting the J2EE server working. If some of the
AOP work ends up getting used inside the core container - cool.
Otherwise they can be separate, parallel modules that work together.
> I believe it would be important to have a considered
> strategy on whether such a feature would be required and if so how and
> when
> should it be brought in.
AOP is certainly not required for J2EE compliance; though it is a nice
feature for folks wanting to use POJOs and so forth. So I'd recommend a
separate project somwhere or a parallel separate module in Geronimo.
> The implementation could be phased, but if the
> approach isnt in place, then it may never take off. Hence I dont think
> one
> can "defer" this issue.
I disagree. If you look at AspectWerkz and Nanning, already they've
gone a long way to adding many J2EE style aspects to any POJOs quite
easily with very little development. I don't see why a group of folks
can't get together, do a groovy J2EE aspects project - try and work
with most J2EE servers and by all means write some Geronimo-specific
extras - but I don't think we need to interfere with the general
Geronimo server development to do this.
> You do bring out an interesting option of a separate AspectJ2EE
> project, but
> I think it would be useful to consider how such a project could
> cooperate
> with geronimo for example.
We could start off as a module of Geronimo. Or it could start elsewhere
too. (I'd like to get the AspectWerkz & Nanning guys involved too if we
can).
> I suspect making aspects into a separate project
> and hoping that they would cooperate nicely with geronimo would be a
> lot
> harder than it seems.
I disagree - many folks on this list work on various separate projects
which work together. Whether the AOP project is a module in Geronimo or
a separate project elsewhere I'm sure we'd work closely together to
make it work. I'm sure plenty of folks on both sides of the fence can
understand each others perspectives and try to help each other. (I
myself might swap hats occasionally, sitting in both camps since I
think both projects are very useful). However I don't want AOP
considerations to slow down Geronimo getting a fully working & tested
J2EE stack.
> I ask myself - how would I build a new container from scratch today,
> and I
> am unable to really have a satisfactory answer which does not involve
> aspects.
Aspects and an interceptor stack are quite similar in many ways - from
a containers perspective. I don't see any reason why the Geronimo
interceptor stack can't be easily integrated into any J2EE AOP project.
James
-------
http://radio.weblogs.com/0112098/
RE: Aspect based design ?
Posted by Dhananjay Nene <dn...@dnene.com>.
> On Friday, August 8, 2003, at 09:51 am, Stefan Arentz wrote:
>
> >
> > On Thursday, August 7, 2003, at 19:30, James Strachan wrote:
> >
> > Personally I don't care much (yet) about a service for users of the
> > servers but I think it should be given some serious thoughts for
> > container development.
>
> Agreed. Though lets get the J2EE server ready first then lets figure
> out how to weave J2EE aspects nicely into POJOs later on - or in a
> separate parallel project.
>
> Incidentally if there was gonna be some J2EE aspects, they should
> hopefully be mostly J2EE standard apsects and so work with any J2EE
> container right? So maybe its time for a separate AspectJ2ee project?
> I'm sure Geronimo could eventually supply some custom Geronimo-specific
> aspects later on down the road.
>
Assuming one started development without any existing code, AOP would
deliver two advantages.
a. For Developers - Offer a better mechanism of expressing cross cutting
design constructs and thus the code
b. For Developers and End users - Offer a better mechanism of expressing
geronimo features which can be perceived to be cross cutting for the users.
The most obvious ones here are transaction / security / logging /
persistence
etc.
An aspect based design would support a scenario where geronimo ships with
j2ee aspects, and would allow "unsatisfied" users to tweak the aspects or
write their own. I believe it would be important to have a considered
strategy on whether such a feature would be required and if so how and when
should it be brought in. The implementation could be phased, but if the
approach isnt in place, then it may never take off. Hence I dont think one
can "defer" this issue.
You do bring out an interesting option of a separate AspectJ2EE project, but
I think it would be useful to consider how such a project could cooperate
with geronimo for example. I suspect making aspects into a separate project
and hoping that they would cooperate nicely with geronimo would be a lot
harder than it seems.
I ask myself - how would I build a new container from scratch today, and I
am unable to really have a satisfactory answer which does not involve
aspects.
Re: Aspect based design ?
Posted by James Strachan <ja...@yahoo.co.uk>.
On Friday, August 8, 2003, at 09:51 am, Stefan Arentz wrote:
>
> On Thursday, August 7, 2003, at 19:30, James Strachan wrote:
>
> [About an AOP service]
>
>> However I see this as another aspect (forgive the pun) of the project
>> - an alternative front end to Geronimo. We need to get the back end
>> container working first. Then we can have some AOP project / module
>> later on.
>
> Isn't the main reason of using AOP that it makes the development of
> the container much more easier?
I guess it depends on your point of view. I understand AOP to be
weaving aspects (cross-cutting concerns) into your code. So I see this
as a nice way to take POJOs that are normal business objects or
services, devoid of any J2EE plumbing, and weave any J2EE aspects into
the code.
i.e. its separation of concerns for Java Code in a powerful way -
separating the business logic completely from the middleware & systems
programming J2EE code. This is why I see this as a separate layer /
module.
> Personally I don't care much (yet) about a service for users of the
> servers but I think it should be given some serious thoughts for
> container development.
Agreed. Though lets get the J2EE server ready first then lets figure
out how to weave J2EE aspects nicely into POJOs later on - or in a
separate parallel project.
Incidentally if there was gonna be some J2EE aspects, they should
hopefully be mostly J2EE standard apsects and so work with any J2EE
container right? So maybe its time for a separate AspectJ2ee project?
I'm sure Geronimo could eventually supply some custom Geronimo-specific
aspects later on down the road.
James
-------
http://radio.weblogs.com/0112098/
Re: Aspect based design ?
Posted by Stefan Arentz <st...@soze.com>.
On Thursday, August 7, 2003, at 19:30, James Strachan wrote:
[About an AOP service]
> However I see this as another aspect (forgive the pun) of the project
> - an alternative front end to Geronimo. We need to get the back end
> container working first. Then we can have some AOP project / module
> later on.
Isn't the main reason of using AOP that it makes the development of the
container much more easier? Personally I don't care much (yet) about a
service for users of the servers but I think it should be given some
serious thoughts for container development.
S.
Re: Aspect based design ?
Posted by James Strachan <ja...@yahoo.co.uk>.
On Thursday, August 7, 2003, at 05:51 pm, Dhananjay Nene wrote:
> Without getting into a debate of how Aspects will compete with or
> complement EJBs, would it be a good idea to at least discuss how
> aspects could be used to actually build much of the desired
> functionality. This surely would complicate things given that the
> project might be using a lot of source from initial contributions, but
> possibly a way could be found to continuously refactor the same over a
> period of time.I am not sure whether one needs to actually build an
> AOP engine like JBoss. Leveraging existing infrastructure (AspectJ /
> AspectWerkz / Nanning) might not be a bad idea.
I'm personally a big fan of AspectWerkz and Nanning since they work
using the Java language (rather than AspectJ which requires a new
language & compiler). Though thats another discussion. Both Jonas & Jon
(from AspectWerkz & Nanning) are aware of the Geronimo project & may
well get involved in building J2EE aspects some stage. Especially Jon
as now he's moved to London so I can drink beer with him :)
For now though we're focussing on the Geronimo - the container. Once
thats up and running & folks can see how the interceptor stack works &
things fit together - it should be very possible to start creating
aspects in any AOP engine - I'd personally recommend AspectWerkz (for
class based, bytecode weaving AOP) or Nanning (for interface based,
dynamic proxy AOP) - to take any POJO and weave J2EE aspects
(transactions, security, remoting, pooling, caching etc). I personally
think this makes J2EE much simpler to use for end users.
However I see this as another aspect (forgive the pun) of the project -
an alternative front end to Geronimo. We need to get the back end
container working first. Then we can have some AOP project / module
later on.
This kinda ties into the Avalon discussion somewhat. Various containers
out there have integrated AOP weaving at deployment time. e.g.
NanoContainer has a Nanning container which as components are dropped
into the container, aspects are weaved for you at deployment time. So
to bootstrap the whole thing we could just treat AOP stuff as a special
service we deploy inside Geronimo and then reuse some AOP aware
container of POJOs or whatever. The Avalon folks might wanna do
something similar too (if they've not already). So the AOP integration
could be a separate module.
But lets not run before we can walk...
James
-------
http://radio.weblogs.com/0112098/