geronimo and avalon?

[Leo Simons <le...@apache.org>]

...not right now, I think. Here's some more thoughts on that.

Hey gang,

okay, okay, I can't resist throwing in a few words about this. I've been 
an avalon committer for several years now, and I've used it for many if 
not all of my software projects ever since becoming 'infected' by it. So 
I am probably way biased.


Why build on avalon
-------------------
One answer: it's a solid, tried and tested Apache project with a lot of 
mature, tried and tested code and concepts that have been proven to work 
well in environments ranging from embedded devices to oracle clusters.

Another answer: it already integrates with a lot of projects that are 
likely to be on the shortlist for integration with Geronimo, like

* OpenEJB (drag-and-drop runs on top of avalon-phoenix (and avalon-merlin))

* Jetty and Tomcat (drag-and-drop run on top of avalon-phoenix (and 
avalon-merlin))

* James (has always run on top of and shipped with avalon-phoenix (and 
runs on avalon-merlin as well))

* HSQLDB (drag-and-drop runs on top of avalon-phoenix)

* several of the other important enterprise technologies can be added in 
as well rather easily if not out of the box, for example Axis (through 
the Ivory wrapper)

* MX4J (avalon-phoenix has builtin JMX support through MX4J)

* Log4J (avalon-phoenix can be configured to use log4j)

* Xerces (avalon-framework has an xml-based configuration system that 
usually is coupled to xerces)

another answer: avalon is all about server software architecture, and 
the general approach offered by the patterns it promotes (COP, 
Seperation of Concerns, Inversion of Control) is hands down the cleanest 
and most reliable way to build complex software. Those approaches are 
implemented well throughout avalon code. Really well.

Sounds compelling, doesn't it? So much so, in fact, someone did so for 
his graduation thesis (http://ichilli.sourceforge.net/, code not public 
though).


Wny not build on avalon
-----------------------
- While all those important components listed do integrate with avalon 
easily, they're for the most part not actually built with avalon (James 
being one notable exception).

- Avalon is at the moment a relatively small project (somewhere around 
20 committers I think) compared to what Geronimo is likely to be in 5 
months; it might be just as easy to just fork and/or rewrite it and not 
have such a big dependency at the very core of a project. (IMHO, one of 
the reasons for avalon never being used internal to tomcat. That, and 
several tomcat peeps disagreeing with some avalon design decisions).

- the current list of committers for geronimo doesn't include many 
people that have lots of experience with avalon, while there is a lot of 
people with experience in doing things differently (ie JMX-based like JBoss)

- Avalon has a relatively high learning curve. To gain all the 
cleanliness it provides, its security and its stability you need to know 
how to use it well; getting to grips with an IoC (Inversion of Control) 
setup is way more difficult at first than getting to grips with a 
central-registry style approach (JNDI, JMX, etc).

- Avalon imposes strict contracts. You have to do lots of stuff in the 
way the avalon design dictates you to. (well, usually, you don't, 
really, but most peeps, including avalon regulars, disagree with me on 
that :D)

- a lot of the avalon folk have always complained heavily about the 
limitations of EJBs, so much so in fact that they have written an 
avalon-based alternative (www.enterpriseobjectbroker.org) to show how 
much better the world is without EJB.

- the avalon mindset seems to behave rather virally. Once people become 
convinced that IoC is the way to go, they never go back.

- there is already an initial codebase that doesn't use it, and we want 
to go forward with that. Refactoring around avalon would delay a first 
release by miles.

Conclusion
----------
Nope, no conclusion. Well, the only significant one perhaps is that 
building a J2EE suite on top of the framework avalon provides is 
definately possible. I am not going to get mingled in the debate of 
whether that is a good idea (me, I think a JMX-based microkernel remains 
a bad idea, even though it is working so well for JBoss. But that's just 
me ;).

Just know some of the avalon regular are listening in with an interested 
ear to hear what's all the fuzz about ye olde Indian war chief, and 
we're more than willing to help you evaluate what stuff (if any) you 
want to use from the avalon project. And we can probably leave y'all 
completely alone, too, if desired ;)


Deal with the big things first
------------------------------
I suggest everyone waits for a few weeks 'till the first bits of code 
are here, knowledge has been gained and the project has been 
'bootstrapped', before raising the topic again. I don't think its 
healthy (and I mean for geronimo *and* avalon, in case anyone wonders) 
if people go saying "geronimo really should use avalon" nor "that is 
absolutely out of the question" before you guys get some other things 
settled first. You can always change your mind later.

But again, that's just me, known for being off the mark :D


cheers,

- Leo

Pluggable CMP (Re: Persistence framework)

[Stefan Arentz <st...@soze.com>]

On Thursday, August 7, 2003, at 18:18, Tim O'Brien wrote:

> This might be a tougher question to answer than Tomcat, Jetty 
> integration,
> but one thing that would be desirable would be a pluggable strategy for
> CMP.
>
> Does the current archtecture include any provisions for a pluggable
> persistence layer - i.e. using Castor, Hibernate, or OJB depending on 
> your
> preference?

I agree that pluggable persitence engines are important, but do not 
forget that this is to be a J2EE server; it has to follow the spec. I 
think it is far more important that the server follows the current CMP 
and JDO specs instead of already looking to much at all the different 
implementations as listed above.

  S.

Persistence framework

[Tim O'Brien <to...@discursive.com>]

This might be a tougher question to answer than Tomcat, Jetty integration, 
but one thing that would be desirable would be a pluggable strategy for 
CMP.

Does the current archtecture include any provisions for a pluggable 
persistence layer - i.e. using Castor, Hibernate, or OJB depending on your 
preference?

The traffic to code ratio on this project is currently "infinity".   
What is the timeframe for getting code into the "incubator-general" 
module?  It is great that so many people have sent in resumes, but all 
this attention for a code-less project seems like wasted energy.  Where's 
the beef? 

Tim

Re: JMX as a kernel

[Bill de hÓra <bi...@dehora.net>]

Leo Simons wrote:


> 2) no isolation. Services running in a kernel should be very much seperated
> from each other. JMX has domains, but those are just a namespacing
> convenience last time I checked.

This is important imo. If Geronimo goes with JMX, it may want to 
leave some wiggle room for using Isolates in the future, either 
directly or if JMX ever upgraded to use them.

Bill de hÓra

RE: JMX as a kernel (was: Re: geronimo and avalon?)

[Michael Remijan <re...@ncsa.uiuc.edu>]

I completely agree with configuring MBeans becomes ad-hoc ugliness.  JBoss 
has done a good job trying to clean up the server's configuration files but 
they are still difficult.  The main problem is that MBeans configurations 
do not need to adhear to a DTD or Schema.  That makes it very difficult to 
find out what can be put in the configuration file in the first place.

Mike


At 11:33 AM 8/8/2003 -0400, Howard M. Lewis Ship wrote:
>I'm going to plug HiveMind again here.
>
>Looking over what JBoss has done with JMX as a Microkernel, I have a 
>couple of key issues.
>
>First off, the code abstraction that requires you to invoke methods on 
>MBeans using an interface
>like reflection.  Yes, there are workarounds to that (such as using 
>dynamic Proxys) but if a Java
>object is invoking a method on another Java object within the same JVM why 
>make it look like some
>low-level RPC call?
>
>Second, configuration of MBeans leaves a bit to be desired.  I suppose it 
>works well for simple
>properties, but once you get to anything complicated, you start seeing 
>more and more ad-hoc
>ugliness.  Among other things, you end up endlessly rehashing the code to 
>translate an MBean name
>into an instance that methods can be invoked on.
>
>Intrinsic to HiveMind are concepts adapted from Eclipse Plugins: extension 
>points and extensions.
>Extension points define a point where modules can plug into other modules; 
>an extension point
>defines a kind of XML schema for contributions.  Extensions are snippets 
>of XML that plug into
>extension points.
>
>The end result is something very flexible, and very supportive of a very 
>complex environment, yet
>very "lean and mean" at the same time.
>
>http://jakarta.apache.org/commons/sandbox/hivemind
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/tapestry
>
>
>
> > -----Original Message-----
> > From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
> > Sent: Friday, August 08, 2003 8:55 AM
> > To: geronimo-dev@incubator.apache.org
> > Subject: Re: JMX as a kernel (was: Re: geronimo and avalon?)
> >
> >
> >
> > On Friday, Aug 8, 2003, at 13:05 Europe/London, Leo Simons wrote:
> >
> > > Why JMX Is Not A Very Good Kernel
> > > ------------------
> >
> > I'd definitely concur with this. Put it better than I could
> > have done,
> > too :-)
> >
> > Note that just because JMX isn't a kernel, doesn't mean that
> > some parts
> > of it can't be configured with JMX on top. It just means that not
> > everything has to be JMX.
> >
> > Building a tighter smaller kernel gives me a gut feeling that it will
> > run faster, though I've yet to convert that into measurable
> > figures :-)
> > But reducing (unnecessary) layers is bound to speed it up...
> >
> > One fear I have of using JMX as a kernel is that all the intra-kernel
> > messages would be sent using JMX. If JMX isn't used in the
> > kernel, then
> > they can be made more efficient/optimised; but JMX can be put as a
> > layer on top of the features (e.g. EJBs) that need
> > configuring/managing
> > by JMX.
> >
> > Definitely vote +1 for not using JMX 'just because'
> >
> > Alex.
> >

Re: JMX as a kernel (was: Re: geronimo and avalon?)

[Berin Loritsch <bl...@apache.org>]

Bruce Snyder wrote:

> AB>Unfortunately, the isA/hasA debate is something that can run and run 
> AB>and run, and since the initial code seed has gone with JMX then it 
> AB>seems very difficult to nudge that another way. But a more generic 
> AB>container framework (the likes of 
> AB>Avalon/Merlin/Hivemind/Eclipse-Plugin-Style) that /has/ a JMX interface 
> AB>would be a 'cleaner' approach from an OO perspective.
> 
> A very interesting point here, Alex.

In my experience with components, the distinction is more along the lines
of usesA/containsA.

Well designed components do one thing, and do it well.  All other functions
are relegated to other components.  Now with a component based design, we
have new distinctions to look at.

You still have the OOD ways of extending the system: extending classes/
implementing interfaces.  You also have two new ways to refer to how one
component interacts with other components.  Due to the nature of a component's
late binding (by design), the only choice for one component using other
components is to either _use_ one that is provided or _contain_ one inside
of it.

Using Cocoon as an example: if I have a DirectoryGenerator I can extend it
so that it reports image types and dimensions calling it an
ImageDirectoryGenerator.  It IS a Generator (impementing the interface), and
it IS a DirectoryGenerator (extending the base class).

Additionally the code that checks a File reference to see if it is an image,
and what dimensions it has, that code can be made into a component.  Advantages
and disadvantages of the approach are ignored for the time being.  By allowing
the parent container to control that component would mean that the
ImageDirectoryGenerator needs to look up the component and use it.  I.e. the
_uses_a_ approach.  It can be argued that the only place in the entire system
that would use the component is encapsulated inside the ImageDirectoryGenerator,
so that would encapsulate the component.  I.e. analogous to the "has a"
relationship in OOD.

The "Uses A" relationship is far more useful and common in component
architectures.  If you ignore this relationship, then you are no longer using
components--you are just using structured OOD.

Late binding is a very powerful feature, which allows us to not only completely
replace one component for another, but also allows us to add in aspects such
as instrumentation, security, etc. all without altering the original component
code or the client code.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

Re: JMX as a kernel (was: Re: geronimo and avalon?)

["Weston M. Price" <we...@yahoo.com>]

And one time...at band camp.....


Does anyone want me to go on?

Weston
On Monday 11 August 2003 04:40 pm, Alex Blewitt wrote:
> On Monday, Aug 11, 2003, at 17:17 Europe/London, Bruce Snyder wrote:
> > This one time, at band camp, Alex Blewitt said:
>
> Band camp? I've never been to band camp.
>
> :-)
> :
> > AB>Lastly, if the focus is on 'The kernel is JMX' then that may
> > AB>unnecessarily affect design decisions: 'Hey, lets use MBeans
> > defined in
> > AB>XML on a single flat file'. We could follow JBoss' example and do
> > this;
> > AB>or we could be more innovative, using a configuration registry
> > backed
> > AB>with JNDI/LDAP, whilst still providing a Management interface over
> > JMX.
> >
> > I was actually thinking about another discussion discussing the storage
> > of configuration metadata in some type of respository. The first thing
> > that comes to my mind is a solution accessible via JNDI and backed by
> > anything that is JNDI accessible. LDAP would be my first choice as
> > well,
> > but because not every environment can deal with LDAP, the JNDI
> > interface
> > allows anything to be implemented. This need could certainly be met by
> > the
> > LDAPd project which is currently trying to become an Incubator project.
>
> Yeah, I'd agree that JNDI makes the most sense as a registry front end,
> and that an LDAP implementation would be the best service for that. And
> I'd definitely vote for an LDAP storage engine inside Geronimo.
>
> See also
> http://nagoya.apache.org/wiki/apachewiki.cgi?ConfigurationAsRegistry
> for more comments about this list; feel free to add comments in there
> to the LDAP/LDAPd project as appropriate.
>
> Alex.

Re: JMX as a kernel (was: Re: geronimo and avalon?)

[Alex Blewitt <Al...@ioshq.com>]

On Monday, Aug 11, 2003, at 17:17 Europe/London, Bruce Snyder wrote:

> This one time, at band camp, Alex Blewitt said:

Band camp? I've never been to band camp.

:-)

> AB>Lastly, if the focus is on 'The kernel is JMX' then that may
> AB>unnecessarily affect design decisions: 'Hey, lets use MBeans 
> defined in
> AB>XML on a single flat file'. We could follow JBoss' example and do 
> this;
> AB>or we could be more innovative, using a configuration registry 
> backed
> AB>with JNDI/LDAP, whilst still providing a Management interface over 
> JMX.
>
> I was actually thinking about another discussion discussing the storage
> of configuration metadata in some type of respository. The first thing
> that comes to my mind is a solution accessible via JNDI and backed by
> anything that is JNDI accessible. LDAP would be my first choice as 
> well,
> but because not every environment can deal with LDAP, the JNDI 
> interface
> allows anything to be implemented. This need could certainly be met by 
> the
> LDAPd project which is currently trying to become an Incubator project.

Yeah, I'd agree that JNDI makes the most sense as a registry front end, 
and that an LDAP implementation would be the best service for that. And 
I'd definitely vote for an LDAP storage engine inside Geronimo.

See also 
http://nagoya.apache.org/wiki/apachewiki.cgi?ConfigurationAsRegistry 
for more comments about this list; feel free to add comments in there 
to the LDAP/LDAPd project as appropriate.

Alex.

Re: JMX as a kernel (was: Re: geronimo and avalon?)

[Bruce Snyder <fe...@frii.com>]

This one time, at band camp, Alex Blewitt said:

AB>On Monday, Aug 11, 2003, at 07:07 Europe/London, Weston M. Price wrote:
AB>
AB>> I agree with Gareth,I am not quite sure of why JMX would not be used, 
AB>> or would
AB>> be replaced at some other time.
AB>>
AB>> On Monday 11 August 2003 09:28 am, Gareth Bryan wrote:
AB>>>> On Mon, 11 Aug 2003 04:40:40 -0400, "Noel J. Bergman" 
AB>>>> <no...@devtech.com>
AB>>>> said:
AB>>>>
AB>>>> Jason Dillon wrote:
AB>>>>> we will eventually want to replace the JMX bus with a more
AB>>>>> robust component system.
AB>>>>
AB>>>> The sense I am getting from the list is that there is a decent sized 
AB>>>> base
AB>>>> of
AB>>>> people who agree with you, and who see JMX as an interface TO a 
AB>>>> component
AB>>>> system, not AS the component system.
AB>>>
AB>>> I get that sense aswell, although personally, I haven't spoken up 
AB>>> about
AB>>> it before now because I wanted to take a look at the seed code. My
AB>>> initial opinion is that I'd like to see some hard evidence for the
AB>>> drawbacks for using JMX, putting it another way: I'm a +1 for JMX at 
AB>>> the
AB>>> moment.
AB>
AB>A number of people are saying 'Lets go with the JMX bus until another 
AB>choice is made later'. The question is, why was the JMX bus chosen in 
AB>the first place? Because other implementations (e.g. JBoss) used that 
AB>approach.
AB>
AB>The problem is that JMX was designed as an interface to allow remote 
AB>programs to manage/start/stop services on a remote machine using an 
AB>arbitrary client. JBoss does as much in its administration console, 
AB>which is nothing more than a glorified send-a-JMX-message system.
AB>
AB>The other reason why JMX is used as the initial bus is that J2EE must 
AB>have a JMX interface. That said, it doesn't need to be implemented 
AB>using JMX (in much the same way that we don't need to build a J2EE 
AB>server using CORBA although CORBA requests may/must be supported).
AB>
AB>Unfortunately, the isA/hasA debate is something that can run and run 
AB>and run, and since the initial code seed has gone with JMX then it 
AB>seems very difficult to nudge that another way. But a more generic 
AB>container framework (the likes of 
AB>Avalon/Merlin/Hivemind/Eclipse-Plugin-Style) that /has/ a JMX interface 
AB>would be a 'cleaner' approach from an OO perspective.

A very interesting point here, Alex.

...

AB>Lastly, if the focus is on 'The kernel is JMX' then that may 
AB>unnecessarily affect design decisions: 'Hey, lets use MBeans defined in 
AB>XML on a single flat file'. We could follow JBoss' example and do this; 
AB>or we could be more innovative, using a configuration registry backed 
AB>with JNDI/LDAP, whilst still providing a Management interface over JMX.

I was actually thinking about another discussion discussing the storage
of configuration metadata in some type of respository. The first thing
that comes to my mind is a solution accessible via JNDI and backed by
anything that is JNDI accessible. LDAP would be my first choice as well,
but because not every environment can deal with LDAP, the JNDI interface
allows anything to be implemented. This need could certainly be met by the
LDAPd project which is currently trying to become an Incubator project.

Bruce
-- 
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'

Re: Dynamic MBeans. Was: Kernel Architecture

[Berin Loritsch <bl...@apache.org>]

James Strachan wrote:

>> Why can't we go for a totally dynamic MBean model?
> 
> 
> We absolutely could. I was trying to just come up with a simple 
> convention component authors could follow - though we should be flexible.
> 
>> Ie - for a given FooService, why do we need to write a FooServiceMBean
>> interface that just has the methods we wish to expose?
> 
> 
> No reason why we couldn't do that. Could use XDoclet or an XML config 
> file or some clever build process to generate the MBean or dynamic 
> MBeans whatever.

Hmmm. Avalon Pheonix currently does this.  We might be able to adapt what
is there and use it here.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

Re: Dynamic MBeans. Was: Kernel Architecture

[Alex Blewitt <Al...@ioshq.com>]

On Tuesday, Aug 12, 2003, at 14:20 Europe/London, James Strachan wrote:

>
> On Tuesday, August 12, 2003, at 02:07  pm, Greg Wilkins wrote:
>>>> But by creating (and calling) them MBeans, you are tying it down to 
>>>> a naming convention expected by JMX which may confuse the issue 
>>>> later.
>>> Why? Whats confusing about it? Why would inventing yet-another-API 
>>> be any less confusing?
>>
>> Why can't we go for a totally dynamic MBean model?
>
> We absolutely could. I was trying to just come up with a simple 
> convention component authors could follow - though we should be 
> flexible.

What about creating an interface, say, ManagedComponent, that component 
authors could implement? Then we can move any JMX/MBean specific 
behavoir into that interface (or an AbstractManagedComponent abstract 
class) and let developers subclass that?

A convention like XxxComponent or XxxService may also be more 
meaningful to developers. Are there any other major types of code in a 
server? XxxAgent, Xxx??? If we can have placeholders for these, then 
future components can be described as one (many?) of these.

>> Ie - for a given FooService, why do we need to write a FooServiceMBean
>> interface that just has the methods we wish to expose?
>
> No reason why we couldn't do that. Could use XDoclet or an XML config 
> file or some clever build process to generate the MBean or dynamic 
> MBeans whatever.

Yes, having an externalised/automatically generated MBean is probably a 
good way to go.

>> I think we should be able to just create the FooService objects
>> and then describe any MBeans we want for them in XML - describing
>> the methods and the meta data in one spot.
>>
>> If we decide not to use MBeans, then we still have our FooService
>> objects and we have no FooServiceMBean objects clutering up the
>> repository.
>
> I'm cool with alternative forms of getting to the same place. i.e. 
> however the MBeans are written - whether they are just POJOs or beans 
> and we adorn them to be MBeans or we follow the MBean interface or we 
> use some XML deployment descriptor for the MBean metadata - I'm easy. 
> It can then be the developers choice.
>
> I personally quite like the MBean interface idea as it makes 
> refactoring easier and your code has no dependencies on JMX - though 
> we should be able to use better / simpler mechanisms for this.

IMHO the naming convention of MBean does tie it down, though; from the 
JMX spec:

JMX_1-2 p37: "The name of an MBean's Java interface is formed by adding 
the 'MBean' suffix to the MBean's fully qualified Java class name. For 
example, the Java class MyClass would implement the MyClassMBean 
interface"

Not having the naming convention would then make it clearer if MBeans 
were not to be used later. However, the principles of still having the 
getters/setters is a clear and easy step for developers to be able to 
interact with it, in whatever means.

>> If we decide to use MBeans - it means that we will have fewer
>> undocumented MBeans without real meta data.  We can also expose
>> more of an object simply by changing the MBean descriptor file.
>
> Agreed.

Externalising the MBean descriptors (and the subsequent automatically 
generated code) might be a way of implementing security as an aspect on 
top of that?

Alex.

Re: Dynamic MBeans. Was: Kernel Architecture

[James Strachan <ja...@yahoo.co.uk>]

On Tuesday, August 12, 2003, at 02:07  pm, Greg Wilkins wrote:
> James Strachan wrote:
>
>>>> An interface based MBean is just a naming convention. There is no 
>>>> tying to anything. Indeed there's not even a dependency on JMX 
>>>> never mind any other container API. Then the container is totally 
>>>> free to go in whatever direction it wishes.
>>>
>>>
>>> But by creating (and calling) them MBeans, you are tying it down to 
>>> a naming convention expected by JMX which may confuse the issue 
>>> later.
>> Why? Whats confusing about it? Why would inventing yet-another-API be 
>> any less confusing?
>
>
> Why can't we go for a totally dynamic MBean model?

We absolutely could. I was trying to just come up with a simple 
convention component authors could follow - though we should be 
flexible.

> Ie - for a given FooService, why do we need to write a FooServiceMBean
> interface that just has the methods we wish to expose?

No reason why we couldn't do that. Could use XDoclet or an XML config 
file or some clever build process to generate the MBean or dynamic 
MBeans whatever.


> This is the simplest form of MBean, but contains no meta data to
> describe that MBean - which has to be placed in an xml file elsewhere.

Agreed - though at least it works :). i.e. its the minimum requirement 
for a component/service author.


> I think we should be able to just create the FooService objects
> and then describe any MBeans we want for them in XML - describing
> the methods and the meta data in one spot.
>
> If we decide not to use MBeans, then we still have our FooService
> objects and we have no FooServiceMBean objects clutering up the
> repository.

I'm cool with alternative forms of getting to the same place. i.e. 
however the MBeans are written - whether they are just POJOs or beans 
and we adorn them to be MBeans or we follow the MBean interface or we 
use some XML deployment descriptor for the MBean metadata - I'm easy. 
It can then be the developers choice.

I personally quite like the MBean interface idea as it makes 
refactoring easier and you're code has no dependencies on JMX - though 
we should be able to use better / simpler mechanisms for this.


> If we decide to use MBeans - it means that we will have fewer
> undocumented MBeans without real meta data.  We can also expose
> more of an object simply by changing the MBean descriptor file.

Agreed.

James
-------
http://radio.weblogs.com/0112098/

Re: Dynamic MBeans. Was: Kernel Architecture

[Jens Schumann <je...@void.fm>]

On 8/12/03 06:10 PM Berin Loritsch <bl...@apache.org> wrote:

> Jens Schumann wrote:
>
>> I agree with you. However I still don't get the point why relying on JMX is
>> a critical factor, and usage of jakarta-commons* is considered harmful. JMX
>> is a specification and it is up to you to implement it.
> 
> Umm, I don't recall saying anything about jakarta-commons*.  I use code from
> there, and in general it is usually pretty good stuff.

Just an analogy. The only reason I switched from silently reading this ML to
posting a few comments is that I see a certain resistance to certain topics
just because religious reasons or something (and I don't say you did that;),
while other areas are out of discussion. Jakarta-commons* is one of those,
and to be honest, jakarta-commons* is a one way street with no return. And
it is not just me who believes in that;).

>> See above, it is a specification. And I don't say JMX based is the only
>> solution. But I believe most people here on the list talk about the
>> instrumentation level only.
> 
> I understand that JMX is a specification.  The only major real damage that
> I see here is one of the golden hammer.  The temptation with any new tool
> is to go hog wild with it.  I am usually much more conservative, and introduce
> the tool where I think it would help.  IOW, I start small.  Since JMX already
> has a place where it lends a big help, I am resistent to endorsing a path
> where
> it is the *only* solution.  As long as we can make it *one* solution out of
> many, I will happily shut my trap.
> 
> Since you mentioned moving back and forth between JMX enabled and JMX
> based is bad, that is yet another red flag that maybe we don't want to
> go down that road.  But that is my conservative side talking.  I'm not
> going to get in the way if you hell bent on going that direction.  I'm
> just trying to find some balance here.

And I am on the other side;). JMX is there a couple of years. And I have to
admit that I love the power of JMX in loosely coupled component based
systems. While following the discussion here I felt some pain reading about
instrumentation only, so please consider taking a look at the agent services
provided through JMX. If they are worth nothing just ignore my posts.

In the end raising the red flag is valid, since switching back to JMX
enabled will be painful to impossible, as it is for switching to a JMX based
solution at some point.

Jens 

Re: Dynamic MBeans. Was: Kernel Architecture

[Berin Loritsch <bl...@apache.org>]

Jens Schumann wrote:

>>Von: Berin Loritsch <bl...@apache.org>
>>Antworten an: geronimo-dev@incubator.apache.org
>>Datum: Tue, 12 Aug 2003 11:39:44 -0400
>>An: geronimo-dev@incubator.apache.org
>>Betreff: Re: Dynamic MBeans. Was: Kernel Architecture
>>
>>Jens Schumann wrote:
>>
>>The thing is that there are certain compromises in the all-in-one box that
>>you have no control over.  Usually the manufacturers of these boxes can only
>>spend money on one part of it, and they skimp on the rest.  So it may have
>>a good tape player, but the CD player sucks (or vice versa).
> 
> 
> I agree with you. However I still don't get the point why relying on JMX is
> a critical factor, and usage of jakarta-commons* is considered harmful. JMX
> is a specification and it is up to you to implement it.

Umm, I don't recall saying anything about jakarta-commons*.  I use code from
there, and in general it is usually pretty good stuff.

> 
> 
>>>In the end it all boils down to whether a system is JMX enabled or JMX
>>>based. Interestingly most projects I have seen moved to JMX enabled at some
>>>stage, since too much stuff was maintained in parallel. However the
>>>transition from one to the other model is something you should avoid (just
>>>take a look at tomcat 5).
>>
>><shudder/>
>>
>>Seriously though, I would much prefer to have JMX enabled than JMX based,
>>as we can have more fine tuned control where we need it.  The JMX dynamic
>>classloading might be something causing problems instead of solving them.
>>If that happens, what is your recourse?
> 
> 
> See above, it is a specification. And I don't say JMX based is the only
> solution. But I believe most people here on the list talk about the
> instrumentation level only.

I understand that JMX is a specification.  The only major real damage that
I see here is one of the golden hammer.  The temptation with any new tool
is to go hog wild with it.  I am usually much more conservative, and introduce
the tool where I think it would help.  IOW, I start small.  Since JMX already
has a place where it lends a big help, I am resistent to endorsing a path where
it is the *only* solution.  As long as we can make it *one* solution out of
many, I will happily shut my trap.

Since you mentioned moving back and forth between JMX enabled and JMX
based is bad, that is yet another red flag that maybe we don't want to
go down that road.  But that is my conservative side talking.  I'm not
going to get in the way if you hell bent on going that direction.  I'm
just trying to find some balance here.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

Re: Dynamic MBeans. Was: Kernel Architecture

[Jens Schumann <je...@void.fm>]

> Von: Berin Loritsch <bl...@apache.org>
> Antworten an: geronimo-dev@incubator.apache.org
> Datum: Tue, 12 Aug 2003 11:39:44 -0400
> An: geronimo-dev@incubator.apache.org
> Betreff: Re: Dynamic MBeans. Was: Kernel Architecture
> 
> Jens Schumann wrote:
> 
> The thing is that there are certain compromises in the all-in-one box that
> you have no control over.  Usually the manufacturers of these boxes can only
> spend money on one part of it, and they skimp on the rest.  So it may have
> a good tape player, but the CD player sucks (or vice versa).

I agree with you. However I still don't get the point why relying on JMX is
a critical factor, and usage of jakarta-commons* is considered harmful. JMX
is a specification and it is up to you to implement it.

>> In the end it all boils down to whether a system is JMX enabled or JMX
>> based. Interestingly most projects I have seen moved to JMX enabled at some
>> stage, since too much stuff was maintained in parallel. However the
>> transition from one to the other model is something you should avoid (just
>> take a look at tomcat 5).
> 
> <shudder/>
> 
> Seriously though, I would much prefer to have JMX enabled than JMX based,
> as we can have more fine tuned control where we need it.  The JMX dynamic
> classloading might be something causing problems instead of solving them.
> If that happens, what is your recourse?

See above, it is a specification. And I don't say JMX based is the only
solution. But I believe most people here on the list talk about the
instrumentation level only.

Jens 

Re: Dynamic MBeans. Was: Kernel Architecture

[Berin Loritsch <bl...@apache.org>]

Jens Schumann wrote:

>>MBean != interface, and we should never use them as such.  By following that
>>mantra, dynamic MBeans becomes a viable tool with few drawbacks.
> 
> 
> Well, this is true if you talk about the instrumentation level only. But if
> you trust in JMX agents for application management you are moving towards
> the MBean == interface analogy. In my opinion JMX offers a lot more than
> management, stuff you need to implement anyway: Dynamic Classloading,
> Notifications, Monitoring, Relations and Lifecycle of components.

My alarm bells go off every time I hear that an object should ever be considered
synonymous with a simple interface.

All of those other aspects: dynamic classloading, notifications, monitoring,
etc. can be addressed by other means--many times more effectively.

I get nervous when I here something slices, dices, makes julian fries, and
will not break (oops! it broke).  That combination hooka and coffie maker
(get the movie reference now?) might better be served with different mechanisms.

For example, in the world of audio and home entertainment systems, you have
two camps:

1) The all in one jobbies--usually less expensive
2) Component systems--usually more expensive

The thing is that there are certain compromises in the all-in-one box that
you have no control over.  Usually the manufacturers of these boxes can only
spend money on one part of it, and they skimp on the rest.  So it may have
a good tape player, but the CD player sucks (or vice versa).

With the component systems, you can get exactly what you want for the job
at hand.  If you don't want a tape player, you don't have to buy one.  If
you really care about your CD player, you can spend money on a good one.
In other words, if something isn't up to snuff you have the ability to swap
it out at any time for a better component.  You aren't stuck with what the
initial manufacturer decided was best for you.


> In the end it all boils down to whether a system is JMX enabled or JMX
> based. Interestingly most projects I have seen moved to JMX enabled at some
> stage, since too much stuff was maintained in parallel. However the
> transition from one to the other model is something you should avoid (just
> take a look at tomcat 5).

<shudder/>

Seriously though, I would much prefer to have JMX enabled than JMX based,
as we can have more fine tuned control where we need it.  The JMX dynamic
classloading might be something causing problems instead of solving them.
If that happens, what is your recourse?


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

Re: Dynamic MBeans. Was: Kernel Architecture

[Jens Schumann <je...@void.fm>]

> Von: Berin Loritsch <bl...@apache.org>
>
> 
> Consider for a moment the purpose of MBeans.  They are to allow a management
> console to control aspects of your software.  So they were originally created
> to provide an end user a way to control the guts of software.  They were not
> created to provide a direct programmatic interface to the underlying software.
> 
> So if you lookup your components and access them by a direct Java interface,
> then you can easily remote that component, control the inheritance structure,
> and still have the benefit of what JMX was designed for.
> 

I think it depends on how much of your application is moved to the JMX
model. If you use it as a simple add on (which was the initial intend of
JMX, and it looks like you are moving towards that direction) then I would
agree. But the JMX spec also contains the agent specification, and thus
being said manageable aspects of software can (and in my opinion should) be
much more than providing a simple management interface to application
components. 

> MBean != interface, and we should never use them as such.  By following that
> mantra, dynamic MBeans becomes a viable tool with few drawbacks.

Well, this is true if you talk about the instrumentation level only. But if
you trust in JMX agents for application management you are moving towards
the MBean == interface analogy. In my opinion JMX offers a lot more than
management, stuff you need to implement anyway: Dynamic Classloading,
Notifications, Monitoring, Relations and Lifecycle of components.

In the end it all boils down to whether a system is JMX enabled or JMX
based. Interestingly most projects I have seen moved to JMX enabled at some
stage, since too much stuff was maintained in parallel. However the
transition from one to the other model is something you should avoid (just
take a look at tomcat 5).


Jens

Re: Dynamic MBeans. Was: Kernel Architecture

[Berin Loritsch <bl...@apache.org>]

Jens Schumann wrote:

>>Von: Greg Wilkins <gr...@mortbay.com>
>>
>>
>>Why can't we go for a totally dynamic MBean model?
>>
> 
> 
> Just a few thoughts:
> 
> - With JMX 1.2 (maybe with 1.1, can't remember when SimpleMBeans where
> introduced) you get meta data for SimpleMBeans.
> - With dynamic Mbeans you loose your concrete interface, and with it a
> simple way to create proxies to them (remote access etc.)
> - Don't forget inheritance - in my opinion pretty dangerous by using Dynamic
> MBeans.

Consider for a moment the purpose of MBeans.  They are to allow a management
console to control aspects of your software.  So they were originally created
to provide an end user a way to control the guts of software.  They were not
created to provide a direct programmatic interface to the underlying software.

So if you lookup your components and access them by a direct Java interface,
then you can easily remote that component, control the inheritance structure,
and still have the benefit of what JMX was designed for.

MBean != interface, and we should never use them as such.  By following that
mantra, dynamic MBeans becomes a viable tool with few drawbacks.

Remember, JMX is a tool but a golden hammer it is not.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

Re: Dynamic MBeans. Was: Kernel Architecture

[Jens Schumann <je...@void.fm>]

> Von: Greg Wilkins <gr...@mortbay.com>
> 
> 
> Why can't we go for a totally dynamic MBean model?
> 

Just a few thoughts:

- With JMX 1.2 (maybe with 1.1, can't remember when SimpleMBeans where
introduced) you get meta data for SimpleMBeans.
- With dynamic Mbeans you loose your concrete interface, and with it a
simple way to create proxies to them (remote access etc.)
- Don't forget inheritance - in my opinion pretty dangerous by using Dynamic
MBeans.

Jens

Re: Dynamic MBeans. Was: Kernel Architecture

[David Jencks <da...@snappydsl.net>]

Using model mbeans instead of standard mbeans has many advantages.  As 
I recall someone (Simone?) offered to write an xmbean model mbean for 
mx4j.  We can use the xdoclet JBoss xmbean template as a starting point 
and generate the xml descriptor from the source.

For now we can generate standard mbean interfaces and, when we get an 
xmbean impl.  switch over with minimal  effort.  Including appropriate 
documentation now will make the switch easier.

Is xdoclet being used in the current build system?

david jencks

On Tuesday, August 12, 2003, at 09:07 AM, Greg Wilkins wrote:

>
>
> James Strachan wrote:
>
>>>> An interface based MBean is just a naming convention. There is no 
>>>> tying to anything. Indeed there's not even a dependency on JMX 
>>>> never mind any other container API. Then the container is totally 
>>>> free to go in whatever direction it wishes.
>>>
>>>
>>> But by creating (and calling) them MBeans, you are tying it down to 
>>> a naming convention expected by JMX which may confuse the issue 
>>> later.
>> Why? Whats confusing about it? Why would inventing yet-another-API be 
>> any less confusing?
>
>
> Why can't we go for a totally dynamic MBean model?
>
> Ie - for a given FooService, why do we need to write a FooServiceMBean
> interface that just has the methods we wish to expose?
>
> This is the simplest form of MBean, but contains no meta data to
> describe that MBean - which has to be placed in an xml file elsewhere.
>
> I think we should be able to just create the FooService objects
> and then describe any MBeans we want for them in XML - describing
> the methods and the meta data in one spot.
>
> If we decide not to use MBeans, then we still have our FooService
> objects and we have no FooServiceMBean objects clutering up the
> repository.
>
> If we decide to use MBeans - it means that we will have fewer
> undocumented MBeans without real meta data.  We can also expose
> more of an object simply by changing the MBean descriptor file.
>
>
> -- 
> Greg Wilkins<gr...@mortbay.com>             Phone/fax: +44 7092063462
> Mort Bay Consulting Australia and UK.          http://www.mortbay.com
>

Re: Dynamic MBeans. Was: Kernel Architecture

[Alex Blewitt <Al...@ioshq.com>]

On Tuesday, Aug 12, 2003, at 14:07 Europe/London, Greg Wilkins wrote:

> James Strachan wrote:
>
>>>> An interface based MBean is just a naming convention. There is no 
>>>> tying to anything. Indeed there's not even a dependency on JMX 
>>>> never mind any other container API. Then the container is totally 
>>>> free to go in whatever direction it wishes.
>>> But by creating (and calling) them MBeans, you are tying it down to 
>>> a naming convention expected by JMX which may confuse the issue 
>>> later.
>> Why? Whats confusing about it? Why would inventing yet-another-API be 
>> any less confusing?
>
> Why can't we go for a totally dynamic MBean model?

Yes, this is precisely the kind of thing I was working towards. In the 
code sample posted earlier, I wanted to demonstrate how it could be 
done to avoid dependency on the JMX spec of calling things MBean, but 
still provide that as a service. There's no reason why it couldn't be 
achieved using a dynamic interface instead.

> This is the simplest form of MBean, but contains no meta data to
> describe that MBean - which has to be placed in an xml file elsewhere.
>
> If we decide not to use MBeans, then we still have our FooService
> objects and we have no FooServiceMBean objects clutering up the
> repository.

Yes, the less clutter (and dependency on MBeans) the better.

> If we decide to use MBeans - it means that we will have fewer
> undocumented MBeans without real meta data.  We can also expose
> more of an object simply by changing the MBean descriptor file.

Agree completely.

Alex.

Dynamic MBeans. Was: Kernel Architecture

[Greg Wilkins <gr...@mortbay.com>]

James Strachan wrote:

>>> An interface based MBean is just a naming convention. There is no 
>>> tying to anything. Indeed there's not even a dependency on JMX never 
>>> mind any other container API. Then the container is totally free to 
>>> go in whatever direction it wishes.
>>
>>
>> But by creating (and calling) them MBeans, you are tying it down to a 
>> naming convention expected by JMX which may confuse the issue later.
> 
> 
> Why? Whats confusing about it? Why would inventing yet-another-API be 
> any less confusing?


Why can't we go for a totally dynamic MBean model?

Ie - for a given FooService, why do we need to write a FooServiceMBean
interface that just has the methods we wish to expose?

This is the simplest form of MBean, but contains no meta data to
describe that MBean - which has to be placed in an xml file elsewhere.

I think we should be able to just create the FooService objects
and then describe any MBeans we want for them in XML - describing
the methods and the meta data in one spot.

If we decide not to use MBeans, then we still have our FooService
objects and we have no FooServiceMBean objects clutering up the
repository.

If we decide to use MBeans - it means that we will have fewer
undocumented MBeans without real meta data.  We can also expose
more of an object simply by changing the MBean descriptor file.


-- 
Greg Wilkins<gr...@mortbay.com>             Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK.          http://www.mortbay.com

Re: Kernel Architecture

[Alex Blewitt <Al...@ioshq.com>]

On Tuesday, Aug 12, 2003, at 14:42 Europe/London, James Strachan wrote:

>
> On Tuesday, August 12, 2003, at 02:17  pm, Alex Blewitt wrote:
>> On Tuesday, Aug 12, 2003, at 12:54 Europe/London, James Strachan 
>> wrote:
>>> On Tuesday, August 12, 2003, at 12:27  pm, Alex Blewitt wrote:
>>>>
>>>> But by creating (and calling) them MBeans, you are tying it down to 
>>>> a naming convention expected by JMX which may confuse the issue 
>>>> later.
>>>
>>> Why? Whats confusing about it? Why would inventing yet-another-API 
>>> be any less confusing?
>>
>> Becuase the MBeans are the naming convention for JMX beans. Call them 
>> something else, then you don't have the dependency.
>>
>> A naming convention is as much a dependency as a code requirement.
>
> Huh?

Sorry, didn't explain myself well on that one. The JMX spec dictates 
that a MBean exposes itself through an interface called XxxMBean. 
Therefore, if you also create interfaces/classes that end XxxMBean, 
it's not just a convention. It's the way it's done in JMX containers, 
and by virtue of ending interfaces in XxxMBean then (a) you allow that 
to be managed by a JMX container, but also (b) it may become dependent 
on a JMX container to run in. Further, external developers who see 
XxxMBean will assume that it is a JMX MBean, even if it isn't meant to 
be.

If I had a class called SimpleSingleton, you'd be very surprised if it 
was a pop-up dialog box to ask for a file name. Names are just as 
important as the implementation, since it can mean something specific 
to developers. And the extension XxxMBean means a JMX managed bean.

>> True, which is why I suggested creating an MBean container to run 
>> within Geronimo.
>
> We've already got one - its in CVS.

Yes, I know, but I was suggesting that a J2EE server should be 
implemented as a MicroKernel architecture, and then (along with 
WebContainer and EJBContainer) provide an MBeanContainer for supporting 
legacy MBeans. That doesn't necessarily imply that everything needs to 
be an MBean, or that a J2EE server should be implemented using JMX, in 
much the same way that it wouldn't necessarily make sense to create a 
J2EE server that used Servlets for all of its implementation (though 
clearly, it could be done).

> We want to support MBeans as we already have MBeans and an MBean 
> container and plenty of external MBeans we wish to reuse. We want to 
> be fully JSR 77 and 88 compliant.

Neither JSR 77 or 88 say that the system must be implemented as MBeans 
though; they merely show a way of providing an MBean interface. As Greg 
suggested, these interfaces could be dynamically generated from XML 
files on top of implementations that are MBean agnostic.

> There's no reason why you Alex can't write your own AlexContainer and 
> drop it into Geronimo and support any component model you wish. Ditto 
> for Avalon & PicoContainers etc.

I believe that the idea of Avalon as a Kernel is to sit under the JMX 
level, not on top of it. I don't see those as being implemented using 
JMX.

>>>> The more JMX dependencies that get added now, the more difficult it 
>>>> will be to change at a later stage. So by abstracting into a common 
>>>> super type(s) now, we can write to a generic API that will be 
>>>> easier to migrate later, rather than having everything being 
>>>> MBean-based.
>>>
>>> There are no dependencies. Its a very common *naming-convention* 
>>> used throughout the J2EE world.  I don't see any problem using this 
>>> established standard rather than yet-another-container-API.
>>
>> It isn't a common naming convention.
>
> Look in the codebases of Geronimo, Tomcat, Jetty, JBoss, mx4j and 
> others.

They use it /because/ they implement JMX beans. It's not because it's a 
naming convention.

Of course, it's hardly surprising that mx4j uses a lot of MBeans -- 
after all, that is the Apache JMX implementation :-)

And, as already has been set, JBoss uses JMX MBeans for all of its work.

>> And the point of this discussion, and the rest of the threads 
>> regarding this (including the Wiki pages) is to think of how it could 
>> be done in different ways, and propose advantages/disadvantages.
>
> Sure lets by all means brainstorm and think of what the future 
> container could be. However remember what the goal of Geronimo is - to 
> create a full J2EE stack. It doesn't have to have the ultimate J2EE 
> container framework inside it from day one.

I never meant to imply that it was, nor that work could not start 
immediately on new services. Indeed, a few proposals have already been 
made that would (a) allow developers to get started on writing new 
services immediately, whilst at the same time (b) not being dependent 
on the MBean JMX spec/naming convention. At a later stage, ideas may 
surface for a replacement kernel, or they may never arise.

> The writing of other J2EE services is *high* priority and absolute 
> requirement. Thinking up an alternative component model to MBeans is 
> quite low IMHO - its a nice to have, not a requirement.

Absolutely agree.

> I don't want developers wishing to integrate the multitude of other 
> parts to get J2EE compliance to sit and wait for some new component 
> model which may or may not come out of some brainstorming session. If 
> another component model comes along in the future we can look at using 
> it. Until then I firmly believe our best course of action is to use 
> MBeans as the default component model for course grained services - 
> and plug anything else in using some custom adapters/containers.

I'd also agree with this as well.

But I think there is a happy compromise by providing some abstract 
classes (Service, ManagedComponent, whatever) that provide the MBean 
interface whilst allowing subclasses to be MBean agnostic. That way, we 
get the benefits of being able to develop (and run) stuff immediately 
whilst still initially using the MBean model, and then migrate as and 
when other kernels become available.

Alex.

Re: Kernel Architecture

[James Strachan <ja...@yahoo.co.uk>]

On Tuesday, August 12, 2003, at 02:17  pm, Alex Blewitt wrote:
> On Tuesday, Aug 12, 2003, at 12:54 Europe/London, James Strachan wrote:
>> On Tuesday, August 12, 2003, at 12:27  pm, Alex Blewitt wrote:
>>> On Tuesday, Aug 12, 2003, at 12:17 Europe/London, James Strachan 
>>> wrote:
>>>> On Tuesday, August 12, 2003, at 11:36  am, James deGraft-Johnson 
>>>> wrote:
>>>>
>>>>> I like the suggestion that even if we decide to go with the MBean 
>>>>> model, a
>>>>> layer be created, possibly via an interface so this software isn't 
>>>>> tightly
>>>>> coupled to MBeans.
>>>>
>>>> An interface based MBean is just a naming convention. There is no 
>>>> tying to anything. Indeed there's not even a dependency on JMX 
>>>> never mind any other container API. Then the container is totally 
>>>> free to go in whatever direction it wishes.
>>>
>>> But by creating (and calling) them MBeans, you are tying it down to 
>>> a naming convention expected by JMX which may confuse the issue 
>>> later.
>>
>> Why? Whats confusing about it? Why would inventing yet-another-API be 
>> any less confusing?
>
> Becuase the MBeans are the naming convention for JMX beans. Call them 
> something else, then you don't have the dependency.
>
> A naming convention is as much a dependency as a code requirement.

Huh?


>>> Changing things after they've been done is much more difficult than 
>>> before they've been done :-)
>>
>> If thats your argument then its already too late to change away from 
>> MBeans. Geronimo has plenty of MBeans already - so has Tomcat, Jetty, 
>> JBoss etc. Any container should be able to easily work with these 
>> components today irrespective of tomorrows container.
>
> True, which is why I suggested creating an MBean container to run 
> within Geronimo.

We've already got one - its in CVS.


>>>>> Whatever we do, the ease of implementation, such as ease of kernel 
>>>>> and
>>>>> service development should be paramount. The easier it is to 
>>>>> develop, the
>>>>> greater the chances that we can focus on removing bugs and 
>>>>> increasing
>>>>> performance.
>>>> Agreed.
>>>>
>>>> Which is why I think us all developing MBeans to start with is the 
>>>> easiest approach. They are very simple. Take a look at some of them 
>>>> in CVS (they end with *MBean.java)
>>>
>>> But creating a category of different types (Service, Component etc.) 
>>> that developers implement is even easier. Ideally, those two should 
>>> be the only two types that implement any kind of MBean interface; 
>>> and the remainder of the code developed /doesn't/ need to have the 
>>> MBean suffix.
>>
>> I don't see the need as this appears to be unnecessary coupling. 
>> However be that as it may - it doesn't change the original premise - 
>> of writing MBeans for now until we come up with something better 
>> later on. Afterall we have lots of MBeans today we should support.
>
> We can introduce the new types, and write to them, and then refactor 
> existing code over. Why the fuss about MBeans? We could still support 
> existing MBeans in an MBeanContainer.

We want to support MBeans as we already have MBeans and an MBean 
container and plenty of external MBeans we wish to reuse. We want to be 
fully JSR 77 and 88 compliant.

There's no reason why you Alex can't write your own AlexContainer and 
drop it into Geronimo and support any component model you wish. Ditto 
for Avalon & PicoContainers etc.


>
>>> The more JMX dependencies that get added now, the more difficult it 
>>> will be to change at a later stage. So by abstracting into a common 
>>> super type(s) now, we can write to a generic API that will be easier 
>>> to migrate later, rather than having everything being MBean-based.
>>
>> There are no dependencies. Its a very common *naming-convention* used 
>> throughout the J2EE world.  I don't see any problem using this 
>> established standard rather than yet-another-container-API.
>
> It isn't a common naming convention.

???

Look in the codebases of Geronimo, Tomcat, Jetty, JBoss, mx4j and 
others.


> It's the JMX spec. The reason why it's used 'Throughout the J2EE 
> world' is because that's the way that JBoss does it. Many other J2EE 
> servers don't.

So?


> And the point of this discussion, and the rest of the threads 
> regarding this (including the Wiki pages) is to think of how it could 
> be done in different ways, and propose advantages/disadvantages.

Sure lets by all means brainstorm and think of what the future 
container could be. However remember what the goal of Geronimo is - to 
create a full J2EE stack. It doesn't have to have the ultimate J2EE 
container framework inside it from day one.

The point of my original thread was to get us started writing services 
that bind into the existing JMX based container along with the existing 
MBeans in Geronimo, Tomcat, Jetty, mx4j and elsewhere while allowing 
those interested in the internals of the container to go off in their 
own direction in parallel. The writing of other J2EE services is *high* 
priority and absolute requirement. Thinking up an alternative component 
model to MBeans is quite low IMHO - its a nice to have, not a 
requirement.

I don't want developers wishing to integrate the multitude of other 
parts to get J2EE compliance to sit and wait for some new component 
model which may or may not come out of some brainstorming session. If 
another component model comes along in the future we can look at using 
it. Until then I firmly believe our best course of action is to use 
MBeans as the default component model for course grained services - and 
plug anything else in using some custom adapters/containers.

James
-------
http://radio.weblogs.com/0112098/

Re: Kernel Architecture

[Alex Blewitt <Al...@ioshq.com>]

On Tuesday, Aug 12, 2003, at 12:54 Europe/London, James Strachan wrote:

>
> On Tuesday, August 12, 2003, at 12:27  pm, Alex Blewitt wrote:
>
>> On Tuesday, Aug 12, 2003, at 12:17 Europe/London, James Strachan 
>> wrote:
>>
>>> On Tuesday, August 12, 2003, at 11:36  am, James deGraft-Johnson 
>>> wrote:
>>>
>>>> I like the suggestion that even if we decide to go with the MBean 
>>>> model, a
>>>> layer be created, possibly via an interface so this software isn't 
>>>> tightly
>>>> coupled to MBeans.
>>>
>>> An interface based MBean is just a naming convention. There is no 
>>> tying to anything. Indeed there's not even a dependency on JMX never 
>>> mind any other container API. Then the container is totally free to 
>>> go in whatever direction it wishes.
>>
>> But by creating (and calling) them MBeans, you are tying it down to a 
>> naming convention expected by JMX which may confuse the issue later.
>
> Why? Whats confusing about it? Why would inventing yet-another-API be 
> any less confusing?

Becuase the MBeans are the naming convention for JMX beans. Call them 
something else, then you don't have the dependency.

A naming convention is as much a dependency as a code requirement.

>> Changing things after they've been done is much more difficult than 
>> before they've been done :-)
>
> If thats your argument then its already too late to change away from 
> MBeans. Geronimo has plenty of MBeans already - so has Tomcat, Jetty, 
> JBoss etc. Any container should be able to easily work with these 
> components today irrespective of tomorrows container.

True, which is why I suggested creating an MBean container to run 
within Geronimo.

>>>> Whatever we do, the ease of implementation, such as ease of kernel 
>>>> and
>>>> service development should be paramount. The easier it is to 
>>>> develop, the
>>>> greater the chances that we can focus on removing bugs and 
>>>> increasing
>>>> performance.
>>> Agreed.
>>>
>>> Which is why I think us all developing MBeans to start with is the 
>>> easiest approach. They are very simple. Take a look at some of them 
>>> in CVS (they end with *MBean.java)
>>
>> But creating a category of different types (Service, Component etc.) 
>> that developers implement is even easier. Ideally, those two should 
>> be the only two types that implement any kind of MBean interface; and 
>> the remainder of the code developed /doesn't/ need to have the MBean 
>> suffix.
>
> I don't see the need as this appears to be unnecessary coupling. 
> However be that as it may - it doesn't change the original premise - 
> of writing MBeans for now until we come up with something better later 
> on. Afterall we have lots of MBeans today we should support.

We can introduce the new types, and write to them, and then refactor 
existing code over. Why the fuss about MBeans? We could still support 
existing MBeans in an MBeanContainer.

>> The more JMX dependencies that get added now, the more difficult it 
>> will be to change at a later stage. So by abstracting into a common 
>> super type(s) now, we can write to a generic API that will be easier 
>> to migrate later, rather than having everything being MBean-based.
>
> There are no dependencies. Its a very common *naming-convention* used 
> throughout the J2EE world.  I don't see any problem using this 
> established standard rather than yet-another-container-API.

It isn't a common naming convention. It's the JMX spec. The reason why 
it's used 'Throughout the J2EE world' is because that's the way that 
JBoss does it. Many other J2EE servers don't.

And the point of this discussion, and the rest of the threads regarding 
this (including the Wiki pages) is to think of how it could be done in 
different ways, and propose advantages/disadvantages.

Alex.

Re: Kernel Architecture

[James Strachan <ja...@yahoo.co.uk>]

On Tuesday, August 12, 2003, at 12:27  pm, Alex Blewitt wrote:

> On Tuesday, Aug 12, 2003, at 12:17 Europe/London, James Strachan wrote:
>
>> On Tuesday, August 12, 2003, at 11:36  am, James deGraft-Johnson 
>> wrote:
>>
>>> I like the suggestion that even if we decide to go with the MBean 
>>> model, a
>>> layer be created, possibly via an interface so this software isn't 
>>> tightly
>>> coupled to MBeans.
>>
>> An interface based MBean is just a naming convention. There is no 
>> tying to anything. Indeed there's not even a dependency on JMX never 
>> mind any other container API. Then the container is totally free to 
>> go in whatever direction it wishes.
>
> But by creating (and calling) them MBeans, you are tying it down to a 
> naming convention expected by JMX which may confuse the issue later.

Why? Whats confusing about it? Why would inventing yet-another-API be 
any less confusing?


> Changing things after they've been done is much more difficult than 
> before they've been done :-)

If thats your argument then its already too late to change away from 
MBeans. Geronimo has plenty of MBeans already - so has Tomcat, Jetty, 
JBoss etc. Any container should be able to easily work with these 
components today irrespective of tomorrows container.


>
>>> Whatever we do, the ease of implementation, such as ease of kernel 
>>> and
>>> service development should be paramount. The easier it is to 
>>> develop, the
>>> greater the chances that we can focus on removing bugs and increasing
>>> performance.
>> Agreed.
>>
>> Which is why I think us all developing MBeans to start with is the 
>> easiest approach. They are very simple. Take a look at some of them 
>> in CVS (they end with *MBean.java)
>
> But creating a category of different types (Service, Component etc.) 
> that developers implement is even easier. Ideally, those two should be 
> the only two types that implement any kind of MBean interface; and the 
> remainder of the code developed /doesn't/ need to have the MBean 
> suffix.

I don't see the need as this appears to be unnecessary coupling. 
However be that as it may - it doesn't change the original premise - of 
writing MBeans for now until we come up with something better later on. 
Afterall we have lots of MBeans today we should support.


> The more JMX dependencies that get added now, the more difficult it 
> will be to change at a later stage. So by abstracting into a common 
> super type(s) now, we can write to a generic API that will be easier 
> to migrate later, rather than having everything being MBean-based.

There are no dependencies. Its a very common *naming-convention* used 
throughout the J2EE world.  I don't see any problem using this 
established standard rather than yet-another-container-API.

James
-------
http://radio.weblogs.com/0112098/

Re: Kernel Architecture

[Alex Blewitt <Al...@ioshq.com>]

On Tuesday, Aug 12, 2003, at 12:17 Europe/London, James Strachan wrote:

> On Tuesday, August 12, 2003, at 11:36  am, James deGraft-Johnson wrote:
>
>> I like the suggestion that even if we decide to go with the MBean 
>> model, a
>> layer be created, possibly via an interface so this software isn't 
>> tightly
>> coupled to MBeans.
>
> An interface based MBean is just a naming convention. There is no 
> tying to anything. Indeed there's not even a dependency on JMX never 
> mind any other container API. Then the container is totally free to go 
> in whatever direction it wishes.

But by creating (and calling) them MBeans, you are tying it down to a 
naming convention expected by JMX which may confuse the issue later. 
Changing things after they've been done is much more difficult than 
before they've been done :-)

>> Whatever we do, the ease of implementation, such as ease of kernel and
>> service development should be paramount. The easier it is to develop, 
>> the
>> greater the chances that we can focus on removing bugs and increasing
>> performance.
> Agreed.
>
> Which is why I think us all developing MBeans to start with is the 
> easiest approach. They are very simple. Take a look at some of them in 
> CVS (they end with *MBean.java)

But creating a category of different types (Service, Component etc.) 
that developers implement is even easier. Ideally, those two should be 
the only two types that implement any kind of MBean interface; and the 
remainder of the code developed /doesn't/ need to have the MBean suffix.

The more JMX dependencies that get added now, the more difficult it 
will be to change at a later stage. So by abstracting into a common 
super type(s) now, we can write to a generic API that will be easier to 
migrate later, rather than having everything being MBean-based.

Alex.

Re: Kernel Architecture

[James Strachan <ja...@yahoo.co.uk>]

On Tuesday, August 12, 2003, at 11:36  am, James deGraft-Johnson wrote:

> Hi,
>
> I like the suggestion that even if we decide to go with the MBean 
> model, a
> layer be created, possibly via an interface so this software isn't 
> tightly
> coupled to MBeans.

An interface based MBean is just a naming convention. There is no tying 
to anything. Indeed there's not even a dependency on JMX never mind any 
other container API. Then the container is totally free to go in 
whatever direction it wishes.


> Whatever we do, the ease of implementation, such as ease of kernel and
> service development should be paramount. The easier it is to develop, 
> the
> greater the chances that we can focus on removing bugs and increasing
> performance. (In particular, by ease I mean the extra code and it's
> complexity needed to integrate kernel/service implementation into the
> framework.) I think this requirement should be weighed against other
> benefits of the alternative architectures.

Agreed.

Which is why I think us all developing MBeans to start with is the 
easiest approach. They are very simple. Take a look at some of them in 
CVS (they end with *MBean.java)

James
-------
http://radio.weblogs.com/0112098/

RE: Kernel Architecture

[James deGraft-Johnson <jd...@digaman.com>]

Hi,

I like the suggestion that even if we decide to go with the MBean model, a
layer be created, possibly via an interface so this software isn't tightly
coupled to MBeans.

Whatever we do, the ease of implementation, such as ease of kernel and
service development should be paramount. The easier it is to develop, the
greater the chances that we can focus on removing bugs and increasing
performance. (In particular, by ease I mean the extra code and it's
complexity needed to integrate kernel/service implementation into the
framework.) I think this requirement should be weighed against other
benefits of the alternative architectures.

James deGraft-Johnson
Software Engineer - IT
Verizon Information Services
Tel:         (240) 456-7018
Fax:        (240) 456-7072
Mobile:   (240) 475-1444 <jd...@verizon-uc.com>

-----Original Message-----
From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
Sent: Tuesday, August 12, 2003 6:07 AM
To: geronimo-dev@incubator.apache.org
Subject: Re: Kernel Architecture (was [Re: JMX as a kernel ...])

I'd recommend having separate pages for each type, rather than
everything in one page.

I'd also like to suggest that there are different groups of
architectures, such as a MicroKernel architecture (of which Avalon and
HiveMind may be examples).

Alex.

On Tuesday, Aug 12, 2003, at 12:58 Europe/London, Richard Monson-Haefel
wrote:

> I've put the the skeleton of a new Wiki page to discuss the different
> kernel solutions proposed. It would be very helpful if supporters of
> each solution could post a description (plain english please) as well
> as pros and cons for any solution ... please add any solutions that
> I've missed. This will give us a better framework around which to
> discuss this topic.
>
> See the Kernel page listed from the Architecture page.
> http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/Architecture
>
> .
>

Re: Kernel Architecture (was [Re: JMX as a kernel ...])

[James Strachan <ja...@yahoo.co.uk>]

On Tuesday, August 12, 2003, at 12:24  pm, Alex Blewitt wrote:
>
>>> I'd also like to suggest that there are different groups of 
>>> architectures, such as a MicroKernel architecture (of which Avalon 
>>> and HiveMind may be examples).
>>
>> Whats the distinction between them? Both JMX and Pico are both micro 
>> kernel architectures too aren't they?
>
> I can't say for Pico, but JMX is a management extension, not a kernel 
> architecture.

That doesn't mean you can't have a JMX based micro-kernel


> So it couldn't really be called a micro kernel, no.

So you're saying JBoss, Tomcat, Jetty and Geronimo for example are not 
using a JMX micro kernel?  What would you call it then? How would you 
distinguish a Pico / Avalon kernel from the JMX-based equivalent?

James
-------
http://radio.weblogs.com/0112098/

Re: Kernel Architecture (was [Re: JMX as a kernel ...])

[Alex Blewitt <Al...@ioshq.com>]

> On Tuesday, August 12, 2003, at 11:06  am, Alex Blewitt wrote:
>
>> I'd recommend having separate pages for each type, rather than 
>> everything in one page.
>
> Its a wiki - just add pages :)

They're there. Still have to flesh out a few more of htem, but the 
structure is there (largely done by Richard; thanks :-)

>> I'd also like to suggest that there are different groups of 
>> architectures, such as a MicroKernel architecture (of which Avalon 
>> and HiveMind may be examples).
>
> Whats the distinction between them? Both JMX and Pico are both micro 
> kernel architectures too aren't they?

I can't say for Pico, but JMX is a management extension, not a kernel 
architecture. So it couldn't really be called a micro kernel, no.

Alex.

Re: Kernel Architecture (was [Re: JMX as a kernel ...])

[James Strachan <ja...@yahoo.co.uk>]

On Tuesday, August 12, 2003, at 11:06  am, Alex Blewitt wrote:

> I'd recommend having separate pages for each type, rather than 
> everything in one page.

Its a wiki - just add pages :)

> I'd also like to suggest that there are different groups of 
> architectures, such as a MicroKernel architecture (of which Avalon and 
> HiveMind may be examples).

Whats the distinction between them? Both JMX and Pico are both micro 
kernel architectures too aren't they?

James
-------
http://radio.weblogs.com/0112098/

Re: Kernel Architecture (was [Re: JMX as a kernel ...])

[Alex Blewitt <Al...@ioshq.com>]

I'd recommend having separate pages for each type, rather than 
everything in one page.

I'd also like to suggest that there are different groups of 
architectures, such as a MicroKernel architecture (of which Avalon and 
HiveMind may be examples).

Alex.

On Tuesday, Aug 12, 2003, at 12:58 Europe/London, Richard Monson-Haefel 
wrote:

> I've put the the skeleton of a new Wiki page to discuss the different 
> kernel solutions proposed. It would be very helpful if supporters of 
> each solution could post a description (plain english please) as well 
> as pros and cons for any solution ... please add any solutions that 
> I've missed. This will give us a better framework around which to 
> discuss this topic.
>
> See the Kernel page listed from the Architecture page.
> http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/Architecture
>
> .
>

Kernel Architecture (was [Re: JMX as a kernel ...])

[Richard Monson-Haefel <Ri...@Monson-Haefel.com>]

I've put the the skeleton of a new Wiki page to discuss the different 
kernel solutions proposed. It would be very helpful if supporters of 
each solution could post a description (plain english please) as well 
as pros and cons for any solution ... please add any solutions that 
I've missed. This will give us a better framework around which to 
discuss this topic.

See the Kernel page listed from the Architecture page.
http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/Architecture

.

Re: JMX as a kernel (was: Re: geronimo and avalon?)

[Dragomir Milivojevic <dr...@milivojevic.net>]

Hi All,

I'm apparently jumping into the ongoing discussion so excuse me if I'm 
making no sense.

JBoss went down the JMX route and it works, but does it mean it is a 
right choice? Innovative choice and good idea for sure, but can it be 
made smarter? Possibly... I am wandering whether a smarter decision can 
be made rather then just using "what's there" just because it is and it 
works for someone.

Somewhere down the line someone is going to say, see we at JBoss went 
this way and others are copying our solution and Geronimo is going to 
be "yeah, me too". Developing a modular kernel isn't all that difficult 
anyway and JMX might even be an overkill. What happens when Sun changes 
JMX spec? besides... Alex has few very good points IMHO.

-d-

On Monday, August 11, 2003, at 11:55 AM, Alex Blewitt wrote:

> On Monday, Aug 11, 2003, at 07:07 Europe/London, Weston M. Price wrote:
>
>> I agree with Gareth,I am not quite sure of why JMX would not be used, 
>> or would
>> be replaced at some other time.
>>
>> On Monday 11 August 2003 09:28 am, Gareth Bryan wrote:
>>>> On Mon, 11 Aug 2003 04:40:40 -0400, "Noel J. Bergman" 
>>>> <no...@devtech.com>
>>>> said:
>>>>
>>>> Jason Dillon wrote:
>>>>> we will eventually want to replace the JMX bus with a more
>>>>> robust component system.
>>>>
>>>> The sense I am getting from the list is that there is a decent 
>>>> sized base
>>>> of
>>>> people who agree with you, and who see JMX as an interface TO a 
>>>> component
>>>> system, not AS the component system.
>>>
>>> I get that sense aswell, although personally, I haven't spoken up 
>>> about
>>> it before now because I wanted to take a look at the seed code. My
>>> initial opinion is that I'd like to see some hard evidence for the
>>> drawbacks for using JMX, putting it another way: I'm a +1 for JMX at 
>>> the
>>> moment.
>
> A number of people are saying 'Lets go with the JMX bus until another 
> choice is made later'. The question is, why was the JMX bus chosen in 
> the first place? Because other implementations (e.g. JBoss) used that 
> approach.
>
> The problem is that JMX was designed as an interface to allow remote 
> programs to manage/start/stop services on a remote machine using an 
> arbitrary client. JBoss does as much in its administration console, 
> which is nothing more than a glorified send-a-JMX-message system.
>
> The other reason why JMX is used as the initial bus is that J2EE must 
> have a JMX interface. That said, it doesn't need to be implemented 
> using JMX (in much the same way that we don't need to build a J2EE 
> server using CORBA although CORBA requests may/must be supported).
>
> Unfortunately, the isA/hasA debate is something that can run and run 
> and run, and since the initial code seed has gone with JMX then it 
> seems very difficult to nudge that another way. But a more generic 
> container framework (the likes of 
> Avalon/Merlin/Hivemind/Eclipse-Plugin-Style) that /has/ a JMX 
> interface would be a 'cleaner' approach from an OO perspective.
>
> There is also a potential danger that if JMX is used as the bus for 
> the kernel, then developers will think it's a good idea to use JMX for 
> all the intra-kernel messages. JMX was designed to be a /Management/ 
> interface, not a system for passing messages between components.
>
> Lastly, if the focus is on 'The kernel is JMX' then that may 
> unnecessarily affect design decisions: 'Hey, lets use MBeans defined 
> in XML on a single flat file'. We could follow JBoss' example and do 
> this; or we could be more innovative, using a configuration registry 
> backed with JNDI/LDAP, whilst still providing a Management interface 
> over JMX.
>
> Alex.
>
>
>

Re: JMX as a kernel (was: Re: geronimo and avalon?)

[Alex Blewitt <Al...@ioshq.com>]

On Monday, Aug 11, 2003, at 07:07 Europe/London, Weston M. Price wrote:

> I agree with Gareth,I am not quite sure of why JMX would not be used, 
> or would
> be replaced at some other time.
>
> On Monday 11 August 2003 09:28 am, Gareth Bryan wrote:
>>> On Mon, 11 Aug 2003 04:40:40 -0400, "Noel J. Bergman" 
>>> <no...@devtech.com>
>>> said:
>>>
>>> Jason Dillon wrote:
>>>> we will eventually want to replace the JMX bus with a more
>>>> robust component system.
>>>
>>> The sense I am getting from the list is that there is a decent sized 
>>> base
>>> of
>>> people who agree with you, and who see JMX as an interface TO a 
>>> component
>>> system, not AS the component system.
>>
>> I get that sense aswell, although personally, I haven't spoken up 
>> about
>> it before now because I wanted to take a look at the seed code. My
>> initial opinion is that I'd like to see some hard evidence for the
>> drawbacks for using JMX, putting it another way: I'm a +1 for JMX at 
>> the
>> moment.

A number of people are saying 'Lets go with the JMX bus until another 
choice is made later'. The question is, why was the JMX bus chosen in 
the first place? Because other implementations (e.g. JBoss) used that 
approach.

The problem is that JMX was designed as an interface to allow remote 
programs to manage/start/stop services on a remote machine using an 
arbitrary client. JBoss does as much in its administration console, 
which is nothing more than a glorified send-a-JMX-message system.

The other reason why JMX is used as the initial bus is that J2EE must 
have a JMX interface. That said, it doesn't need to be implemented 
using JMX (in much the same way that we don't need to build a J2EE 
server using CORBA although CORBA requests may/must be supported).

Unfortunately, the isA/hasA debate is something that can run and run 
and run, and since the initial code seed has gone with JMX then it 
seems very difficult to nudge that another way. But a more generic 
container framework (the likes of 
Avalon/Merlin/Hivemind/Eclipse-Plugin-Style) that /has/ a JMX interface 
would be a 'cleaner' approach from an OO perspective.

There is also a potential danger that if JMX is used as the bus for the 
kernel, then developers will think it's a good idea to use JMX for all 
the intra-kernel messages. JMX was designed to be a /Management/ 
interface, not a system for passing messages between components.

Lastly, if the focus is on 'The kernel is JMX' then that may 
unnecessarily affect design decisions: 'Hey, lets use MBeans defined in 
XML on a single flat file'. We could follow JBoss' example and do this; 
or we could be more innovative, using a configuration registry backed 
with JNDI/LDAP, whilst still providing a Management interface over JMX.

Alex.

Re: JMX as a kernel (was: Re: geronimo and avalon?)

["Weston M. Price" <we...@yahoo.com>]

I agree with Gareth,I am not quite sure of why JMX would not be used, or would 
be replaced at some other time. 

Regards,

Weston

On Monday 11 August 2003 09:28 am, Gareth Bryan wrote:
> >On Mon, 11 Aug 2003 04:40:40 -0400, "Noel J. Bergman" <no...@devtech.com>
> > said:
> >
> > Jason Dillon wrote:
> > > we will eventually want to replace the JMX bus with a more
> > > robust component system.
> >
> > The sense I am getting from the list is that there is a decent sized base
> > of
> > people who agree with you, and who see JMX as an interface TO a component
> > system, not AS the component system.
>
> I get that sense aswell, although personally, I haven't spoken up about
> it before now because I wanted to take a look at the seed code. My
> initial opinion is that I'd like to see some hard evidence for the
> drawbacks for using JMX, putting it another way: I'm a +1 for JMX at the
> moment.
>
> Perhaps there are others like me who have not spoken up about this until
> first look at the code?
>
> Just a thought.
>
> Regards,
>
> Gareth
> --
>   Gareth Bryan
>   garethbryan@fastmail.fm

RE: JMX as a kernel (was: Re: geronimo and avalon?)

[Gareth Bryan <ga...@fastmail.fm>]

>On Mon, 11 Aug 2003 04:40:40 -0400, "Noel J. Bergman" <no...@devtech.com> said:
> Jason Dillon wrote:
> 
> > we will eventually want to replace the JMX bus with a more
> > robust component system.
> 
> The sense I am getting from the list is that there is a decent sized base
> of
> people who agree with you, and who see JMX as an interface TO a component
> system, not AS the component system.
> 

I get that sense aswell, although personally, I haven't spoken up about
it before now because I wanted to take a look at the seed code. My
initial opinion is that I'd like to see some hard evidence for the
drawbacks for using JMX, putting it another way: I'm a +1 for JMX at the
moment.

Perhaps there are others like me who have not spoken up about this until
first look at the code?

Just a thought.

Regards,

Gareth
-- 
  Gareth Bryan
  garethbryan@fastmail.fm

-- 
http://www.fastmail.fm - Choose from over 50 domains or use your own

RE: JMX as a kernel (was: Re: geronimo and avalon?)

["Noel J. Bergman" <no...@devtech.com>]

Paul Hammant wrote:
> > I'm sure the current Geronimo committers will agree that it is too
> > early to think about a new container/component design. Better for them
> > ship code than procrastinate over design.  Right James/lads ?

There is a line between seeding the CVS and pushing a singular design
without working with other interested parties.  :-)

Jason Dillon wrote:

> we will eventually want to replace the JMX bus with a more
> robust component system.

The sense I am getting from the list is that there is a decent sized base of
people who agree with you, and who see JMX as an interface TO a component
system, not AS the component system.

	--- Noel

Re: JMX as a kernel (was: Re: geronimo and avalon?)

[Jason Dillon <ja...@coredevelopers.net>]

> Eclipse reboots between starts. As you say the team is looking for a 
> new component design, with OSG Framework being frontrunner.  There is 
> a lot of good in the Eclipse design though.
>
> I'm sure the current Geronimo committers will agree that it is too 
> early to think about a new container/component design. Better for them 
> ship code than procrastinate over design.  Right James/lads ?

Yes, though I believe that information about existing 
container/component models is useful, as we will eventually want to 
replace the JMX bus with a more robust component system.

--jason

Re: JMX as a kernel (was: Re: geronimo and avalon?)

[Paul Hammant <Pa...@ThoughtWorks.net>]

Hiram

Eclipse reboots between starts. As you say the team is looking for a new 
component design, with OSG Framework being frontrunner.  There is a lot 
of good in the Eclipse design though.

I'm sure the current Geronimo committers will agree that it is too early 
to think about a new container/component design. Better for them ship 
code than procrastinate over design.  Right James/lads ?

- Paul

>Having developed a few Eclipse plugins, I can attest that Eclipse has a
>great plugin system.  
>  
>


-- 
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...

Re: JMX as a kernel (was: Re: geronimo and avalon?)

[Hiram Chirino <hi...@coredevelopers.net>]

Having developed a few Eclipse plugins, I can attest that Eclipse has a
great plugin system.  

It has a great classloader structure.  I can deploy a plugin and have
it's classloader "import" classes from other plugins.  I can use a set
of filters to define which classes of a plugin are allowed to be
"imported" by other plugins.  

It's deployment registry allows you to lazy load the plugin classes.  No
need to activate a plugin until it's being used.  The deployment
registry allows you to register the "extension points" that your plugin
implements.  For example, there could be a "WebAppDeployer" plugin that
defines a "WebContainer" "extension point".  When a jetty plugin gets
deployed it defines that it implements the "WebContainer" "extension
point".  Since it's all just meta-data, jetty does not really need to be
activated until the "WebAppDeployer" tries to get a instance of one of
the guys that implemented the "WebContainer" extension point.

It also provides each plugin an interface to persist runtime
configuration changes.  Persisting changes have to be done explicitly by
the plugin provider but at least every plugin uses the same
configuration persistence interface.

The down side is that they designed the deployment meta-data registry to
be loaded on startup and then be static after that.  So they do not hot
deploy new plugins or anything like that.  So their stuff will not work
for us well at all but they have implemented some very nice concepts. 
But some eclipse folks are working on changing this.. see: 
http://eclipse.org/equinox/index.html


Regards,
Hiram

On Fri, 2003-08-08 at 15:05, Jason Dillon wrote:
> I think that it would be best for Geronimo not to use JMX as the 
> component bus, but use something else and then adapt JMX to it, as we 
> must have JMX support.
> 
> That said there are so many different component containers out there, 
> it is hard to find the one which suites our needs and/or requires the 
> least amount of hacking to get it to function.
> 
> I have had a look over several containers, HiveMind being one of them, 
> though I have not really spent much time looking at the details.
> 
> We need something which is small, fast, can plug in any sort of 
> component, which will support linking component instances to avoid any 
> hard coupling.  It needs to be able to support elba/jboss style 
> deployment and class loading semantics.  It needs to be able to be 
> adapted to JMX (possibly other protocols like SNMP too).  It would be 
> beneficial if it could provide dependency management as well as 
> component state management, or at the minimum be easy to provide layers 
> on top which can provide this.  It must not impose many restrictions on 
> how it can be used, nor should it impose any other application 
> functionality short of managing components.
> 
> This is just a rough blurb about the requirements for the geronimo 
> component container, I will try to write up something more formal and 
> drop it into the wiki in the next day or so... along with the system 
> loading, configuration and deployment sub-systems.
> 
> I believe that the initial geronimo/elba hybrid will probably use JMX, 
> as it already works, but we will want to replace this with a more 
> robust system as soon as we can sort out how to build it.  Anyways, I 
> will put up some wiki docs and then perhaps some of the folks who are 
> more knowledgeable about these different containers can comment.  I do 
> not want to reinvent the wheel, but if the wheel does not fit the wagon 
> then we may just have to make a new one.
> 
> --jason
> 
> PS. Can someone write up something about the current state of the major 
> component containers out there with a feature blurb... no soap boxes, 
> just the facts jack.
> 
> 
> On Friday, August 8, 2003, at 10:33  PM, Howard M. Lewis Ship wrote:
> 
> > I'm going to plug HiveMind again here.
> >
> > Looking over what JBoss has done with JMX as a Microkernel, I have a 
> > couple of key issues.
> >
> > First off, the code abstraction that requires you to invoke methods on 
> > MBeans using an interface
> > like reflection.  Yes, there are workarounds to that (such as using 
> > dynamic Proxys) but if a Java
> > object is invoking a method on another Java object within the same JVM 
> > why make it look like some
> > low-level RPC call?
> >
> > Second, configuration of MBeans leaves a bit to be desired.  I suppose 
> > it works well for simple
> > properties, but once you get to anything complicated, you start seeing 
> > more and more ad-hoc
> > ugliness.  Among other things, you end up endlessly rehashing the code 
> > to translate an MBean name
> > into an instance that methods can be invoked on.
> >
> > Intrinsic to HiveMind are concepts adapted from Eclipse Plugins: 
> > extension points and extensions.
> > Extension points define a point where modules can plug into other 
> > modules; an extension point
> > defines a kind of XML schema for contributions.  Extensions are 
> > snippets of XML that plug into
> > extension points.
> >
> > The end result is something very flexible, and very supportive of a 
> > very complex environment, yet
> > very "lean and mean" at the same time.
> >
> > http://jakarta.apache.org/commons/sandbox/hivemind
> >
> > --
> > Howard M. Lewis Ship
> > Creator, Tapestry: Java Web Components
> > http://jakarta.apache.org/tapestry
> >
> >
> >
> >> -----Original Message-----
> >> From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
> >> Sent: Friday, August 08, 2003 8:55 AM
> >> To: geronimo-dev@incubator.apache.org
> >> Subject: Re: JMX as a kernel (was: Re: geronimo and avalon?)
> >>
> >>
> >>
> >> On Friday, Aug 8, 2003, at 13:05 Europe/London, Leo Simons wrote:
> >>
> >>> Why JMX Is Not A Very Good Kernel
> >>> ------------------
> >>
> >> I'd definitely concur with this. Put it better than I could
> >> have done,
> >> too :-)
> >>
> >> Note that just because JMX isn't a kernel, doesn't mean that
> >> some parts
> >> of it can't be configured with JMX on top. It just means that not
> >> everything has to be JMX.
> >>
> >> Building a tighter smaller kernel gives me a gut feeling that it will
> >> run faster, though I've yet to convert that into measurable
> >> figures :-)
> >> But reducing (unnecessary) layers is bound to speed it up...
> >>
> >> One fear I have of using JMX as a kernel is that all the intra-kernel
> >> messages would be sent using JMX. If JMX isn't used in the
> >> kernel, then
> >> they can be made more efficient/optimised; but JMX can be put as a
> >> layer on top of the features (e.g. EJBs) that need
> >> configuring/managing
> >> by JMX.
> >>
> >> Definitely vote +1 for not using JMX 'just because'
> >>
> >> Alex.
> >>
> >
-- 
/**************************
  * Hiram Chirino
  * Partner
  * Core Developers Network
  **************************/

Avalon Merlin - model-driven containment

[Stephen McConnell <mc...@apache.org>]

Jason Dillon wrote:

> PS. Can someone write up something about the current state of the 
> major component containers out there with a feature blurb... no soap 
> boxes, just the facts jack. 


Based on current directions (and subject to the usual votes within the 
comming days) the Avalon community is about to release a container 
framework – codenamed Merlin. The framework deals with a set of critical 
container/component concerns that provide support for general component 
models (not just classic Avalon).

In particular, the Merlin framework includes:

* component meta info - declaration of a component criteria including 
configuration and parameterization requirements, contextualization 
requirements (including contextualization strategy, casting constraints, 
context entry requirements, optional and volatile entry criteria, 
etc.)., service dependencies, general component type attributes, logging 
criteria, etc.

* component meta data - definition of the meta model for declaration of 
component deployment directives that instruct a container with respect 
to deployment requirements - things like activation policies, 
configuration and contextualization information to be applied to 
components, lifecycle and lifestyle management and so on.

Combining the above two models together in a runtime environment enables 
the establishment of a model driven containment solution (the 
composition framework). Meta info and meta data can be supplied in 
either XML or serializable form, enabling remote model execution and 
management. Model execution is realized though the Merlin 'activation' 
platform which provides the infrastructure for nested component 
hierarchies, composite components (container that contain components the 
define an implementation strategy that allows a container to publish 
itself as a component), and the complete framework for configuration and 
context management based on a model driven approach. The Avalon work has 
already started on a JMX solution and with the introduction of the 
activation API, the Merlin platform will be able deliver a very 
significant level of management automation exposed via local or remotely 
accessible JMX management points that reach into fine-grain controls 
within the containment model.

Aside from all of the above - the Merlin platform provides a neutral 
component type discovery system and an automated component assembly 
framework. This ensures that the overall component deployment process 
can be simplified dramatically, in some cases down to nothing more than 
a couple of container directives.

The first public release of the Merlin platform should be coming out of 
Avalon within a matter of days. From there on the Avalon community will 
be leveraging the Merlin platform as the generic framework on which a 
new model-driven solutions will be delivered. I'll try to make sure we 
get release info to you as soon as it becomes available.

Cheers, Steve.


-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin

Re: Reflection Bad, OO and direct Method invocation Good...

[Frankie Lam <fr...@mindless.com>]

>From what I saw from JBoss implementation (in debugger only, I have never
digged into the source code), it uses a proxy to construct a value object
dynamically using reflection. 100 reflections aren't that much when you have
* a single row *, but when you encounter a table with, say, 40 fields and
you want to load 1000 records, then it takes 40000 reflection operations. In
addition, persistence is essential to any J2EE applications. So if there are
10 users requesting data per second, then it's 400000 operations. Of course
it isn't that much when you count CPU cycles.

But the point is: Why do we want to stress the CPU on the operations that we
can save?

Best regards,
  Frankie

----- Original Message -----
From: "Aaron Mulder" <am...@alumni.princeton.edu>
To: <ge...@incubator.apache.org>
Sent: Saturday, August 09, 2003 11:05 PM
Subject: Re: Reflection Bad, OO and direct Method invocation Good...


> On Sat, 9 Aug 2003, Frankie Lam wrote:
> > I fully agree with you and the benchmark you made is really persuasive
=)
> > I would like to raise a point that the disadvantages of reflection are
more
> > apparant when the methods are called frequently. JBoss CMP
implementation
> > is, AFAIK, reflection-based and its performance is really disappointing.
I'd
> > prefer some sort of on-the-fly compilation mechanisms that need to be
done
> > once only instead.
>
> Wait, I'm confused.  Let's say a CMP operation uses 100 reflection
> operations (which is outrageous).  According the the benchmark that you
> fully agree with, you have now officially wasted 0.0000223 seconds.  Did
> you catch that on your stopwatch?
>
> Aaron
>
>

Re: Reflection Bad, OO and direct Method invocation Good...

[Aaron Mulder <am...@alumni.princeton.edu>]

On Sat, 9 Aug 2003, Frankie Lam wrote:
> I fully agree with you and the benchmark you made is really persuasive =)
> I would like to raise a point that the disadvantages of reflection are more
> apparant when the methods are called frequently. JBoss CMP implementation
> is, AFAIK, reflection-based and its performance is really disappointing. I'd
> prefer some sort of on-the-fly compilation mechanisms that need to be done
> once only instead.

	Wait, I'm confused.  Let's say a CMP operation uses 100 reflection
operations (which is outrageous).  According the the benchmark that you
fully agree with, you have now officially wasted 0.0000223 seconds.  Did
you catch that on your stopwatch?

Aaron

Re: Reflection Bad, OO and direct Method invocation Good...

[Frankie Lam <fr...@mindless.com>]

I fully agree with you and the benchmark you made is really persuasive =)
I would like to raise a point that the disadvantages of reflection are more
apparant when the methods are called frequently. JBoss CMP implementation
is, AFAIK, reflection-based and its performance is really disappointing. I'd
prefer some sort of on-the-fly compilation mechanisms that need to be done
once only instead.

Best regards,
  Frankie

----- Original Message -----
From: John C. Dale
To: geronimo-dev@incubator.apache.org
Sent: Saturday, August 09, 2003 9:16 PM
Subject: Reflection Bad, OO and direct Method invocation Good...


I'm concerned about your mention of reflection.  I really like reflection,
and think it has many useful applications in the application development
space, but should be kept out of any runtime application that has stringent
scalability and performance requirements.  Although reflection allows an
incredibly generic way to solve many difficult problems, and really opens
the door to completely grandios perfectly idealistic genericititousness ;)
, a straight-forward OO approach to solving the problems would 1) be faster
and 2) be easier to read and maintain.  I've seen reflection based
approaches work, and I've seen them bomb.

One might argue that in a container based system that will eventually
support clustering and scalability doesn't have to worry about savoring
individual CPU cycles that might be expended needlessly with a
reflection-based design.  Just add more hardware and the user experience
will be perpetually preserved.  I would argue, however, that the development
community will be able to make better use of the product if the rate at
which additional hardware purchases becomes necessary decreases.  The
philosophy, IMHO, should be to solve the problems at hand with
straight-forward OO solutions, and not to focus so much on being generic and
supporting n * infinity solutions up-front.  Using things like the
Policy/Strategy pattern at well-selected locations will afford the
opportunity for pluggability without compromising maintainability and
performance.

Here are some dramatic results:

Direct:

public void init()
{
   customer = new Customer();
}

public void run()
{
   customer.work();
}

Interface (Polymorphism):

public void init()
{
  customer = new Customer();
}
public void run()
{
  Person person = (Person) customer;
  person.work();
}

Reflection:

public void init()
{
  customer = new Customer();
  try
  {
      method = customer.getClass().getMethod("work", new Class[0]);
  }
  catch (Exception e)
  {
  }

   params = new Object[0];
}

public void run()
{
  try
  {
    method.invoke(customer, params);
  }
  catch (Exception e)
  {
  }
}

With 1000000 of the above code, here were the results:

JDKDirectTestInterfaceTestReflectionTest
Sun 1.452 ms54 ms543 ms
Sun 1.4 -server26 ms56 ms279 ms
Sun 1.3124 ms128 ms2168 ms
Sun 1.3 -server41 ms58 ms2012 ms
IBM 1.375 ms78 ms2134 ms

Reflection will significantly effect the performance of the system and
should be avoided for any runtime operations.  Where it should and could
definitely be applied is with the dynamic generation and compilation of
code, or generation of metadata.  Otherwise, even at the recommendation of
Sun, it should be avoided for runtime operations.

Best,

John C. Dale

Re: Reflection Bad, OO and direct Method invocation Good...

[Leo Simons <le...@apache.org>]

John C. Dale wrote:

> I have no problem with reflection for the instantiation of a policy 
> *once* during the course of an applications' lifecycle.  However, 
> using reflection rampantly for every user request will result in the 
> vaunted and oft feared big Oh catastrophy.  If you have 1 + n 
> reflection operations for every user request, the application 
> performance relative to the reflection code will degrade exponentially 
> with the increase of concurrent users to the system O(n exponential). 

hey, guess what: we agree!

A container is basically there to manage an applications' lifecycle. 
When your
components are up and running, the container should be next to invisible 
(or at
least you should have that option). But startup is already so expensive 
that a
little reflection isn't going to hurt. The same goes for stuff like 
xml<->object
conversion like soap and many other setups.

> If its precise empirical data you're asking for, I would ask the same 
> - 99%?  ;) 

let's settle on the 80/20 rule then :D.

> How does an application 'not care if it is subject to reflection'? 
> Module isolation?  Low coupling? 

dynamic proxying is one way. Really careful interface design is another, 
as is bytecode
manipulation.

regards,

- Leo, who wishes he'd learn to just shut up

Re: Reflection Bad, OO and direct Method invocation Good...

["John C. Dale" <jc...@downinthedesert.com>]

I have no problem with reflection for the instantiation of a policy 
*once* during the course of an applications' lifecycle.  However, using 
reflection rampantly for every user request will result in the vaunted 
and oft feared big Oh catastrophy.  If you have 1 + n reflection 
operations for every user request, the application performance relative 
to the reflection code will degrade exponentially with the increase of 
concurrent users to the system O(n exponential).

If its precise empirical data you're asking for, I would ask the same - 
99%?  ;)

The bottleneck is *always* at the database, which is constrained by the 
time it takes to shuttle bits-n-bytes back and forth from/to the 
database.  Software  optimization efforts at that level are wasted.  The 
nice thing, though, is that database technology has advanced to the 
extent that a 5ms query under no load doesn't degrade too fast under 
heavy user load - unlike reflection.

I have a feeling that many of the core developers on the team have 
already put an extensive amount of reflection into the system.  I have 
yet to see any code, but will be interested to do a performance 
evaluation on the existing kernel (if there is one :) .  Furthermore, 
I'm very interested in using probing utilities to discover the extent to 
which particular segments of code are slowing the system down.

How does an application 'not care if it is subject to reflection'? 
 Module isolation?  Low coupling?

I'll reiterate that a straight forward OO implementation will be easier 
to maintain than would something that relies heavily on being generic. 
 Usually, systems that are overly generic for the sake of saving 
development time spend far too much time developing a generic framework.

my2c

Best,

John C. Dale


Leo Simons wrote:

> John C. Dale wrote:
>
>> I'm concerned about your mention of reflection.  I really like 
>> reflection, and think it has many useful applications in the 
>> application development space, but should be kept out of any runtime 
>> application that has stringent scalability and performance requirements.
>
>
> it should be kept out of *any* code that has stringent performance 
> requirements.
> Indeed! One should know when to use the right tool.
>
> But in all applications I have ever developed using containers that 
> use reflection
> operations, (usually to do instantiation and facilitate late binding), 
> those operations
> have never turned out to be the bottleneck.
>
> 99% of time is spent doing I/O, waiting for locks, or doing actual 
> processing.
> If the development time gained by using some ingenious proxying or 
> reflection
> code you write once and use in the right place, is spent optimizing 
> the bottleneck
> code, your app becomes lighting fast.
>
> The trick is to write most of your application so that it does not 
> care whether
> it is subject to reflection of any kind at any point. If it turns out 
> that's your
> bottleneck, you can always take it out and replace it with something 
> efficient.
>
>> Here are some dramatic results:
>
>
> ehm. Why are they dramatic? Reflection is known to be slow, yes, but 
> I've yet
> to see hard figures showing it being the bottleneck in any realistic 
> system.
>
> cheers!
>
> - Leo
>
>
>
>
>

Re: Reflection Bad, OO and direct Method invocation Good...

[Leo Simons <le...@apache.org>]

John C. Dale wrote:

> I'm concerned about your mention of reflection.  I really like 
> reflection, and think it has many useful applications in the 
> application development space, but should be kept out of any runtime 
> application that has stringent scalability and performance requirements.

it should be kept out of *any* code that has stringent performance 
requirements.
Indeed! One should know when to use the right tool.

But in all applications I have ever developed using containers that use 
reflection
operations, (usually to do instantiation and facilitate late binding), 
those operations
have never turned out to be the bottleneck.

99% of time is spent doing I/O, waiting for locks, or doing actual 
processing.
If the development time gained by using some ingenious proxying or 
reflection
code you write once and use in the right place, is spent optimizing the 
bottleneck
code, your app becomes lighting fast.

The trick is to write most of your application so that it does not care 
whether
it is subject to reflection of any kind at any point. If it turns out 
that's your
bottleneck, you can always take it out and replace it with something 
efficient.

> Here are some dramatic results:

ehm. Why are they dramatic? Reflection is known to be slow, yes, but 
I've yet
to see hard figures showing it being the bottleneck in any realistic system.

cheers!

- Leo

RE: Reflection Bad, OO and direct Method invocation Good...

["Howard M. Lewis Ship" <hl...@comcast.net>]

HiveMind includes some stuff refactored out of Tapestry, not Hibernate (that's Gavin King's LGPL O/R
mapping framework).

HiveMind makes use of Javassist (MPL) to generate classes on-the-fly.  This sidesteps reflection in
a very nice, efficient way.

Javassist is very clever; it groks an approximation of Java language syntax (has some kind of parser
built in) and generates bytecode from that.  Makes doing sophisticated bytecode generation very,
very easy.

I did some tests that showed that using Javassist was a bit faster than dynamic proxies, and a lot
more memory efficient.

Please direct all Tapestry questions to tapestry-user@jakarta.apache.org.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
 

Re: Reflection Bad, OO and direct Method invocation Good...

[Alex Blewitt <Al...@ioshq.com>]

On Saturday, Aug 9, 2003, at 14:16 Europe/London, John C. Dale wrote:

> Although reflection allows an incredibly generic way to solve many 
> difficult problems, and really opens the door to completely grandios 
> perfectly idealistic genericititousness ;)  , a straight-forward OO 
> approach to solving the problems would 1) be faster and 2) be easier 
> to read and maintain.  I've seen reflection based approaches work, and 
> I've seen them bomb.

I'd like to disagree with 1). Sun have done a lot of work in the more 
recent VMs making reflection fly, just for this kind of purpose. With a 
Method.invoke() you get a call-time similar to calling static methods 
(which don't require any messy inheritance searching for the correct 
method call in sub/super classes). Since the Method contains the 
reference to the class that it's defined in, inheritance doesn't play a 
part (unless that Method is defined as abstract, such as an interface 
or abstract class, obviously ;-)

I'd completely agree with 2), though -- but I'd suggest that reflection 
has its uses in low-level routines rather than in every step.

Re: Reflection Bad, OO and direct Method invocation Good...

["John C. Dale" <jc...@downinthedesert.com>]

Aaron Mulder wrote:

>On Sat, 9 Aug 2003, John C. Dale wrote:
>  
>
>>Microbenchmarks can in fact be misleading when we aren't talking about 
>>as much as a factor of 10!  Reflection, in the best case scenario below, 
>>was a factor of 10 slower!  The bottom line is that reflection takes a 
>>lot more electricity than does non-reflection.
>>    
>>
>
>	No, really, it can be misleading by a factor of 10.  The compiler
>or VM can "do things" (like inlining a method when you're testing the time
>it takes to call different kinds of methods) that totally defeat a
>microbenchmark.  I will certainly agree that "reflection is significantly
>slower", but I don't think it's valuable to point to specific numbers on a
>benchmark like you showed.
>  
>
So we're in agreement then that reflection is slower, regardless of the 
benchmark's presence in my argument.  I always like to have some 
supporting empirical evidence - a habit, really...but as long as we're 
in agreement on that point.

>  
>
>>You are absolutely right in that the round trip to the database is going 
>>to consume more time for the life of the user request than is a sequence 
>>of reflection-based calls.  That will always be the bottleneck in 
>>systems that don't have any kind of intelligent middle-tier cache - but 
>>wait, there's more!
>>
>>Entity EJBS are just that (a cache) aren't they?  Through intelligent 
>>caching and good design of our applications, we're able to avoid the 
>>extra knocks on the database if the entity of our type with our PK has 
>>already been loaded.  This, in my mind, is one of the chief advantages 
>>of using Entity Beans; throughput.  This throughput will definitely be 
>>impacted negatively if there are several reflection calls for each user 
>>request as the system comes under (and maintains) load.  Furthermore, 
>>although the bottleneck is clearly the round trip to the database for 
>>the hydration/storage of data, the time it takes to get to the point of 
>>JDBC query invocation will be effected negatively if reflection is used 
>>- this effect becomes more pronounced as the system comes under heavy 
>>load.  The sooner the JDBC query starts, the sooner it will finish.
>>    
>>
>
>	In my experience, slow EJB apps can be attributed to the frequency
>and nature of the JDBC calls and/or application problems far more often
>than the server technology.  In other words, it's pretty rare to find an
>EJB performance problem that can't be addressed without altering something
>like whether the server uses reflection.  And in response to "the JDBC
>request that starts faster finishes faster", granted, but I refer you to
>my response to Frankie -- you won't notice any difference if every JDBC
>request finishes 0.00002 seconds faster (and that's being generous).
>  
>
And let's not forget the people writing the SQL - you are right IMHO, 
but with one additional qualification.  The SQL that is being executed 
is far more often the culprite than is the JDBC implementation.  In my 
experience, I've found that stable releases of most JDBC drivers are 
very nice.  So much revolves around the application design (the web/EJB 
app, not the container) and implementation, and we are *all* in 
agreement that bad developers write bad apps no matter how fast/good the 
platform.

>  
>
>>I would also note that 'optimizing away' performance issues due to 
>>reflection (assuming that the core of the system is based on reflection) 
>>is MUCH easier to type than it is to implement.  If we see the train 
>>coming now, why don't we get out of the way...now?
>>    
>>
>
>	You're implicitly asserting that reflection has no advantage.  
>Agreed, if reflection has no advantage and costs performance, we should
>avoid it.  I would argue that such is not the case, and the reflection
>code:
>
> - is more straightforward/less buggy than generating custom Java code
>during deployment (due to comments, exception handling, version control,
>etc.)
>
> - is dramatically faster to start up then writing out Java code, running
>the compiler, and reading the classes back in
>
> - reduces the amount of code an EJB client is required to have access to
>(1 server JAR and the code written by the EJB developer, instead of 1
>server JAR plus 1 server JAR per EJB JAR in addition to the code written
>by the EJB developer)
>
> - has less of an impact on debugging (vs. getting errors originating in
>classes that the server generated)
>
> - allows common code such as passing control to a chain of interceptors
>to be written and compiled and tested in one place by a server developer,
>instead of being generated into every method in every EJB
>
> - gives the server developers more options for how to handle the passing 
>of requests over the network, and again lets that code be written once and 
>version controlled and so on rather than forcing us to maintain the code 
>that writes the code.
>
>	Well, that's what I can think of for now, and overall, I'd say 
>it's well worth a few microseconds on every request.
>
>Aaron
>
>
>  
>
I have yet to see the code, so I am happy to suspend judgement regarding 
the advantage point until I get the opportunity to get a really critical 
look at the implementation you have in mind.  Coincidentally, you made 
the point very well and also suggest an alternative that hasn't worked 
in the past.  It's almost as though you've argued this issue before. 
 hmmmm...

Thanks for taking the time to make your points, and they are well taken. 
 I will be watching the implementation closely and will be happy to 
reverse-engineer documentation and do some performance probing to reduce 
the risk(s) of embedding significant amounts of (hopefully isolated) 
reflection into the kernel.

Best,

John C. Dale
Professional Services
Compuware

>  
>

Re: [aspects] Re: Reflection Bad, OO and direct Method invocation Good...

[James Strachan <ja...@yahoo.co.uk>]

Agreed. FWIW already AspectWerkz can dynamically weave aspects into 
Java code at deployment time using a special ClassLoader which performs 
the necessary bytecode swizzling to insert the aspects.

http://aspectwerkz.codehaus.org


On Sunday, August 10, 2003, at 05:10  pm, Jules Gosnell wrote:

> let me subvert this thread a little...
>
> for the future...
>
> If  you step back a little and look again at the precompiled and 
> dynamically aggregated containers, I think you would find that they 
> could both  be decomposed into aspects in a pretty similar way. The 
> difference is simply in the choice of how to implement those aspects.
>
> The thing that I find exciting is that from only a little bit of 
> reading around aspects it looks as if it will soon be possible (if it 
> is not already) to weave the same set of aspects at either compile or 
> deploy/run time. Whether the aspect guys will be able to be as 
> efficient at deploy-time weaving as they can at compile-time is a 
> matter for an aspect list, but I suspect that compile time weaved 
> aspects will not be any slower than a custom compiled container and 
> deploy-time weaving will be considerable more efficient than existing 
> run time interceptor frameworks.
>
> So, in short, I think that the gap between compile time and deploy 
> time container composition is probably shrinking into irrelevance, 
> which is good news as it means that both teams can concentrate on a 
> single impl - competition is good, but right now I think it should be 
> all hands on deck to get something out there...
>
> Jules
>
>
> Greg Wilkins wrote:
>
>>
>> Even if we are able to support two or more EJB containers, I would
>> never recommend using different ones for development and deployment.
>> That, as you say, is just asking for inconsistencies to cause grief.
>>
>> But some users may choose to give up the benefits of the dynamics
>> during development for a compiled container - because either they
>> really want/need every nano seconds of latency reduced or because
>> their culture is opposed to dynamics on production machines.
>>
>> If there are really several diametrically opposed ways of doing
>> EJBs - then it would be great if geronimo could support them all.
>> But then I have little idea of the amount of work required to
>> come up with AbstractEJBContainer.
>>
>> cheers
>>
>>
>> Test Account wrote:
>>
>>> Greg,
>>>
>>>     Absolutely, that was the gist of what I was trying to say, 
>>> albeit,
>>> somewhat poorly.  You want the fast dynamic development deployment
>>> capabilities while banging out endless refactorings.  But when it 
>>> comes time
>>> to deploy in a scalable environment you may need to eek every last 
>>> drop of
>>> performance, so may need the compiled skeletons.  It would be great 
>>> to have
>>> both.  The problem would be in guaranteeing consistency between the 
>>> two
>>> paths.  I wouldn't want to get differing behavior when running in
>>> development from when running in production.
>>>
>>> Enjoy,
>>>
>>> Craig
>>>
>>> ----- Original Message ----- From: "Greg Wilkins" <gr...@mortbay.com>
>>> To: <ge...@incubator.apache.org>
>>> Sent: Sunday, August 10, 2003 1:07 AM
>>> Subject: Re: Reflection Bad, OO and direct Method invocation Good...
>>>
>>>
>>>
>>>> I don't know if this falls into the "too much choice is a bad thing"
>>>> arena, but would it not be good if we could have both a dynamic 
>>>> jboss
>>>> inspired EJB container and a compiled EJB container (perhaps from
>>>> or inspired by the JOnAS folks??).
>>>>
>>>> -- 
>>>> Greg Wilkins<gr...@mortbay.com>             Phone/fax: +44 
>>>> 7092063462
>>>> Mort Bay Consulting Australia and UK.          
>>>> http://www.mortbay.com
>>>>
>>
>>
>
>
> -- 
> /*************************************
> * Jules Gosnell
> * Partner
> * Core Developers Network (Europe)
> * http://www.coredevelopers.net
> *************************************/
>
>

James
-------
http://radio.weblogs.com/0112098/

[aspects] Re: Reflection Bad, OO and direct Method invocation Good...

[Jules Gosnell <ju...@coredevelopers.net>]

let me subvert this thread a little...

for the future...

If  you step back a little and look again at the precompiled and 
dynamically aggregated containers, I think you would find that they 
could both  be decomposed into aspects in a pretty similar way. The 
difference is simply in the choice of how to implement those aspects.

The thing that I find exciting is that from only a little bit of reading 
around aspects it looks as if it will soon be possible (if it is not 
already) to weave the same set of aspects at either compile or 
deploy/run time. Whether the aspect guys will be able to be as efficient 
at deploy-time weaving as they can at compile-time is a matter for an 
aspect list, but I suspect that compile time weaved aspects will not be 
any slower than a custom compiled container and deploy-time weaving will 
be considerable more efficient than existing run time interceptor 
frameworks.

So, in short, I think that the gap between compile time and deploy time 
container composition is probably shrinking into irrelevance, which is 
good news as it means that both teams can concentrate on a single impl - 
competition is good, but right now I think it should be all hands on 
deck to get something out there...

Jules


Greg Wilkins wrote:

>
> Even if we are able to support two or more EJB containers, I would
> never recommend using different ones for development and deployment.
> That, as you say, is just asking for inconsistencies to cause grief.
>
> But some users may choose to give up the benefits of the dynamics
> during development for a compiled container - because either they
> really want/need every nano seconds of latency reduced or because
> their culture is opposed to dynamics on production machines.
>
> If there are really several diametrically opposed ways of doing
> EJBs - then it would be great if geronimo could support them all.
> But then I have little idea of the amount of work required to
> come up with AbstractEJBContainer.
>
> cheers
>
>
> Test Account wrote:
>
>> Greg,
>>
>>     Absolutely, that was the gist of what I was trying to say, albeit,
>> somewhat poorly.  You want the fast dynamic development deployment
>> capabilities while banging out endless refactorings.  But when it 
>> comes time
>> to deploy in a scalable environment you may need to eek every last 
>> drop of
>> performance, so may need the compiled skeletons.  It would be great 
>> to have
>> both.  The problem would be in guaranteeing consistency between the two
>> paths.  I wouldn't want to get differing behavior when running in
>> development from when running in production.
>>
>> Enjoy,
>>
>> Craig
>>
>> ----- Original Message ----- From: "Greg Wilkins" <gr...@mortbay.com>
>> To: <ge...@incubator.apache.org>
>> Sent: Sunday, August 10, 2003 1:07 AM
>> Subject: Re: Reflection Bad, OO and direct Method invocation Good...
>>
>>
>>
>>> I don't know if this falls into the "too much choice is a bad thing"
>>> arena, but would it not be good if we could have both a dynamic jboss
>>> inspired EJB container and a compiled EJB container (perhaps from
>>> or inspired by the JOnAS folks??).
>>>
>>> -- 
>>> Greg Wilkins<gr...@mortbay.com>             Phone/fax: +44 7092063462
>>> Mort Bay Consulting Australia and UK.          http://www.mortbay.com
>>>
>
>


-- 
/*************************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 * http://www.coredevelopers.net
 *************************************/

Re: Reflection Bad, OO and direct Method invocation Good...

[Greg Wilkins <gr...@mortbay.com>]

Even if we are able to support two or more EJB containers, I would
never recommend using different ones for development and deployment.
That, as you say, is just asking for inconsistencies to cause grief.

But some users may choose to give up the benefits of the dynamics
during development for a compiled container - because either they
really want/need every nano seconds of latency reduced or because
their culture is opposed to dynamics on production machines.

If there are really several diametrically opposed ways of doing
EJBs - then it would be great if geronimo could support them all.
But then I have little idea of the amount of work required to
come up with AbstractEJBContainer.

cheers


Test Account wrote:
> Greg,
> 
>     Absolutely, that was the gist of what I was trying to say, albeit,
> somewhat poorly.  You want the fast dynamic development deployment
> capabilities while banging out endless refactorings.  But when it comes time
> to deploy in a scalable environment you may need to eek every last drop of
> performance, so may need the compiled skeletons.  It would be great to have
> both.  The problem would be in guaranteeing consistency between the two
> paths.  I wouldn't want to get differing behavior when running in
> development from when running in production.
> 
> Enjoy,
> 
> Craig
> 
> ----- Original Message ----- 
> From: "Greg Wilkins" <gr...@mortbay.com>
> To: <ge...@incubator.apache.org>
> Sent: Sunday, August 10, 2003 1:07 AM
> Subject: Re: Reflection Bad, OO and direct Method invocation Good...
> 
> 
> 
>>I don't know if this falls into the "too much choice is a bad thing"
>>arena, but would it not be good if we could have both a dynamic jboss
>>inspired EJB container and a compiled EJB container (perhaps from
>>or inspired by the JOnAS folks??).
>>
>>-- 
>>Greg Wilkins<gr...@mortbay.com>             Phone/fax: +44 7092063462
>>Mort Bay Consulting Australia and UK.          http://www.mortbay.com
>>


-- 
Greg Wilkins<gr...@mortbay.com>             Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK.          http://www.mortbay.com

Re: Reflection Bad, OO and direct Method invocation Good...

[Test Account <cm...@earthlink.net>]

Greg,

    Absolutely, that was the gist of what I was trying to say, albeit,
somewhat poorly.  You want the fast dynamic development deployment
capabilities while banging out endless refactorings.  But when it comes time
to deploy in a scalable environment you may need to eek every last drop of
performance, so may need the compiled skeletons.  It would be great to have
both.  The problem would be in guaranteeing consistency between the two
paths.  I wouldn't want to get differing behavior when running in
development from when running in production.

Enjoy,

Craig

----- Original Message ----- 
From: "Greg Wilkins" <gr...@mortbay.com>
To: <ge...@incubator.apache.org>
Sent: Sunday, August 10, 2003 1:07 AM
Subject: Re: Reflection Bad, OO and direct Method invocation Good...


>
> I don't know if this falls into the "too much choice is a bad thing"
> arena, but would it not be good if we could have both a dynamic jboss
> inspired EJB container and a compiled EJB container (perhaps from
> or inspired by the JOnAS folks??).
>
> -- 
> Greg Wilkins<gr...@mortbay.com>             Phone/fax: +44 7092063462
> Mort Bay Consulting Australia and UK.          http://www.mortbay.com
>

Re: Reflection Bad, OO and direct Method invocation Good...

[Greg Wilkins <gr...@mortbay.com>]

I don't know if this falls into the "too much choice is a bad thing"
arena, but would it not be good if we could have both a dynamic jboss
inspired EJB container and a compiled EJB container (perhaps from
or inspired by the JOnAS folks??).

-- 
Greg Wilkins<gr...@mortbay.com>             Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK.          http://www.mortbay.com

Re: Reflection Bad, OO and direct Method invocation Good...

[Robert McIntosh <ro...@bull-enterprises.com>]

I have to agree partially with Craig here. I would venture to say that 
most of those many thousand users of JBoss use it for development where 
they do not have to run a separate compiler (actually a code generator), 
compile again, then package yet again and deploy. I agree that dynamic 
proxies will be slower, but that doesn't mean that a class generator at 
runtime couldn't take the place of that proxy. As a developer, I should 
be able to take my EJBs, compiled once I might add, package and drop 
into some deploy directory and let the container take it from there. It 
is a massive time saver during development.

Robert

Test Account wrote:

>    Reflection and dynamic proxies are a good thing in EJB containers.  To
>bear this out, deploy and ear file on JBoss.  Now deploy the same
>application on Orion/OC4J. Do this 1000s of times during development.
>Consider the time lost watching Orion complain and fail compiling generated
>classes.  Consider the time the development team loses waiting for this step
>to occur repeatedly even when the deployment is successful.  Now actually
>make a few requests on the application.  Do you notice any difference?
>    It seems that this issue may be related to the lazy loading development
>vs production deploy discussion in that a bifurcated deployment option *may*
>be of use.  Anyone care to write an production option alternative to
>reflection because they believe in the savings?  This is certainly something
>which can be done *should* it be demonstrable that reflection shows any
>degradation of performance in a working container.
>
>Craig
>
>
>
>
>
>----- Original Message ----- 
>From: "Aaron Mulder" <am...@alumni.princeton.edu>
>To: <ge...@incubator.apache.org>
>Sent: Saturday, August 09, 2003 9:38 AM
>Subject: Re: Reflection Bad, OO and direct Method invocation Good...
>
>
>  
>
>>On Sat, 9 Aug 2003, John C. Dale wrote:
>>    
>>
>>>Microbenchmarks can in fact be misleading when we aren't talking about
>>>as much as a factor of 10!  Reflection, in the best case scenario below,
>>>was a factor of 10 slower!  The bottom line is that reflection takes a
>>>lot more electricity than does non-reflection.
>>>      
>>>
>>No, really, it can be misleading by a factor of 10.  The compiler
>>or VM can "do things" (like inlining a method when you're testing the time
>>it takes to call different kinds of methods) that totally defeat a
>>microbenchmark.  I will certainly agree that "reflection is significantly
>>slower", but I don't think it's valuable to point to specific numbers on a
>>benchmark like you showed.
>>
>>    
>>
>>>You are absolutely right in that the round trip to the database is going
>>>to consume more time for the life of the user request than is a sequence
>>>of reflection-based calls.  That will always be the bottleneck in
>>>systems that don't have any kind of intelligent middle-tier cache - but
>>>wait, there's more!
>>>
>>>Entity EJBS are just that (a cache) aren't they?  Through intelligent
>>>caching and good design of our applications, we're able to avoid the
>>>extra knocks on the database if the entity of our type with our PK has
>>>already been loaded.  This, in my mind, is one of the chief advantages
>>>of using Entity Beans; throughput.  This throughput will definitely be
>>>impacted negatively if there are several reflection calls for each user
>>>request as the system comes under (and maintains) load.  Furthermore,
>>>although the bottleneck is clearly the round trip to the database for
>>>the hydration/storage of data, the time it takes to get to the point of
>>>JDBC query invocation will be effected negatively if reflection is used
>>>- this effect becomes more pronounced as the system comes under heavy
>>>load.  The sooner the JDBC query starts, the sooner it will finish.
>>>      
>>>
>>In my experience, slow EJB apps can be attributed to the frequency
>>and nature of the JDBC calls and/or application problems far more often
>>than the server technology.  In other words, it's pretty rare to find an
>>EJB performance problem that can't be addressed without altering something
>>like whether the server uses reflection.  And in response to "the JDBC
>>request that starts faster finishes faster", granted, but I refer you to
>>my response to Frankie -- you won't notice any difference if every JDBC
>>request finishes 0.00002 seconds faster (and that's being generous).
>>
>>    
>>
>>>I would also note that 'optimizing away' performance issues due to
>>>reflection (assuming that the core of the system is based on reflection)
>>>is MUCH easier to type than it is to implement.  If we see the train
>>>coming now, why don't we get out of the way...now?
>>>      
>>>
>>You're implicitly asserting that reflection has no advantage.
>>Agreed, if reflection has no advantage and costs performance, we should
>>avoid it.  I would argue that such is not the case, and the reflection
>>code:
>>
>> - is more straightforward/less buggy than generating custom Java code
>>during deployment (due to comments, exception handling, version control,
>>etc.)
>>
>> - is dramatically faster to start up then writing out Java code, running
>>the compiler, and reading the classes back in
>>
>> - reduces the amount of code an EJB client is required to have access to
>>(1 server JAR and the code written by the EJB developer, instead of 1
>>server JAR plus 1 server JAR per EJB JAR in addition to the code written
>>by the EJB developer)
>>
>> - has less of an impact on debugging (vs. getting errors originating in
>>classes that the server generated)
>>
>> - allows common code such as passing control to a chain of interceptors
>>to be written and compiled and tested in one place by a server developer,
>>instead of being generated into every method in every EJB
>>
>> - gives the server developers more options for how to handle the passing
>>of requests over the network, and again lets that code be written once and
>>version controlled and so on rather than forcing us to maintain the code
>>that writes the code.
>>
>>Well, that's what I can think of for now, and overall, I'd say
>>it's well worth a few microseconds on every request.
>>
>>Aaron
>>
>>    
>>
>
>  
>

Re: Reflection Bad, OO and direct Method invocation Good...

["John C. Dale" <jc...@downinthedesert.com>]

Test Account wrote:

>    Reflection and dynamic proxies are a good thing in EJB containers.  To
>bear this out, deploy and ear file on JBoss.  Now deploy the same
>application on Orion/OC4J. Do this 1000s of times during development.
>Consider the time lost watching Orion complain and fail compiling generated
>classes.  Consider the time the development team loses waiting for this step
>to occur repeatedly even when the deployment is successful.  Now actually
>make a few requests on the application.  Do you notice any difference?
>    It seems that this issue may be related to the lazy loading development
>vs production deploy discussion in that a bifurcated deployment option *may*
>be of use.  Anyone care to write an production option alternative to
>reflection because they believe in the savings?  This is certainly something
>which can be done *should* it be demonstrable that reflection shows any
>degradation of performance in a working container.
>
>Craig
>
>
>  
>
Just one point on this.  Any difference between the two containers would 
never be noticed by a single human user/development.  It is under load, 
then thousands of potential concurrent users are dingin' the system that 
we really might want to start being more frugal with CPU.

Your points are well taken, though.

John C. Dale
Professional Services
Compuware

>
>
>----- Original Message ----- 
>From: "Aaron Mulder" <am...@alumni.princeton.edu>
>To: <ge...@incubator.apache.org>
>Sent: Saturday, August 09, 2003 9:38 AM
>Subject: Re: Reflection Bad, OO and direct Method invocation Good...
>
>
>  
>
>>On Sat, 9 Aug 2003, John C. Dale wrote:
>>    
>>
>>>Microbenchmarks can in fact be misleading when we aren't talking about
>>>as much as a factor of 10!  Reflection, in the best case scenario below,
>>>was a factor of 10 slower!  The bottom line is that reflection takes a
>>>lot more electricity than does non-reflection.
>>>      
>>>
>>No, really, it can be misleading by a factor of 10.  The compiler
>>or VM can "do things" (like inlining a method when you're testing the time
>>it takes to call different kinds of methods) that totally defeat a
>>microbenchmark.  I will certainly agree that "reflection is significantly
>>slower", but I don't think it's valuable to point to specific numbers on a
>>benchmark like you showed.
>>
>>    
>>
>>>You are absolutely right in that the round trip to the database is going
>>>to consume more time for the life of the user request than is a sequence
>>>of reflection-based calls.  That will always be the bottleneck in
>>>systems that don't have any kind of intelligent middle-tier cache - but
>>>wait, there's more!
>>>
>>>Entity EJBS are just that (a cache) aren't they?  Through intelligent
>>>caching and good design of our applications, we're able to avoid the
>>>extra knocks on the database if the entity of our type with our PK has
>>>already been loaded.  This, in my mind, is one of the chief advantages
>>>of using Entity Beans; throughput.  This throughput will definitely be
>>>impacted negatively if there are several reflection calls for each user
>>>request as the system comes under (and maintains) load.  Furthermore,
>>>although the bottleneck is clearly the round trip to the database for
>>>the hydration/storage of data, the time it takes to get to the point of
>>>JDBC query invocation will be effected negatively if reflection is used
>>>- this effect becomes more pronounced as the system comes under heavy
>>>load.  The sooner the JDBC query starts, the sooner it will finish.
>>>      
>>>
>>In my experience, slow EJB apps can be attributed to the frequency
>>and nature of the JDBC calls and/or application problems far more often
>>than the server technology.  In other words, it's pretty rare to find an
>>EJB performance problem that can't be addressed without altering something
>>like whether the server uses reflection.  And in response to "the JDBC
>>request that starts faster finishes faster", granted, but I refer you to
>>my response to Frankie -- you won't notice any difference if every JDBC
>>request finishes 0.00002 seconds faster (and that's being generous).
>>
>>    
>>
>>>I would also note that 'optimizing away' performance issues due to
>>>reflection (assuming that the core of the system is based on reflection)
>>>is MUCH easier to type than it is to implement.  If we see the train
>>>coming now, why don't we get out of the way...now?
>>>      
>>>
>>You're implicitly asserting that reflection has no advantage.
>>Agreed, if reflection has no advantage and costs performance, we should
>>avoid it.  I would argue that such is not the case, and the reflection
>>code:
>>
>> - is more straightforward/less buggy than generating custom Java code
>>during deployment (due to comments, exception handling, version control,
>>etc.)
>>
>> - is dramatically faster to start up then writing out Java code, running
>>the compiler, and reading the classes back in
>>
>> - reduces the amount of code an EJB client is required to have access to
>>(1 server JAR and the code written by the EJB developer, instead of 1
>>server JAR plus 1 server JAR per EJB JAR in addition to the code written
>>by the EJB developer)
>>
>> - has less of an impact on debugging (vs. getting errors originating in
>>classes that the server generated)
>>
>> - allows common code such as passing control to a chain of interceptors
>>to be written and compiled and tested in one place by a server developer,
>>instead of being generated into every method in every EJB
>>
>> - gives the server developers more options for how to handle the passing
>>of requests over the network, and again lets that code be written once and
>>version controlled and so on rather than forcing us to maintain the code
>>that writes the code.
>>
>>Well, that's what I can think of for now, and overall, I'd say
>>it's well worth a few microseconds on every request.
>>
>>Aaron
>>
>>    
>>
>
>
>
>  
>

Re: Reflection Bad, OO and direct Method invocation Good...

[Test Account <cm...@earthlink.net>]

    Reflection and dynamic proxies are a good thing in EJB containers.  To
bear this out, deploy and ear file on JBoss.  Now deploy the same
application on Orion/OC4J. Do this 1000s of times during development.
Consider the time lost watching Orion complain and fail compiling generated
classes.  Consider the time the development team loses waiting for this step
to occur repeatedly even when the deployment is successful.  Now actually
make a few requests on the application.  Do you notice any difference?
    It seems that this issue may be related to the lazy loading development
vs production deploy discussion in that a bifurcated deployment option *may*
be of use.  Anyone care to write an production option alternative to
reflection because they believe in the savings?  This is certainly something
which can be done *should* it be demonstrable that reflection shows any
degradation of performance in a working container.

Craig





----- Original Message ----- 
From: "Aaron Mulder" <am...@alumni.princeton.edu>
To: <ge...@incubator.apache.org>
Sent: Saturday, August 09, 2003 9:38 AM
Subject: Re: Reflection Bad, OO and direct Method invocation Good...


> On Sat, 9 Aug 2003, John C. Dale wrote:
> > Microbenchmarks can in fact be misleading when we aren't talking about
> > as much as a factor of 10!  Reflection, in the best case scenario below,
> > was a factor of 10 slower!  The bottom line is that reflection takes a
> > lot more electricity than does non-reflection.
>
> No, really, it can be misleading by a factor of 10.  The compiler
> or VM can "do things" (like inlining a method when you're testing the time
> it takes to call different kinds of methods) that totally defeat a
> microbenchmark.  I will certainly agree that "reflection is significantly
> slower", but I don't think it's valuable to point to specific numbers on a
> benchmark like you showed.
>
> > You are absolutely right in that the round trip to the database is going
> > to consume more time for the life of the user request than is a sequence
> > of reflection-based calls.  That will always be the bottleneck in
> > systems that don't have any kind of intelligent middle-tier cache - but
> > wait, there's more!
> >
> > Entity EJBS are just that (a cache) aren't they?  Through intelligent
> > caching and good design of our applications, we're able to avoid the
> > extra knocks on the database if the entity of our type with our PK has
> > already been loaded.  This, in my mind, is one of the chief advantages
> > of using Entity Beans; throughput.  This throughput will definitely be
> > impacted negatively if there are several reflection calls for each user
> > request as the system comes under (and maintains) load.  Furthermore,
> > although the bottleneck is clearly the round trip to the database for
> > the hydration/storage of data, the time it takes to get to the point of
> > JDBC query invocation will be effected negatively if reflection is used
> > - this effect becomes more pronounced as the system comes under heavy
> > load.  The sooner the JDBC query starts, the sooner it will finish.
>
> In my experience, slow EJB apps can be attributed to the frequency
> and nature of the JDBC calls and/or application problems far more often
> than the server technology.  In other words, it's pretty rare to find an
> EJB performance problem that can't be addressed without altering something
> like whether the server uses reflection.  And in response to "the JDBC
> request that starts faster finishes faster", granted, but I refer you to
> my response to Frankie -- you won't notice any difference if every JDBC
> request finishes 0.00002 seconds faster (and that's being generous).
>
> > I would also note that 'optimizing away' performance issues due to
> > reflection (assuming that the core of the system is based on reflection)
> > is MUCH easier to type than it is to implement.  If we see the train
> > coming now, why don't we get out of the way...now?
>
> You're implicitly asserting that reflection has no advantage.
> Agreed, if reflection has no advantage and costs performance, we should
> avoid it.  I would argue that such is not the case, and the reflection
> code:
>
>  - is more straightforward/less buggy than generating custom Java code
> during deployment (due to comments, exception handling, version control,
> etc.)
>
>  - is dramatically faster to start up then writing out Java code, running
> the compiler, and reading the classes back in
>
>  - reduces the amount of code an EJB client is required to have access to
> (1 server JAR and the code written by the EJB developer, instead of 1
> server JAR plus 1 server JAR per EJB JAR in addition to the code written
> by the EJB developer)
>
>  - has less of an impact on debugging (vs. getting errors originating in
> classes that the server generated)
>
>  - allows common code such as passing control to a chain of interceptors
> to be written and compiled and tested in one place by a server developer,
> instead of being generated into every method in every EJB
>
>  - gives the server developers more options for how to handle the passing
> of requests over the network, and again lets that code be written once and
> version controlled and so on rather than forcing us to maintain the code
> that writes the code.
>
> Well, that's what I can think of for now, and overall, I'd say
> it's well worth a few microseconds on every request.
>
> Aaron
>

Re: Reflection Bad, OO and direct Method invocation Good...

[Dain Sundstrom <da...@coredevelopers.net>]

On Saturday, August 9, 2003, at 10:38 AM, Aaron Mulder wrote:

> On Sat, 9 Aug 2003, John C. Dale wrote:
>> Microbenchmarks can in fact be misleading when we aren't talking about
>> as much as a factor of 10!  Reflection, in the best case scenario 
>> below,
>> was a factor of 10 slower!  The bottom line is that reflection takes a
>> lot more electricity than does non-reflection.
>
> 	No, really, it can be misleading by a factor of 10.  The compiler
> or VM can "do things" (like inlining a method when you're testing the 
> time
> it takes to call different kinds of methods) that totally defeat a
> microbenchmark.  I will certainly agree that "reflection is 
> significantly
> slower", but I don't think it's valuable to point to specific numbers 
> on a
> benchmark like you showed.

To truly test the speed of a direct invocation you need to give the VM 
something it cannot inline.  The only way I know how to do that is to 
make the method you are calling just under the maximum method size, 64k.

-dain

Re: Reflection Bad, OO and direct Method invocation Good...

[Aaron Mulder <am...@alumni.princeton.edu>]

On Sat, 9 Aug 2003, John C. Dale wrote:
> Microbenchmarks can in fact be misleading when we aren't talking about 
> as much as a factor of 10!  Reflection, in the best case scenario below, 
> was a factor of 10 slower!  The bottom line is that reflection takes a 
> lot more electricity than does non-reflection.

	No, really, it can be misleading by a factor of 10.  The compiler
or VM can "do things" (like inlining a method when you're testing the time
it takes to call different kinds of methods) that totally defeat a
microbenchmark.  I will certainly agree that "reflection is significantly
slower", but I don't think it's valuable to point to specific numbers on a
benchmark like you showed.

> You are absolutely right in that the round trip to the database is going 
> to consume more time for the life of the user request than is a sequence 
> of reflection-based calls.  That will always be the bottleneck in 
> systems that don't have any kind of intelligent middle-tier cache - but 
> wait, there's more!
> 
> Entity EJBS are just that (a cache) aren't they?  Through intelligent 
> caching and good design of our applications, we're able to avoid the 
> extra knocks on the database if the entity of our type with our PK has 
> already been loaded.  This, in my mind, is one of the chief advantages 
> of using Entity Beans; throughput.  This throughput will definitely be 
> impacted negatively if there are several reflection calls for each user 
> request as the system comes under (and maintains) load.  Furthermore, 
> although the bottleneck is clearly the round trip to the database for 
> the hydration/storage of data, the time it takes to get to the point of 
> JDBC query invocation will be effected negatively if reflection is used 
> - this effect becomes more pronounced as the system comes under heavy 
> load.  The sooner the JDBC query starts, the sooner it will finish.

	In my experience, slow EJB apps can be attributed to the frequency
and nature of the JDBC calls and/or application problems far more often
than the server technology.  In other words, it's pretty rare to find an
EJB performance problem that can't be addressed without altering something
like whether the server uses reflection.  And in response to "the JDBC
request that starts faster finishes faster", granted, but I refer you to
my response to Frankie -- you won't notice any difference if every JDBC
request finishes 0.00002 seconds faster (and that's being generous).

> I would also note that 'optimizing away' performance issues due to 
> reflection (assuming that the core of the system is based on reflection) 
> is MUCH easier to type than it is to implement.  If we see the train 
> coming now, why don't we get out of the way...now?

	You're implicitly asserting that reflection has no advantage.  
Agreed, if reflection has no advantage and costs performance, we should
avoid it.  I would argue that such is not the case, and the reflection
code:

 - is more straightforward/less buggy than generating custom Java code
during deployment (due to comments, exception handling, version control,
etc.)

 - is dramatically faster to start up then writing out Java code, running
the compiler, and reading the classes back in

 - reduces the amount of code an EJB client is required to have access to
(1 server JAR and the code written by the EJB developer, instead of 1
server JAR plus 1 server JAR per EJB JAR in addition to the code written
by the EJB developer)

 - has less of an impact on debugging (vs. getting errors originating in
classes that the server generated)

 - allows common code such as passing control to a chain of interceptors
to be written and compiled and tested in one place by a server developer,
instead of being generated into every method in every EJB

 - gives the server developers more options for how to handle the passing 
of requests over the network, and again lets that code be written once and 
version controlled and so on rather than forcing us to maintain the code 
that writes the code.

	Well, that's what I can think of for now, and overall, I'd say 
it's well worth a few microseconds on every request.

Aaron

Re: Reflection Bad, OO and direct Method invocation Good...

["John C. Dale" <jc...@downinthedesert.com>]

Microbenchmarks can in fact be misleading when we aren't talking about 
as much as a factor of 10!  Reflection, in the best case scenario below, 
was a factor of 10 slower!  The bottom line is that reflection takes a 
lot more electricity than does non-reflection.

You are absolutely right in that the round trip to the database is going 
to consume more time for the life of the user request than is a sequence 
of reflection-based calls.  That will always be the bottleneck in 
systems that don't have any kind of intelligent middle-tier cache - but 
wait, there's more!

Entity EJBS are just that (a cache) aren't they?  Through intelligent 
caching and good design of our applications, we're able to avoid the 
extra knocks on the database if the entity of our type with our PK has 
already been loaded.  This, in my mind, is one of the chief advantages 
of using Entity Beans; throughput.  This throughput will definitely be 
impacted negatively if there are several reflection calls for each user 
request as the system comes under (and maintains) load.  Furthermore, 
although the bottleneck is clearly the round trip to the database for 
the hydration/storage of data, the time it takes to get to the point of 
JDBC query invocation will be effected negatively if reflection is used 
- this effect becomes more pronounced as the system comes under heavy 
load.  The sooner the JDBC query starts, the sooner it will finish.

I would also note that 'optimizing away' performance issues due to 
reflection (assuming that the core of the system is based on reflection) 
is MUCH easier to type than it is to implement.  If we see the train 
coming now, why don't we get out of the way...now?

Best,

John C. Dale
Professional Services
Compuware


Aaron Mulder wrote:

>	First of all, can we agree that microbenchmarks are dangerous?
>
>	But all that aside, try 1 million HTTP requests, or 1 million
>iterations of a JDBC query, and then provide a ratio between JDBC/HTTP
>time and reflection time.  If you can perform a million requests of either
>type in 30 seconds I'd be shocked, and that's two orders of magnitude.
>
>	IMHO, reflection is something that can be optimized away later,
>once it becomes the bottleneck on performance.  I don't think we need to 
>avoid it from the outset, because I don't think it will be the bottleneck 
>at the outset.
>
>Aaron
>
>On Sat, 9 Aug 2003, John C. Dale wrote:
>  
>
>>I'm concerned about your mention of reflection.  I really like 
>>reflection, and think it has many useful applications in the application 
>>development space, but should be kept out of any runtime application 
>>that has stringent scalability and performance requirements.  Although 
>>reflection allows an incredibly generic way to solve many difficult 
>>problems, and really opens the door to completely grandios perfectly 
>>idealistic genericititousness ;)  , a straight-forward OO approach to 
>>solving the problems would 1) be faster and 2) be easier to read and 
>>maintain.  I've seen reflection based approaches work, and I've seen 
>>them bomb.
>>
>>One might argue that in a container based system that will eventually 
>>support clustering and scalability doesn't have to worry about savoring 
>>individual CPU cycles that might be expended needlessly with a 
>>reflection-based design.  Just add more hardware and the user experience 
>>will be perpetually preserved.  I would argue, however, that the 
>>development community will be able to make better use of the product if 
>>the rate at which additional hardware purchases becomes necessary 
>>decreases.  The philosophy, IMHO, should be to solve the problems at 
>>hand with straight-forward OO solutions, and not to focus so much on 
>>being generic and supporting n * infinity solutions up-front.  Using 
>>things like the Policy/Strategy pattern at well-selected locations will 
>>afford the opportunity for pluggability without compromising 
>>maintainability and performance.
>>
>>Here are some dramatic results:
>>
>>*Direct:*
>>
>>public void init()
>>{
>>   customer = new Customer();
>>}
>>
>>public void run()
>>{
>>   customer.work();
>>}
>>
>>
>>*Interface (Polymorphism):*
>>
>>public void init()
>>{
>>  customer = new Customer();
>>}
>>public void run()
>>{
>>  Person person = (Person) customer;
>>  person.work();
>>}
>>
>>
>>*Reflection:*
>>
>>public void init()
>>{
>>  customer = new Customer();
>>  try 
>>  {
>>      method = customer.getClass().getMethod("work", new Class[0]);
>>  } 
>>  catch (Exception e) 
>>  {
>>  }
>>  
>>   params = new Object[0];
>>}
>>
>>public void run() 
>>{
>>  try 
>>  {
>>    method.invoke(customer, params);
>>  } 
>>  catch (Exception e) 
>>  {
>>  }
>>}
>>
>>
>>With 1000000 of the above code, here were the results:
>>
>>JDK DirectTest InterfaceTest ReflectionTest
>>*Sun 1.4* 52 ms 54 ms 543 ms
>>*Sun 1.4 -server* 26 ms 56 ms 279 ms
>>*Sun 1.3* 124 ms 128 ms 2168 ms
>>*Sun 1.3 -server* 41 ms 58 ms 2012 ms
>>*IBM 1.3* 75 ms 78 ms 2134 ms
>>
>>
>>Reflection will significantly effect the performance of the system and 
>>should be avoided for any runtime operations.  Where it should and could 
>>definitely be applied is with the dynamic generation and compilation of 
>>code, or generation of metadata.  Otherwise, even at the recommendation 
>>of Sun, it should be avoided for runtime operations.
>>
>>Best,
>>
>>John C. Dale
>>
>>Leo Simons wrote:
>>
>>    
>>
>>>Jason Dillon wrote:
>>>
>>>      
>>>
>>>>PS. Can someone write up something about the current state of the 
>>>>major component containers out there with a feature blurb... no soap 
>>>>boxes, just the facts jack.
>>>>        
>>>>
>>>What, no soap boxes? How on earth can anyone comply with that? ;) No 
>>>wait,
>>>you weren't asking me anyway, were you. Ah, e-mail already typed. Bummer.
>>>
>>>= My Opinion =
>>>
>>>You should *not* be evaluating component containers. You should save 
>>>this discussion
>>>for a later date and just code your way to 1.0. The basic design idea 
>>>overview
>>>below should show that most of the architectural concepts behind all 
>>>these containers are
>>>very similar. I've been experimenting (no, I will not plug it, you 
>>>will just get confused) with
>>>some reflection that will allow any component written for any of the 
>>>below to run in any
>>>of the other containers, and that is feasible, straightforward and 
>>>performant.
>>>
>>>So write your components to plug in whatever you have, do a nice IoC, 
>>>SoC, SAI, AOP
>>>setup, and you will be able to defer refactoring around an external 
>>>container until much later.
>>>
>>>But that's my opinion, and I have now said it three times, and your a 
>>>responsible adult
>>>(yep, its a guess, you could also be 11 years old :D). Switching 
>>>soapbox mode off.
>>>
>>>
>>>= Disclaimer =
>>>
>>>Comparing component containers is comparing apples with pears. Avalon 
>>>is by far the
>>>biggest 'generic' project at the moment, for example, but recent 
>>>developments utilize AOP
>>>and interceptor architecture to support a much 'lighter' 
>>>container-component api and
>>>contract. Indeed, picocontainer was started by an avalon elder from 
>>>the firm belief that
>>>things should be simpler and smaller. So to actually evaluate all this 
>>>stuff, you really should
>>>spend a day or so delving into the websites and the code of all these 
>>>projects, and backing
>>>tech like nanning (nanning.codehaus.org) and aspectj 
>>>(www.aspectj.org). I would start
>>>by looking at pico/nano and xwork, then take a look at the tutorials 
>>>for avalon-merlin.
>>>The other projects have a smaller community atm, and I tend to value 
>>>community size
>>>and vibe.
>>>
>>>Furthermore, I have strong opinions about stuff, and allegations to 
>>>various projects, hence
>>>this is not an objective overview, even though I tried to make it 
>>>somewhat objective.
>>>
>>>
>>>= Features/ design idea shorthands =
>>>
>>>IoC = Inversion of Control, the idea that an application is controlled 
>>>from the top down
>>>SoC = Seperation of Coccerns, the idea that a class (aspect) should do 
>>>one job and do it well
>>>SAI = Seperation of API from Implementation, the idea that you define 
>>>and code to work
>>>   interfaces
>>>AOP = Aspect Oriented Programming, mostly lightweight nowadays where 
>>>you add a chain
>>>   of interceptors around a method call that can handle orthogonal 
>>>concerns
>>>DecP = Declarative Programming, where you use a declarative-style 
>>>language (usually xml) to
>>>   determine things like component wiring (ie your average tomcat 
>>>config file, generalized)
>>>EBP = Event Based Programming, basically making the inter-object 
>>>method call asynchronous
>>>   and encapsulating such a call into some kind of event object that 
>>>can be queued, modfied,
>>>   etc
>>>
>>>
>>>= No particular order, incomplete list =
>>>
>>>http://wiki.opensymphony.com/space/XWork - IoC, SoC, SAI, AOP, DecP, 
>>>EBP. Nearing
>>>1.0 release. Used in webwork2 (a competitor to struts). EBP very basic 
>>>only. Lean and mean,
>>>but not mature and some client-server web-layer specific assumptions. 
>>>Don't like the XXXAware
>>>interfaces. Very vibrant and active community and many famous peeps 
>>>with J2EE experience
>>>around at opensymphony.
>>>
>>>http://www.picocontainer.org/ and http://www.nanocontainer.org/ -
>>>IoC, SoC, SAI, AOP, DecP. 1.0 beta releases. Lean and mean and very 
>>>extensible and
>>>embeddable, developed by smart XP peeps, some stuff already in use in 
>>>some apps, but
>>>otherwise pretty much alpha. I love picocontainer and the way they're 
>>>doing the project.
>>>The dev community is intentionally kept small atm, but many peeps are 
>>>watching this one.
>>>
>>>http://plexus.codehaus.org/ - IoC, SoC, SAI, DecP. Container supporting
>>>avalon-framework components. Used to be 
>>>yet-another-novel-avalon-container, but I
>>>think they're growing to be container-component-contract-agnostic. 
>>>Corporate backed
>>>development. Smart guys, not so much focussed on releases as on 
>>>getting all the
>>>functionality they need (which is a lot) in place. Very much a 
>>>pragmatic project.
>>>
>>>http://www.jcontainer.org/ - Not yet public container development
>>>(dubbed 'loom' IIRC) by a smart ex-avaloner 'n others. Haven't seen 
>>>any code yet
>>>but my guess is it'll be good. The website says "move along" so you 
>>>prolly should.
>>>
>>>http://www.springframework.org/ - haven't looked at in too much depth. 
>>>Seems similar to
>>>nanocontainer and xwork. Think it has one active developer and a beta 
>>>release. Some
>>>smart points made, but too much xml for my taste. Hoping to see some 
>>>of this rolled into
>>>Xwork and/or pico.
>>>
>>>http://avalon.apache.org/ - IoC, SoC, SAI, DecP, EBP (EBP for fortress 
>>>only). By far
>>>the oldest 'generic container' project. Big committer base, mature 
>>>codebase, mature
>>>ASF project (which can be a good thing and a bad thing ;) rather 
>>>extensive
>>>'avalon-framework' (comparatively heavy compared to more recent 
>>>developments)
>>>that defines the contracts between a component and a container. Has 3
>>>container projects to consider: avalon-phoenix, a mature microkernel 
>>>design,
>>>avalon-fortress, similar in weight and featureset to something like 
>>>nanocontainer with a
>>>1.0 release (successor to avalon-ecm, the container used in (among 
>>>other projects)
>>>apache-cocoon), and avalon-merlin, a more recent development which we 
>>>_seem_
>>>to be converging on as the successor to all other previously produced 
>>>containers. Merlin
>>>is further described in the email by Stephen Mcconnell. Arguably the 
>>>biggest,
>>>most extensive and most dynamic IoC container implementation around 
>>>(and hence
>>>also the most complex). Re: my earlier blurb on 'geronimo and avalon' 
>>>for more
>>>yadayada.
>>>
>>>http://jakarta.apache.org/commons/sandbox/hivemind - haven't looked at 
>>>in much detail, but seems
>>>very similar in scope and setup to avalon at first glance. Framework 
>>>being refactored out
>>>of hibernate, one developer, still in alpha with no releases I think. 
>>>No offense to Howard
>>>intended, but I think he's cut himself a rather big piece of the 
>>>puzzle to recode from scratch
>>>at once. But I am an uninformed whiner, so I'm not going to comment 
>>>further in the hope that
>>>Howard will just eventually see the light and direct his energy 
>>>towards collaboration with the
>>>avalon peeps :P
>>>
>>>
>>>I am spending too much time on writing messages to this mailing list 
>>>(it is nearly 3am over here).
>>>I promise this is the last message from me for two weeks :D
>>>
>>>g'night,
>>>
>>>- Leo
>>>
>>>
>>>
>>>
>>>
>>>      
>>>
>>    
>>
>
>
>
>  
>

Re: Reflection Bad, OO and direct Method invocation Good...

[Aaron Mulder <am...@alumni.princeton.edu>]

	First of all, can we agree that microbenchmarks are dangerous?

	But all that aside, try 1 million HTTP requests, or 1 million
iterations of a JDBC query, and then provide a ratio between JDBC/HTTP
time and reflection time.  If you can perform a million requests of either
type in 30 seconds I'd be shocked, and that's two orders of magnitude.

	IMHO, reflection is something that can be optimized away later,
once it becomes the bottleneck on performance.  I don't think we need to 
avoid it from the outset, because I don't think it will be the bottleneck 
at the outset.

Aaron

On Sat, 9 Aug 2003, John C. Dale wrote:
> I'm concerned about your mention of reflection.  I really like 
> reflection, and think it has many useful applications in the application 
> development space, but should be kept out of any runtime application 
> that has stringent scalability and performance requirements.  Although 
> reflection allows an incredibly generic way to solve many difficult 
> problems, and really opens the door to completely grandios perfectly 
> idealistic genericititousness ;)  , a straight-forward OO approach to 
> solving the problems would 1) be faster and 2) be easier to read and 
> maintain.  I've seen reflection based approaches work, and I've seen 
> them bomb.
> 
> One might argue that in a container based system that will eventually 
> support clustering and scalability doesn't have to worry about savoring 
> individual CPU cycles that might be expended needlessly with a 
> reflection-based design.  Just add more hardware and the user experience 
> will be perpetually preserved.  I would argue, however, that the 
> development community will be able to make better use of the product if 
> the rate at which additional hardware purchases becomes necessary 
> decreases.  The philosophy, IMHO, should be to solve the problems at 
> hand with straight-forward OO solutions, and not to focus so much on 
> being generic and supporting n * infinity solutions up-front.  Using 
> things like the Policy/Strategy pattern at well-selected locations will 
> afford the opportunity for pluggability without compromising 
> maintainability and performance.
> 
> Here are some dramatic results:
> 
> *Direct:*
> 
> public void init()
> {
>    customer = new Customer();
> }
> 
> public void run()
> {
>    customer.work();
> }
> 
> 
> *Interface (Polymorphism):*
> 
> public void init()
> {
>   customer = new Customer();
> }
> public void run()
> {
>   Person person = (Person) customer;
>   person.work();
> }
> 
> 
> *Reflection:*
> 
> public void init()
> {
>   customer = new Customer();
>   try 
>   {
>       method = customer.getClass().getMethod("work", new Class[0]);
>   } 
>   catch (Exception e) 
>   {
>   }
>   
>    params = new Object[0];
> }
> 
> public void run() 
> {
>   try 
>   {
>     method.invoke(customer, params);
>   } 
>   catch (Exception e) 
>   {
>   }
> }
> 
> 
> With 1000000 of the above code, here were the results:
> 
> JDK DirectTest InterfaceTest ReflectionTest
> *Sun 1.4* 52 ms 54 ms 543 ms
> *Sun 1.4 -server* 26 ms 56 ms 279 ms
> *Sun 1.3* 124 ms 128 ms 2168 ms
> *Sun 1.3 -server* 41 ms 58 ms 2012 ms
> *IBM 1.3* 75 ms 78 ms 2134 ms
> 
> 
> Reflection will significantly effect the performance of the system and 
> should be avoided for any runtime operations.  Where it should and could 
> definitely be applied is with the dynamic generation and compilation of 
> code, or generation of metadata.  Otherwise, even at the recommendation 
> of Sun, it should be avoided for runtime operations.
> 
> Best,
> 
> John C. Dale
> 
> Leo Simons wrote:
> 
> > Jason Dillon wrote:
> >
> >> PS. Can someone write up something about the current state of the 
> >> major component containers out there with a feature blurb... no soap 
> >> boxes, just the facts jack.
> >
> >
> > What, no soap boxes? How on earth can anyone comply with that? ;) No 
> > wait,
> > you weren't asking me anyway, were you. Ah, e-mail already typed. Bummer.
> >
> > = My Opinion =
> >
> > You should *not* be evaluating component containers. You should save 
> > this discussion
> > for a later date and just code your way to 1.0. The basic design idea 
> > overview
> > below should show that most of the architectural concepts behind all 
> > these containers are
> > very similar. I've been experimenting (no, I will not plug it, you 
> > will just get confused) with
> > some reflection that will allow any component written for any of the 
> > below to run in any
> > of the other containers, and that is feasible, straightforward and 
> > performant.
> >
> > So write your components to plug in whatever you have, do a nice IoC, 
> > SoC, SAI, AOP
> > setup, and you will be able to defer refactoring around an external 
> > container until much later.
> >
> > But that's my opinion, and I have now said it three times, and your a 
> > responsible adult
> > (yep, its a guess, you could also be 11 years old :D). Switching 
> > soapbox mode off.
> >
> >
> > = Disclaimer =
> >
> > Comparing component containers is comparing apples with pears. Avalon 
> > is by far the
> > biggest 'generic' project at the moment, for example, but recent 
> > developments utilize AOP
> > and interceptor architecture to support a much 'lighter' 
> > container-component api and
> > contract. Indeed, picocontainer was started by an avalon elder from 
> > the firm belief that
> > things should be simpler and smaller. So to actually evaluate all this 
> > stuff, you really should
> > spend a day or so delving into the websites and the code of all these 
> > projects, and backing
> > tech like nanning (nanning.codehaus.org) and aspectj 
> > (www.aspectj.org). I would start
> > by looking at pico/nano and xwork, then take a look at the tutorials 
> > for avalon-merlin.
> > The other projects have a smaller community atm, and I tend to value 
> > community size
> > and vibe.
> >
> > Furthermore, I have strong opinions about stuff, and allegations to 
> > various projects, hence
> > this is not an objective overview, even though I tried to make it 
> > somewhat objective.
> >
> >
> > = Features/ design idea shorthands =
> >
> > IoC = Inversion of Control, the idea that an application is controlled 
> > from the top down
> > SoC = Seperation of Coccerns, the idea that a class (aspect) should do 
> > one job and do it well
> > SAI = Seperation of API from Implementation, the idea that you define 
> > and code to work
> >    interfaces
> > AOP = Aspect Oriented Programming, mostly lightweight nowadays where 
> > you add a chain
> >    of interceptors around a method call that can handle orthogonal 
> > concerns
> > DecP = Declarative Programming, where you use a declarative-style 
> > language (usually xml) to
> >    determine things like component wiring (ie your average tomcat 
> > config file, generalized)
> > EBP = Event Based Programming, basically making the inter-object 
> > method call asynchronous
> >    and encapsulating such a call into some kind of event object that 
> > can be queued, modfied,
> >    etc
> >
> >
> > = No particular order, incomplete list =
> >
> > http://wiki.opensymphony.com/space/XWork - IoC, SoC, SAI, AOP, DecP, 
> > EBP. Nearing
> > 1.0 release. Used in webwork2 (a competitor to struts). EBP very basic 
> > only. Lean and mean,
> > but not mature and some client-server web-layer specific assumptions. 
> > Don't like the XXXAware
> > interfaces. Very vibrant and active community and many famous peeps 
> > with J2EE experience
> > around at opensymphony.
> >
> > http://www.picocontainer.org/ and http://www.nanocontainer.org/ -
> > IoC, SoC, SAI, AOP, DecP. 1.0 beta releases. Lean and mean and very 
> > extensible and
> > embeddable, developed by smart XP peeps, some stuff already in use in 
> > some apps, but
> > otherwise pretty much alpha. I love picocontainer and the way they're 
> > doing the project.
> > The dev community is intentionally kept small atm, but many peeps are 
> > watching this one.
> >
> > http://plexus.codehaus.org/ - IoC, SoC, SAI, DecP. Container supporting
> > avalon-framework components. Used to be 
> > yet-another-novel-avalon-container, but I
> > think they're growing to be container-component-contract-agnostic. 
> > Corporate backed
> > development. Smart guys, not so much focussed on releases as on 
> > getting all the
> > functionality they need (which is a lot) in place. Very much a 
> > pragmatic project.
> >
> > http://www.jcontainer.org/ - Not yet public container development
> > (dubbed 'loom' IIRC) by a smart ex-avaloner 'n others. Haven't seen 
> > any code yet
> > but my guess is it'll be good. The website says "move along" so you 
> > prolly should.
> >
> > http://www.springframework.org/ - haven't looked at in too much depth. 
> > Seems similar to
> > nanocontainer and xwork. Think it has one active developer and a beta 
> > release. Some
> > smart points made, but too much xml for my taste. Hoping to see some 
> > of this rolled into
> > Xwork and/or pico.
> >
> > http://avalon.apache.org/ - IoC, SoC, SAI, DecP, EBP (EBP for fortress 
> > only). By far
> > the oldest 'generic container' project. Big committer base, mature 
> > codebase, mature
> > ASF project (which can be a good thing and a bad thing ;) rather 
> > extensive
> > 'avalon-framework' (comparatively heavy compared to more recent 
> > developments)
> > that defines the contracts between a component and a container. Has 3
> > container projects to consider: avalon-phoenix, a mature microkernel 
> > design,
> > avalon-fortress, similar in weight and featureset to something like 
> > nanocontainer with a
> > 1.0 release (successor to avalon-ecm, the container used in (among 
> > other projects)
> > apache-cocoon), and avalon-merlin, a more recent development which we 
> > _seem_
> > to be converging on as the successor to all other previously produced 
> > containers. Merlin
> > is further described in the email by Stephen Mcconnell. Arguably the 
> > biggest,
> > most extensive and most dynamic IoC container implementation around 
> > (and hence
> > also the most complex). Re: my earlier blurb on 'geronimo and avalon' 
> > for more
> > yadayada.
> >
> > http://jakarta.apache.org/commons/sandbox/hivemind - haven't looked at 
> > in much detail, but seems
> > very similar in scope and setup to avalon at first glance. Framework 
> > being refactored out
> > of hibernate, one developer, still in alpha with no releases I think. 
> > No offense to Howard
> > intended, but I think he's cut himself a rather big piece of the 
> > puzzle to recode from scratch
> > at once. But I am an uninformed whiner, so I'm not going to comment 
> > further in the hope that
> > Howard will just eventually see the light and direct his energy 
> > towards collaboration with the
> > avalon peeps :P
> >
> >
> > I am spending too much time on writing messages to this mailing list 
> > (it is nearly 3am over here).
> > I promise this is the last message from me for two weeks :D
> >
> > g'night,
> >
> > - Leo
> >
> >
> >
> >
> >
> 
> 

Reflection Bad, OO and direct Method invocation Good...

["John C. Dale" <jc...@downinthedesert.com>]

I'm concerned about your mention of reflection.  I really like 
reflection, and think it has many useful applications in the application 
development space, but should be kept out of any runtime application 
that has stringent scalability and performance requirements.  Although 
reflection allows an incredibly generic way to solve many difficult 
problems, and really opens the door to completely grandios perfectly 
idealistic genericititousness ;)  , a straight-forward OO approach to 
solving the problems would 1) be faster and 2) be easier to read and 
maintain.  I've seen reflection based approaches work, and I've seen 
them bomb.

One might argue that in a container based system that will eventually 
support clustering and scalability doesn't have to worry about savoring 
individual CPU cycles that might be expended needlessly with a 
reflection-based design.  Just add more hardware and the user experience 
will be perpetually preserved.  I would argue, however, that the 
development community will be able to make better use of the product if 
the rate at which additional hardware purchases becomes necessary 
decreases.  The philosophy, IMHO, should be to solve the problems at 
hand with straight-forward OO solutions, and not to focus so much on 
being generic and supporting n * infinity solutions up-front.  Using 
things like the Policy/Strategy pattern at well-selected locations will 
afford the opportunity for pluggability without compromising 
maintainability and performance.

Here are some dramatic results:

*Direct:*

public void init()
{
   customer = new Customer();
}

public void run()
{
   customer.work();
}


*Interface (Polymorphism):*

public void init()
{
  customer = new Customer();
}
public void run()
{
  Person person = (Person) customer;
  person.work();
}


*Reflection:*

public void init()
{
  customer = new Customer();
  try 
  {
      method = customer.getClass().getMethod("work", new Class[0]);
  } 
  catch (Exception e) 
  {
  }
  
   params = new Object[0];
}

public void run() 
{
  try 
  {
    method.invoke(customer, params);
  } 
  catch (Exception e) 
  {
  }
}


With 1000000 of the above code, here were the results:

JDK DirectTest InterfaceTest ReflectionTest
*Sun 1.4* 52 ms 54 ms 543 ms
*Sun 1.4 -server* 26 ms 56 ms 279 ms
*Sun 1.3* 124 ms 128 ms 2168 ms
*Sun 1.3 -server* 41 ms 58 ms 2012 ms
*IBM 1.3* 75 ms 78 ms 2134 ms


Reflection will significantly effect the performance of the system and 
should be avoided for any runtime operations.  Where it should and could 
definitely be applied is with the dynamic generation and compilation of 
code, or generation of metadata.  Otherwise, even at the recommendation 
of Sun, it should be avoided for runtime operations.

Best,

John C. Dale

Leo Simons wrote:

> Jason Dillon wrote:
>
>> PS. Can someone write up something about the current state of the 
>> major component containers out there with a feature blurb... no soap 
>> boxes, just the facts jack.
>
>
> What, no soap boxes? How on earth can anyone comply with that? ;) No 
> wait,
> you weren't asking me anyway, were you. Ah, e-mail already typed. Bummer.
>
> = My Opinion =
>
> You should *not* be evaluating component containers. You should save 
> this discussion
> for a later date and just code your way to 1.0. The basic design idea 
> overview
> below should show that most of the architectural concepts behind all 
> these containers are
> very similar. I've been experimenting (no, I will not plug it, you 
> will just get confused) with
> some reflection that will allow any component written for any of the 
> below to run in any
> of the other containers, and that is feasible, straightforward and 
> performant.
>
> So write your components to plug in whatever you have, do a nice IoC, 
> SoC, SAI, AOP
> setup, and you will be able to defer refactoring around an external 
> container until much later.
>
> But that's my opinion, and I have now said it three times, and your a 
> responsible adult
> (yep, its a guess, you could also be 11 years old :D). Switching 
> soapbox mode off.
>
>
> = Disclaimer =
>
> Comparing component containers is comparing apples with pears. Avalon 
> is by far the
> biggest 'generic' project at the moment, for example, but recent 
> developments utilize AOP
> and interceptor architecture to support a much 'lighter' 
> container-component api and
> contract. Indeed, picocontainer was started by an avalon elder from 
> the firm belief that
> things should be simpler and smaller. So to actually evaluate all this 
> stuff, you really should
> spend a day or so delving into the websites and the code of all these 
> projects, and backing
> tech like nanning (nanning.codehaus.org) and aspectj 
> (www.aspectj.org). I would start
> by looking at pico/nano and xwork, then take a look at the tutorials 
> for avalon-merlin.
> The other projects have a smaller community atm, and I tend to value 
> community size
> and vibe.
>
> Furthermore, I have strong opinions about stuff, and allegations to 
> various projects, hence
> this is not an objective overview, even though I tried to make it 
> somewhat objective.
>
>
> = Features/ design idea shorthands =
>
> IoC = Inversion of Control, the idea that an application is controlled 
> from the top down
> SoC = Seperation of Coccerns, the idea that a class (aspect) should do 
> one job and do it well
> SAI = Seperation of API from Implementation, the idea that you define 
> and code to work
>    interfaces
> AOP = Aspect Oriented Programming, mostly lightweight nowadays where 
> you add a chain
>    of interceptors around a method call that can handle orthogonal 
> concerns
> DecP = Declarative Programming, where you use a declarative-style 
> language (usually xml) to
>    determine things like component wiring (ie your average tomcat 
> config file, generalized)
> EBP = Event Based Programming, basically making the inter-object 
> method call asynchronous
>    and encapsulating such a call into some kind of event object that 
> can be queued, modfied,
>    etc
>
>
> = No particular order, incomplete list =
>
> http://wiki.opensymphony.com/space/XWork - IoC, SoC, SAI, AOP, DecP, 
> EBP. Nearing
> 1.0 release. Used in webwork2 (a competitor to struts). EBP very basic 
> only. Lean and mean,
> but not mature and some client-server web-layer specific assumptions. 
> Don't like the XXXAware
> interfaces. Very vibrant and active community and many famous peeps 
> with J2EE experience
> around at opensymphony.
>
> http://www.picocontainer.org/ and http://www.nanocontainer.org/ -
> IoC, SoC, SAI, AOP, DecP. 1.0 beta releases. Lean and mean and very 
> extensible and
> embeddable, developed by smart XP peeps, some stuff already in use in 
> some apps, but
> otherwise pretty much alpha. I love picocontainer and the way they're 
> doing the project.
> The dev community is intentionally kept small atm, but many peeps are 
> watching this one.
>
> http://plexus.codehaus.org/ - IoC, SoC, SAI, DecP. Container supporting
> avalon-framework components. Used to be 
> yet-another-novel-avalon-container, but I
> think they're growing to be container-component-contract-agnostic. 
> Corporate backed
> development. Smart guys, not so much focussed on releases as on 
> getting all the
> functionality they need (which is a lot) in place. Very much a 
> pragmatic project.
>
> http://www.jcontainer.org/ - Not yet public container development
> (dubbed 'loom' IIRC) by a smart ex-avaloner 'n others. Haven't seen 
> any code yet
> but my guess is it'll be good. The website says "move along" so you 
> prolly should.
>
> http://www.springframework.org/ - haven't looked at in too much depth. 
> Seems similar to
> nanocontainer and xwork. Think it has one active developer and a beta 
> release. Some
> smart points made, but too much xml for my taste. Hoping to see some 
> of this rolled into
> Xwork and/or pico.
>
> http://avalon.apache.org/ - IoC, SoC, SAI, DecP, EBP (EBP for fortress 
> only). By far
> the oldest 'generic container' project. Big committer base, mature 
> codebase, mature
> ASF project (which can be a good thing and a bad thing ;) rather 
> extensive
> 'avalon-framework' (comparatively heavy compared to more recent 
> developments)
> that defines the contracts between a component and a container. Has 3
> container projects to consider: avalon-phoenix, a mature microkernel 
> design,
> avalon-fortress, similar in weight and featureset to something like 
> nanocontainer with a
> 1.0 release (successor to avalon-ecm, the container used in (among 
> other projects)
> apache-cocoon), and avalon-merlin, a more recent development which we 
> _seem_
> to be converging on as the successor to all other previously produced 
> containers. Merlin
> is further described in the email by Stephen Mcconnell. Arguably the 
> biggest,
> most extensive and most dynamic IoC container implementation around 
> (and hence
> also the most complex). Re: my earlier blurb on 'geronimo and avalon' 
> for more
> yadayada.
>
> http://jakarta.apache.org/commons/sandbox/hivemind - haven't looked at 
> in much detail, but seems
> very similar in scope and setup to avalon at first glance. Framework 
> being refactored out
> of hibernate, one developer, still in alpha with no releases I think. 
> No offense to Howard
> intended, but I think he's cut himself a rather big piece of the 
> puzzle to recode from scratch
> at once. But I am an uninformed whiner, so I'm not going to comment 
> further in the hope that
> Howard will just eventually see the light and direct his energy 
> towards collaboration with the
> avalon peeps :P
>
>
> I am spending too much time on writing messages to this mailing list 
> (it is nearly 3am over here).
> I promise this is the last message from me for two weeks :D
>
> g'night,
>
> - Leo
>
>
>
>
>

Container overview (was: Re: JMX as a kernel)

[Leo Simons <le...@apache.org>]

Jason Dillon wrote:

> PS. Can someone write up something about the current state of the 
> major component containers out there with a feature blurb... no soap 
> boxes, just the facts jack.

What, no soap boxes? How on earth can anyone comply with that? ;) No wait,
you weren't asking me anyway, were you. Ah, e-mail already typed. Bummer.

= My Opinion =

You should *not* be evaluating component containers. You should save 
this discussion
for a later date and just code your way to 1.0. The basic design idea 
overview
below should show that most of the architectural concepts behind all 
these containers are
very similar. I've been experimenting (no, I will not plug it, you will 
just get confused) with
some reflection that will allow any component written for any of the 
below to run in any
of the other containers, and that is feasible, straightforward and 
performant.

So write your components to plug in whatever you have, do a nice IoC, 
SoC, SAI, AOP
setup, and you will be able to defer refactoring around an external 
container until much later.

But that's my opinion, and I have now said it three times, and your a 
responsible adult
(yep, its a guess, you could also be 11 years old :D). Switching soapbox 
mode off.


= Disclaimer =

Comparing component containers is comparing apples with pears. Avalon is 
by far the
biggest 'generic' project at the moment, for example, but recent 
developments utilize AOP
and interceptor architecture to support a much 'lighter' 
container-component api and
contract. Indeed, picocontainer was started by an avalon elder from the 
firm belief that
things should be simpler and smaller. So to actually evaluate all this 
stuff, you really should
spend a day or so delving into the websites and the code of all these 
projects, and backing
tech like nanning (nanning.codehaus.org) and aspectj (www.aspectj.org). 
I would start
by looking at pico/nano and xwork, then take a look at the tutorials for 
avalon-merlin.
The other projects have a smaller community atm, and I tend to value 
community size
and vibe.

Furthermore, I have strong opinions about stuff, and allegations to 
various projects, hence
this is not an objective overview, even though I tried to make it 
somewhat objective.


= Features/ design idea shorthands =

IoC = Inversion of Control, the idea that an application is controlled 
from the top down
SoC = Seperation of Coccerns, the idea that a class (aspect) should do 
one job and do it well
SAI = Seperation of API from Implementation, the idea that you define 
and code to work
    interfaces
AOP = Aspect Oriented Programming, mostly lightweight nowadays where you 
add a chain
    of interceptors around a method call that can handle orthogonal concerns
DecP = Declarative Programming, where you use a declarative-style 
language (usually xml) to
    determine things like component wiring (ie your average tomcat 
config file, generalized)
EBP = Event Based Programming, basically making the inter-object method 
call asynchronous
    and encapsulating such a call into some kind of event object that 
can be queued, modfied,
    etc


= No particular order, incomplete list =

http://wiki.opensymphony.com/space/XWork - IoC, SoC, SAI, AOP, DecP, 
EBP. Nearing
1.0 release. Used in webwork2 (a competitor to struts). EBP very basic 
only. Lean and mean,
but not mature and some client-server web-layer specific assumptions. 
Don't like the XXXAware
interfaces. Very vibrant and active community and many famous peeps with 
J2EE experience
around at opensymphony.

http://www.picocontainer.org/ and http://www.nanocontainer.org/ -
IoC, SoC, SAI, AOP, DecP. 1.0 beta releases. Lean and mean and very 
extensible and
embeddable, developed by smart XP peeps, some stuff already in use in 
some apps, but
otherwise pretty much alpha. I love picocontainer and the way they're 
doing the project.
The dev community is intentionally kept small atm, but many peeps are 
watching this one.

http://plexus.codehaus.org/ - IoC, SoC, SAI, DecP. Container supporting
avalon-framework components. Used to be 
yet-another-novel-avalon-container, but I
think they're growing to be container-component-contract-agnostic. 
Corporate backed
development. Smart guys, not so much focussed on releases as on getting 
all the
functionality they need (which is a lot) in place. Very much a pragmatic 
project.

http://www.jcontainer.org/ - Not yet public container development
(dubbed 'loom' IIRC) by a smart ex-avaloner 'n others. Haven't seen any 
code yet
but my guess is it'll be good. The website says "move along" so you 
prolly should.

http://www.springframework.org/ - haven't looked at in too much depth. 
Seems similar to
nanocontainer and xwork. Think it has one active developer and a beta 
release. Some
smart points made, but too much xml for my taste. Hoping to see some of 
this rolled into
Xwork and/or pico.

http://avalon.apache.org/ - IoC, SoC, SAI, DecP, EBP (EBP for fortress 
only). By far
the oldest 'generic container' project. Big committer base, mature 
codebase, mature
ASF project (which can be a good thing and a bad thing ;) rather extensive
'avalon-framework' (comparatively heavy compared to more recent 
developments)
that defines the contracts between a component and a container. Has 3
container projects to consider: avalon-phoenix, a mature microkernel design,
avalon-fortress, similar in weight and featureset to something like 
nanocontainer with a
1.0 release (successor to avalon-ecm, the container used in (among other 
projects)
apache-cocoon), and avalon-merlin, a more recent development which we _seem_
to be converging on as the successor to all other previously produced 
containers. Merlin
is further described in the email by Stephen Mcconnell. Arguably the 
biggest,
most extensive and most dynamic IoC container implementation around (and 
hence
also the most complex). Re: my earlier blurb on 'geronimo and avalon' 
for more
yadayada.

http://jakarta.apache.org/commons/sandbox/hivemind - haven't looked at 
in much detail, but seems
very similar in scope and setup to avalon at first glance. Framework 
being refactored out
of hibernate, one developer, still in alpha with no releases I think. No 
offense to Howard
intended, but I think he's cut himself a rather big piece of the puzzle 
to recode from scratch
at once. But I am an uninformed whiner, so I'm not going to comment 
further in the hope that
Howard will just eventually see the light and direct his energy towards 
collaboration with the
avalon peeps :P


I am spending too much time on writing messages to this mailing list (it 
is nearly 3am over here).
I promise this is the last message from me for two weeks :D

g'night,

- Leo

Avalon Merlin - model-driven containment

[Stephen McConnell <mc...@apache.org>]

Jason Dillon wrote:

> PS. Can someone write up something about the current state of the 
> major component containers out there with a feature blurb... no soap 
> boxes, just the facts jack. 


Based on current directions (and subject to the usual votes within the 
comming days) the Avalon community is about to release a container 
framework – codenamed Merlin. The framework deals with a set of critical 
container/component concerns that provide support for general component 
models (not just classic Avalon).

In particular, the Merlin framework includes:

* component meta info - declaration of a component criteria including 
configuration and parameterization requirements, contextualization 
requirements (including contextualization strategy, casting constraints, 
context entry requirements, optional and volatile entry criteria, 
etc.)., service dependencies, general component type attributes, logging 
criteria, etc.

* component meta data - definition of the meta model for declaration of 
component deployment directives that instruct a container with respect 
to deployment requirements - things like activation policies, 
configuration and contextualization information to be applied to 
components, lifecycle and lifestyle management and so on.

Combining the above two models together in a runtime environment enables 
the establishment of a model driven containment solution (the 
composition framework). Meta info and meta data can be supplied in 
either XML or serializable form, enabling remote model execution and 
management. Model execution is realized though the Merlin 'activation' 
platform which provides the infrastructure for nested component 
hierarchies, composite components (container that contain components the 
define an implementation strategy that allows a container to publish 
itself as a component), and the complete framework for configuration and 
context management based on a model driven approach. The Avalon work has 
already started on a JMX solution and with the introduction of the 
activation API, the Merlin platform will be able deliver a very 
significant level of management automation exposed via local or remotely 
accessible JMX management points that reach into fine-grain controls 
within the containment model.

Aside from all of the above - the Merlin platform provides a neutral 
component type discovery system and an automated component assembly 
framework. This ensures that the overall component deployment process 
can be simplified dramatically, in some cases down to nothing more than 
a couple of container directives.

The first public release of the Merlin platform should be coming out of 
Avalon within a matter of days. From there on the Avalon community will 
be leveraging the Merlin platform as the generic framework on which a 
new model-driven solutions will be delivered. I'll try to make sure we 
get release info to you as soon as it becomes available.

Cheers, Steve.


-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

RE: JMX as a kernel (was: Re: geronimo and avalon?)

["Noel J. Bergman" <no...@devtech.com>]

> Can someone write up something about the current state of the major
> component containers out there with a feature blurb... no soap boxes,
> just the facts jack.

I've sent an e-mail to the Avalon developers asking them to explain how the
new container supports your desires.

	--- Noel

Re: JMX as a kernel (was: Re: geronimo and avalon?)

[Jason Dillon <ja...@coredevelopers.net>]

I think that it would be best for Geronimo not to use JMX as the 
component bus, but use something else and then adapt JMX to it, as we 
must have JMX support.

That said there are so many different component containers out there, 
it is hard to find the one which suites our needs and/or requires the 
least amount of hacking to get it to function.

I have had a look over several containers, HiveMind being one of them, 
though I have not really spent much time looking at the details.

We need something which is small, fast, can plug in any sort of 
component, which will support linking component instances to avoid any 
hard coupling.  It needs to be able to support elba/jboss style 
deployment and class loading semantics.  It needs to be able to be 
adapted to JMX (possibly other protocols like SNMP too).  It would be 
beneficial if it could provide dependency management as well as 
component state management, or at the minimum be easy to provide layers 
on top which can provide this.  It must not impose many restrictions on 
how it can be used, nor should it impose any other application 
functionality short of managing components.

This is just a rough blurb about the requirements for the geronimo 
component container, I will try to write up something more formal and 
drop it into the wiki in the next day or so... along with the system 
loading, configuration and deployment sub-systems.

I believe that the initial geronimo/elba hybrid will probably use JMX, 
as it already works, but we will want to replace this with a more 
robust system as soon as we can sort out how to build it.  Anyways, I 
will put up some wiki docs and then perhaps some of the folks who are 
more knowledgeable about these different containers can comment.  I do 
not want to reinvent the wheel, but if the wheel does not fit the wagon 
then we may just have to make a new one.

--jason

PS. Can someone write up something about the current state of the major 
component containers out there with a feature blurb... no soap boxes, 
just the facts jack.


On Friday, August 8, 2003, at 10:33  PM, Howard M. Lewis Ship wrote:

> I'm going to plug HiveMind again here.
>
> Looking over what JBoss has done with JMX as a Microkernel, I have a 
> couple of key issues.
>
> First off, the code abstraction that requires you to invoke methods on 
> MBeans using an interface
> like reflection.  Yes, there are workarounds to that (such as using 
> dynamic Proxys) but if a Java
> object is invoking a method on another Java object within the same JVM 
> why make it look like some
> low-level RPC call?
>
> Second, configuration of MBeans leaves a bit to be desired.  I suppose 
> it works well for simple
> properties, but once you get to anything complicated, you start seeing 
> more and more ad-hoc
> ugliness.  Among other things, you end up endlessly rehashing the code 
> to translate an MBean name
> into an instance that methods can be invoked on.
>
> Intrinsic to HiveMind are concepts adapted from Eclipse Plugins: 
> extension points and extensions.
> Extension points define a point where modules can plug into other 
> modules; an extension point
> defines a kind of XML schema for contributions.  Extensions are 
> snippets of XML that plug into
> extension points.
>
> The end result is something very flexible, and very supportive of a 
> very complex environment, yet
> very "lean and mean" at the same time.
>
> http://jakarta.apache.org/commons/sandbox/hivemind
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
>
>
>
>> -----Original Message-----
>> From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
>> Sent: Friday, August 08, 2003 8:55 AM
>> To: geronimo-dev@incubator.apache.org
>> Subject: Re: JMX as a kernel (was: Re: geronimo and avalon?)
>>
>>
>>
>> On Friday, Aug 8, 2003, at 13:05 Europe/London, Leo Simons wrote:
>>
>>> Why JMX Is Not A Very Good Kernel
>>> ------------------
>>
>> I'd definitely concur with this. Put it better than I could
>> have done,
>> too :-)
>>
>> Note that just because JMX isn't a kernel, doesn't mean that
>> some parts
>> of it can't be configured with JMX on top. It just means that not
>> everything has to be JMX.
>>
>> Building a tighter smaller kernel gives me a gut feeling that it will
>> run faster, though I've yet to convert that into measurable
>> figures :-)
>> But reducing (unnecessary) layers is bound to speed it up...
>>
>> One fear I have of using JMX as a kernel is that all the intra-kernel
>> messages would be sent using JMX. If JMX isn't used in the
>> kernel, then
>> they can be made more efficient/optimised; but JMX can be put as a
>> layer on top of the features (e.g. EJBs) that need
>> configuring/managing
>> by JMX.
>>
>> Definitely vote +1 for not using JMX 'just because'
>>
>> Alex.
>>
>

RE: JMX as a kernel (was: Re: geronimo and avalon?)

["Howard M. Lewis Ship" <hl...@comcast.net>]

I'm going to plug HiveMind again here.

Looking over what JBoss has done with JMX as a Microkernel, I have a couple of key issues.

First off, the code abstraction that requires you to invoke methods on MBeans using an interface
like reflection.  Yes, there are workarounds to that (such as using dynamic Proxys) but if a Java
object is invoking a method on another Java object within the same JVM why make it look like some
low-level RPC call?

Second, configuration of MBeans leaves a bit to be desired.  I suppose it works well for simple
properties, but once you get to anything complicated, you start seeing more and more ad-hoc
ugliness.  Among other things, you end up endlessly rehashing the code to translate an MBean name
into an instance that methods can be invoked on.

Intrinsic to HiveMind are concepts adapted from Eclipse Plugins: extension points and extensions.
Extension points define a point where modules can plug into other modules; an extension point
defines a kind of XML schema for contributions.  Extensions are snippets of XML that plug into
extension points.

The end result is something very flexible, and very supportive of a very complex environment, yet
very "lean and mean" at the same time.

http://jakarta.apache.org/commons/sandbox/hivemind

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry



> -----Original Message-----
> From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com] 
> Sent: Friday, August 08, 2003 8:55 AM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: JMX as a kernel (was: Re: geronimo and avalon?)
> 
> 
> 
> On Friday, Aug 8, 2003, at 13:05 Europe/London, Leo Simons wrote:
> 
> > Why JMX Is Not A Very Good Kernel
> > ------------------
> 
> I'd definitely concur with this. Put it better than I could 
> have done, 
> too :-)
> 
> Note that just because JMX isn't a kernel, doesn't mean that 
> some parts 
> of it can't be configured with JMX on top. It just means that not 
> everything has to be JMX.
> 
> Building a tighter smaller kernel gives me a gut feeling that it will 
> run faster, though I've yet to convert that into measurable 
> figures :-) 
> But reducing (unnecessary) layers is bound to speed it up...
> 
> One fear I have of using JMX as a kernel is that all the intra-kernel 
> messages would be sent using JMX. If JMX isn't used in the 
> kernel, then 
> they can be made more efficient/optimised; but JMX can be put as a 
> layer on top of the features (e.g. EJBs) that need 
> configuring/managing 
> by JMX.
> 
> Definitely vote +1 for not using JMX 'just because'
> 
> Alex.
> 

Re: JMX as a kernel (was: Re: geronimo and avalon?)

[Alex Blewitt <Al...@ioshq.com>]

On Friday, Aug 8, 2003, at 13:05 Europe/London, Leo Simons wrote:

> Why JMX Is Not A Very Good Kernel
> ------------------

I'd definitely concur with this. Put it better than I could have done, 
too :-)

Note that just because JMX isn't a kernel, doesn't mean that some parts 
of it can't be configured with JMX on top. It just means that not 
everything has to be JMX.

Building a tighter smaller kernel gives me a gut feeling that it will 
run faster, though I've yet to convert that into measurable figures :-) 
But reducing (unnecessary) layers is bound to speed it up...

One fear I have of using JMX as a kernel is that all the intra-kernel 
messages would be sent using JMX. If JMX isn't used in the kernel, then 
they can be made more efficient/optimised; but JMX can be put as a 
layer on top of the features (e.g. EJBs) that need configuring/managing 
by JMX.

Definitely vote +1 for not using JMX 'just because'

Alex.

JMX as a kernel (was: Re: geronimo and avalon?)

[Leo Simons <le...@apache.org>]

Jason Dillon wrote:

>> Yes, I could explain.
>
> Okay, well then explain... the abridged version please :-P

Why JMX Is Not A Very Good Kernel
------------------
top-of-head stuff. Can't find my old notes. IMVHO.

1) bloat. The JMX specification is over two hunderd pages I think. The JMX
API is dozens of classes. Too big. NanoKernel is better than MicroKernel.
MicroKernel better than BigKernel.

2) no isolation. Services running in a kernel should be very much seperated
from each other. JMX has domains, but those are just a namespacing
convenience last time I checked.

3) bad security. 2 leads to holes. You don't normally want to run untrusted
code directly inside the JBoss kernel. You can run untrusted code inside
a servlet or an EJB, but not inside the core.

4) big ugly wrappers. DynamicMBean and similar require client code to do
all sorts of introspection, and often require beans to declare all sorts of
information (through the XXXInfo stuff).

5) lack of transparency. Beans running inside a JMX envoriment usually need
some sort of knowledge that they are in that environment.

6) bad seperation of concerns. JMX acts as a component registry, as a
reflection tool, as a management tool, as an event/messaging mechanism, and
each of those is intertwined with the other.

7-25) I am sure I had 25 distinct similar complaints at one point. I 
can't find
the list.

Now, each of those issues can definately be addressed, and the success
JMX is having in precisely this role shows that they can be addressed
pretty well, and with JMX 1.2 and 1.3. things have improved a lot. But by
inverting the JMX setup (control over the system rests with the kernel,
not the other way around) the code becomes leaner, meaner, cleaner, simpler
and more secure. Moreover, "non-core" concerns (to a bean) such as
management and messaging can become fully transparent. And since JMX
was designed to be an extension, it is still easy to extend the lean machine
you've just coded to fully import/export everything it cares about over
JMX.

I guess that's enough talk for an abriged version :D

cheers,

- Leo

Re: geronimo and avalon?

[Jason Dillon <ja...@coredevelopers.net>]

> Yes, I could explain.

Okay, well then explain... the abridged version please :-P


> one question first: do you think it is a good idea to get into 
> longwinded
> theoretical/architectural kernel design discussions at this point? 
> Will it
> help geronimo get of the ground better / quicker? My ideas on software
> archictecture might fill a book, yours too, and before you know it
> geronimo spends a year coming up with a 0.1 release :D

No I do not, though I am interested to hear your opinions on this 
matter.

--jason

Re: geronimo and avalon?

[Leo Simons <le...@apache.org>]

Jason Dillon wrote:

>> Nope, no conclusion. Well, the only significant one perhaps is that 
>> building a J2EE suite on top of the framework avalon provides is 
>> definately possible. I am not going to get mingled in the debate of 
>> whether that is a good idea (me, I think a JMX-based microkernel 
>> remains a bad idea, even though it is working so well for JBoss. But 
>> that's just me ;).
>
> Can you explain why you believe that a JMX-based micro-kernel is a bad 
> idea?

Yes, I could explain.

one question first: do you think it is a good idea to get into longwinded
theoretical/architectural kernel design discussions at this point? Will it
help geronimo get of the ground better / quicker? My ideas on software
archictecture might fill a book, yours too, and before you know it
geronimo spends a year coming up with a 0.1 release :D

>> Just know some of the avalon regular are listening in with an 
>> interested ear to hear what's all the fuzz about ye olde Indian war 
>> chief, and we're more than willing to help you evaluate what stuff 
>> (if any) you want to use from the avalon project. And we can probably 
>> leave y'all completely alone, too, if desired ;)
>
> I have had a look at Avalon several times in the past and very 
> recently looked over some of the web pages... and my general feeling 
> is that it is too bloated

bloated? Hmm. I can see how you would get that impression from
a quick glance at all avalon subprojects at once (we certainly have
a lot of code, all in all). I am guessing though that if you download
a single container distributable (say, avalon-phoenix-4.0.4-src.zip),
you'll find it rather compact and picky about what it does and does
not do.

> and does not provide some core functionality which Geronimo will 
> probably want to have.

I'll bet the farm (no, I think I'll bet a shoe) on that!

> I am not against looking into or even using a pre-existing system such 
> Avalon for the core component framework for Geronimo, but I am very 
> skeptical about how feasible it will be to implement.
>
> I am very familiar with the core systems of JBoss, and hope to 
> implement a similar yet enhanced loading, component model and 
> deployment system.  It does not appear that any one system has all of 
> the bases covered, which would mean that we would have a lot of 
> hacking work to get something integrated and functional. 

looking at the amount of energy geronimo has gathered in 24 hours,
I think you guys don't have to worry about too little hands to take on
a task ;)

> Anyways, perhaps we should start out with and outline of the core 
> system services for Geronimo and the requirements for each, and then 
> we can see which systems may be suitable for integration.

sounds like a plan. I'll be lurking :D

cheers,

- Leo

Re: geronimo and avalon?

["Geir Magnusson Jr." <ge...@adeptra.com>]

On Friday, August 8, 2003, at 04:49 AM, Christian Trutz wrote:

> On Fri, Aug 08, 2003 at 09:04:24AM +0100, Paul Hammant wrote:
>> Folks,
>>
>> It is way too early to talk of a (internal) component design.  
>> Refactor
>> to it later. Or enable all visions, again later.  Working code that
>> passes unit tests is far more important.
>>
> 1+
>
> what will be the first geronimo code ?
> A modified elba code???

No, and this is really important.

The Elba code is JBoss code, and thus will NOT enter the Apache CVS, 
nor can it be licensed with the Apaache License.  The ASF will *not* 
let another entity's license be violated.

Any code that comes to the ASF will be either new code, or code that is 
clearly free of any encumbrance by any other author or organization.  
The point of the incubation process is to ensure that this rule is 
followed both to the letter and the spirit.

geir

-- 
Geir Magnusson Jr                                   203-956-2604(w)
Adeptra, Inc.                                       203-434-2093(m)
geirm@adeptra.com                                   203-247-1713(m)

Re: geronimo and avalon?

[Christian Trutz <ch...@smilebase.org>]

On Fri, Aug 08, 2003 at 09:04:24AM +0100, Paul Hammant wrote:
> Folks,
> 
> It is way too early to talk of a (internal) component design.  Refactor 
> to it later. Or enable all visions, again later.  Working code that 
> passes unit tests is far more important.
> 
1+

what will be the first geronimo code ? 
A modified elba code???

chris

> Regards,
> 
> - Paul
> (hammant at apache.org)
> 
> >I think you are right.
> >Either JMX or Avalon, it is born after a successful project, the fomer one 
> >is born after JBoss.
> >If this project comply with JMX, it may looks like JBoss.
> > 
> >
> 
> 
> 
> -- 
> http://www.thoughtworks.com -> The art of heavy lifting.
> Home for many Agile practicing, Open Source activists...
> 

Re: XP principles [ was "geronimo and avalon?" ]

[Paul Hammant <Pa...@ThoughtWorks.net>]

James,

>> Any chance that this project could lean towards TDD?
>
>
> I'd love it to.

:-)

>
>> That, obviously after you guys have booked code in, componentized it 
>> and test covered it.  That and working out what to test, versus what 
>> will be replaced etc.
>
>
> We've so much to do and quite a large community with some folks 
> haven't been properly TDD infected yet so I'd not want to absolutely 
> enforce that TDD must be done on all code but I'd hope it can become 
> the norm.


Bit by bit though right ?

He he, the more I write here and the more often, the more ideas and 
design that I throw in, the more i delay you n the others completing the 
basics and shipping first src/bins right? 

-- 
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...

Re: XP principles [ was "geronimo and avalon?" ]

[James Strachan <ja...@yahoo.co.uk>]

On Friday, August 8, 2003, at 09:26  am, Paul Hammant wrote:
> James,
>
> Any chance that this project could lean towards TDD?

I'd love it to.


> That, obviously after you guys have booked code in, componentized it 
> and test covered it.  That and working out what to test, versus what 
> will be replaced etc.

We've so much to do and quite a large community with some folks haven't 
been properly TDD infected yet so I'd not want to absolutely enforce 
that TDD must be done on all code but I'd hope it can become the norm.

James
-------
http://radio.weblogs.com/0112098/

XP principles [ was "geronimo and avalon?" ]

[Paul Hammant <Pa...@ThoughtWorks.net>]

James,

Any chance that this project could lean towards TDD?

That, obviously after you guys have booked code in, componentized it and 
test covered it.  That and working out what to test, versus what will be 
replaced etc.

Regards,

- Paul

>> It is way too early to talk of a (internal) component design.  
>> Refactor to it later. Or enable all visions, again later.  Working 
>> code that passes unit tests is far more important.
>
>
> +1.
>
> Lets try not do too much design up front. Most important right now is 
> creating unit tests, getting good test coverage & completing the 
> EJB/MDB container & integrating Tomcat/Jetty, James, Axis, OJB,  
> OpenJMS etc. (Note thats not just dropping components into a container 
> - its things like using MDBs in James & Axis or transactions in OJB, 
> OpenJms and EJB etc).
>
> Lets take an XP approach to get things functional and get it tested & 
> working, then look at refactoring when it makes sense later on. If we 
> spend too much time on up front design right now we'll never get 
> anywhere. I think Geronimo can only really be succesful if we follow 
> an XP path and let the framework show itself to us as we refactor 
> rather than designing it up front.
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
>


-- 
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...

Re: geronimo and avalon?

[James Strachan <ja...@yahoo.co.uk>]

On Friday, August 8, 2003, at 09:04  am, Paul Hammant wrote:

> Folks,
>
> It is way too early to talk of a (internal) component design.  
> Refactor to it later. Or enable all visions, again later.  Working 
> code that passes unit tests is far more important.

+1.

Lets try not do too much design up front. Most important right now is 
creating unit tests, getting good test coverage & completing the 
EJB/MDB container & integrating Tomcat/Jetty, James, Axis, OJB,  
OpenJMS etc. (Note thats not just dropping components into a container 
- its things like using MDBs in James & Axis or transactions in OJB, 
OpenJms and EJB etc).

Lets take an XP approach to get things functional and get it tested & 
working, then look at refactoring when it makes sense later on. If we 
spend too much time on up front design right now we'll never get 
anywhere. I think Geronimo can only really be succesful if we follow an 
XP path and let the framework show itself to us as we refactor rather 
than designing it up front.

James
-------
http://radio.weblogs.com/0112098/

Re: geronimo and avalon?

[Paul Hammant <Pa...@ThoughtWorks.net>]

Folks,

It is way too early to talk of a (internal) component design.  Refactor 
to it later. Or enable all visions, again later.  Working code that 
passes unit tests is far more important.

Regards,

- Paul
(hammant at apache.org)

>I think you are right.
>Either JMX or Avalon, it is born after a successful project, the fomer one is born after JBoss.
>If this project comply with JMX, it may looks like JBoss.
>  
>



-- 
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...

Re: geronimo and avalon?

[Justin Ju <ju...@bigfoot.com>]

I think you are right.
Either JMX or Avalon, it is born after a successful project, the fomer one is born after JBoss.
If this project comply with JMX, it may looks like JBoss.

----- Original Message ----- 
From: "Noel J. Bergman" <no...@devtech.com>
To: "Jason Dillon" <ja...@coredevelopers.net>; "Leo Simons" <le...@apache.org>
Cc: <ge...@incubator.apache.org>
Sent: Friday, August 08, 2003 1:58 AM
Subject: RE: geronimo and avalon?


> Jason,
> 
> > I have had a look at Avalon several times in the past and very recently
> > looked over some of the web pages...
> 
> FYI, the Avalon Frameworks have been stable, but Avalon container
> development has gone through a period of change.  As of very recently, there
> appears to be a hard won consensus on a single extensible codebase.  At its
> core, that codebase focuses on how to build containers (sort of a Service
> Provider interface for containers).  Actual containers are built on that
> model, exposing the behaviors and interfaces necessary for components.
> 
> > I [hope] implement [an] enhanced loading, component model and
> > deployment system.  It does not appear that any one system has
> > all of the bases covered, which would mean that we would have
> > a lot of hacking work to get something integrated and functional.
> 
> > perhaps we should start out with and outline of the core system
> > services for Geronimo and the requirements for each, and then we
> > can see which systems may be suitable for integration.
> 
> Sounds reasonable.  What do you feel Geronimo will need?
> 
> --- Noel
> 
> 

RE: geronimo and avalon?

["Noel J. Bergman" <no...@devtech.com>]

Jason,

> I have had a look at Avalon several times in the past and very recently
> looked over some of the web pages...

FYI, the Avalon Frameworks have been stable, but Avalon container
development has gone through a period of change.  As of very recently, there
appears to be a hard won consensus on a single extensible codebase.  At its
core, that codebase focuses on how to build containers (sort of a Service
Provider interface for containers).  Actual containers are built on that
model, exposing the behaviors and interfaces necessary for components.

> I [hope] implement [an] enhanced loading, component model and
> deployment system.  It does not appear that any one system has
> all of the bases covered, which would mean that we would have
> a lot of hacking work to get something integrated and functional.

> perhaps we should start out with and outline of the core system
> services for Geronimo and the requirements for each, and then we
> can see which systems may be suitable for integration.

Sounds reasonable.  What do you feel Geronimo will need?

	--- Noel

Re: geronimo and avalon?

[Jason Dillon <ja...@coredevelopers.net>]

> Nope, no conclusion. Well, the only significant one perhaps is that 
> building a J2EE suite on top of the framework avalon provides is 
> definately possible. I am not going to get mingled in the debate of 
> whether that is a good idea (me, I think a JMX-based microkernel 
> remains a bad idea, even though it is working so well for JBoss. But 
> that's just me ;).

Can you explain why you believe that a JMX-based micro-kernel is a bad 
idea?


> Just know some of the avalon regular are listening in with an 
> interested ear to hear what's all the fuzz about ye olde Indian war 
> chief, and we're more than willing to help you evaluate what stuff (if 
> any) you want to use from the avalon project. And we can probably 
> leave y'all completely alone, too, if desired ;)

I have had a look at Avalon several times in the past and very recently 
looked over some of the web pages... and my general feeling is that it 
is too bloated and does not provide some core functionality which 
Geronimo will probably want to have.  That said, I did not make an 
extensive investigation into Avalon, just looked over some of the docs.

I am not against looking into or even using a pre-existing system such 
Avalon for the core component framework for Geronimo, but I am very 
skeptical about how feasible it will be to implement.

I am very familiar with the core systems of JBoss, and hope to 
implement a similar yet enhanced loading, component model and 
deployment system.  It does not appear that any one system has all of 
the bases covered, which would mean that we would have a lot of hacking 
work to get something integrated and functional.

Anyways, perhaps we should start out with and outline of the core 
system services for Geronimo and the requirements for each, and then we 
can see which systems may be suitable for integration.

--jason

Re: geronimo and avalon?

[Emmanuel Bernard <ep...@yahoo.fr>]

Some Reply-To issue

Emmanuel Bernard wrote:

> James Strachan wrote:
>
>> We're  in the middle of building a special kind of container, 
>> Geronimo.  Given time, Geronimo could end up being an Avalon 
>> container. Or it could have an optional Avalon module so some 
>> adapter/service could allow any existing Avalon container (or 
>> PicoContainer) to drop right in and so it could end up reusing any of 
>> the plethora of containers out there (off the top of my head there 
>> is... Phoenix, Plexus, ECM, Fortress, Merlin, Loom, DNA, JContainer, 
>> PicoContainer, NanoContainer - which are all different Avalon, 
>> ex-Avalon or PicoContainer implementations).
>>
>> I'm pretty sure we'll eventually support (somehow) Avalon & Pico 
>> components in some way. Interoperability is a goal. Lets just leave 
>> the implementation time to grow first and make decisions based on 
>> whats best for Geronimo the container. JMX, Avalon and Pico are 3 
>> component models I'd like us to support - lets keep the container 
>> open first though until it gets the basic requirements (JTA, EJB, 
>> MDB, Web) sorted out. 
>
>
> James,
> Avalon principes and container implementation choices should be 
> separated.
>
> When I had a look at Avalon framework, I was please to find a standard 
> way to see and manage components. Leo already starts a + and - list, 
> so I won't do my own list, but I think using Avalon principles to 
> build a *component based* J2EE compliant projet with pluggable 
> implementation capabilities (as I can see in the mainling list), is a 
> good idea. Avalon guys already think about these kind of issues. I'm 
> not experienced enough, but It seems to be far more easy to start 
> Geronimo implems over Avalon than doing one and refactor later.
>
> If you think that available container impelmentations is not 
> *standardized* enough to start Geronimo on it, feel free to implement 
> a Geronimo one to start the project.
>
> Emmanuel
>

Re: geronimo and avalon?

[James Strachan <ja...@yahoo.co.uk>]

Thanks Leo for a good email...

On Thursday, August 7, 2003, at 04:58  pm, Leo Simons wrote:

> ...not right now, I think. Here's some more thoughts on that.
>
> Hey gang,
>
> okay, okay, I can't resist throwing in a few words about this. I've 
> been an avalon committer for several years now, and I've used it for 
> many if not all of my software projects ever since becoming 'infected' 
> by it. So I am probably way biased.
>
>
> Why build on avalon
> -------------------
> One answer: it's a solid, tried and tested Apache project with a lot 
> of mature, tried and tested code and concepts that have been proven to 
> work well in environments ranging from embedded devices to oracle 
> clusters.
>
> Another answer: it already integrates with a lot of projects that are 
> likely to be on the shortlist for integration with Geronimo, like
>
> * OpenEJB (drag-and-drop runs on top of avalon-phoenix (and 
> avalon-merlin))
>
> * Jetty and Tomcat (drag-and-drop run on top of avalon-phoenix (and 
> avalon-merlin))
>
> * James (has always run on top of and shipped with avalon-phoenix (and 
> runs on avalon-merlin as well))
>
> * HSQLDB (drag-and-drop runs on top of avalon-phoenix)
>
> * several of the other important enterprise technologies can be added 
> in as well rather easily if not out of the box, for example Axis 
> (through the Ivory wrapper)
>
> * MX4J (avalon-phoenix has builtin JMX support through MX4J)
>
> * Log4J (avalon-phoenix can be configured to use log4j)
>
> * Xerces (avalon-framework has an xml-based configuration system that 
> usually is coupled to xerces)
>
> another answer: avalon is all about server software architecture, and 
> the general approach offered by the patterns it promotes (COP, 
> Seperation of Concerns, Inversion of Control) is hands down the 
> cleanest and most reliable way to build complex software. Those 
> approaches are implemented well throughout avalon code. Really well.
>
> Sounds compelling, doesn't it? So much so, in fact, someone did so for 
> his graduation thesis (http://ichilli.sourceforge.net/, code not 
> public though).
>
>
> Wny not build on avalon
> -----------------------
> - While all those important components listed do integrate with avalon 
> easily, they're for the most part not actually built with avalon 
> (James being one notable exception).
>
> - Avalon is at the moment a relatively small project (somewhere around 
> 20 committers I think) compared to what Geronimo is likely to be in 5 
> months; it might be just as easy to just fork and/or rewrite it and 
> not have such a big dependency at the very core of a project. (IMHO, 
> one of the reasons for avalon never being used internal to tomcat. 
> That, and several tomcat peeps disagreeing with some avalon design 
> decisions).
>
> - the current list of committers for geronimo doesn't include many 
> people that have lots of experience with avalon, while there is a lot 
> of people with experience in doing things differently (ie JMX-based 
> like JBoss)
>
> - Avalon has a relatively high learning curve. To gain all the 
> cleanliness it provides, its security and its stability you need to 
> know how to use it well; getting to grips with an IoC (Inversion of 
> Control) setup is way more difficult at first than getting to grips 
> with a central-registry style approach (JNDI, JMX, etc).
>
> - Avalon imposes strict contracts. You have to do lots of stuff in the 
> way the avalon design dictates you to. (well, usually, you don't, 
> really, but most peeps, including avalon regulars, disagree with me on 
> that :D)
>
> - a lot of the avalon folk have always complained heavily about the 
> limitations of EJBs, so much so in fact that they have written an 
> avalon-based alternative (www.enterpriseobjectbroker.org) to show how 
> much better the world is without EJB.

AFAIK the EOB project is now moving towards using PicoContainer rather 
than Avalon.


> - the avalon mindset seems to behave rather virally. Once people 
> become convinced that IoC is the way to go, they never go back.
>
> - there is already an initial codebase that doesn't use it, and we 
> want to go forward with that. Refactoring around avalon would delay a 
> first release by miles.
>
> Conclusion
> ----------
> Nope, no conclusion. Well, the only significant one perhaps is that 
> building a J2EE suite on top of the framework avalon provides is 
> definately possible. I am not going to get mingled in the debate of 
> whether that is a good idea (me, I think a JMX-based microkernel 
> remains a bad idea, even though it is working so well for JBoss. But 
> that's just me ;).
>
> Just know some of the avalon regular are listening in with an 
> interested ear to hear what's all the fuzz about ye olde Indian war 
> chief, and we're more than willing to help you evaluate what stuff (if 
> any) you want to use from the avalon project. And we can probably 
> leave y'all completely alone, too, if desired ;)
>
>
> Deal with the big things first
> ------------------------------
> I suggest everyone waits for a few weeks 'till the first bits of code 
> are here, knowledge has been gained and the project has been 
> 'bootstrapped', before raising the topic again. I don't think its 
> healthy (and I mean for geronimo *and* avalon, in case anyone wonders) 
> if people go saying "geronimo really should use avalon" nor "that is 
> absolutely out of the question" before you guys get some other things 
> settled first. You can always change your mind later.

I've tried to reflect this in the FAQ.


> But again, that's just me, known for being off the mark :D

You're totally on the mark.

At this point we're not ruling nothing in or out - just requesting some 
time to grow & decide.


We're  in the middle of building a special kind of container, Geronimo. 
  Given time, Geronimo could end up being an Avalon container. Or it 
could have an optional Avalon module so some adapter/service could 
allow any existing Avalon container (or PicoContainer) to drop right in 
and so it could end up reusing any of the plethora of containers out 
there (off the top of my head there is... Phoenix, Plexus, ECM, 
Fortress, Merlin, Loom, DNA, JContainer, PicoContainer, NanoContainer - 
which are all different Avalon, ex-Avalon or PicoContainer 
implementations).

I'm pretty sure we'll eventually support (somehow) Avalon & Pico 
components in some way. Interoperability is a goal. Lets just leave the 
implementation time to grow first and make decisions based on whats 
best for Geronimo the container. JMX, Avalon and Pico are 3 component 
models I'd like us to support - lets keep the container open first 
though until it gets the basic requirements (JTA, EJB, MDB, Web) sorted 
out.

James
-------
http://radio.weblogs.com/0112098/