>> I think gbeans achieve modularity and low coupling, but I think they  
>> do easy at the expense of ease of use.
>> Perhaps by using two separate apis it might be possible to do both?

>I'm not sure what you mean.  Could you explain in more detail?

I am sure somebody must have distilled this tension in some article somewhere.
I hope I can explain it properly. The issue is coupling vs. usability. The most
'usable' way for me to find the transaction manager gbean would be, let's say:

TransactionManager tm = GeronimoTransactionManager.getInstance()

It's the most usable because it can be checked at compilation time. Looking up
a reference in a directory is much more fragile.

On the other, this would couple all the Geronimo components inextricably, which
definitely outweighs the benefits of usability.

However, sometimes there is something small you can do to get most of what you want
(80/20 rule) (a rule popularized by Woody Allen say "80% of life consists of just
showing up"). In this case you could have some code which sits on top of the GBean
architecture and makes them easier to use.

Since GBeans have xml plans, a simple way to do this might be to parse a set of plans
(the "Geronimo Plan API") and generate classes for them, e.g.:

package org.apache.geronimo.plan;

public class J2eeServerPlan {

        public GBean getDefaultThreadPool() {
                //look up by ObjectName

        public GBean getConnectionTracker() {
                //look up by ObjectName

        public GBean getDefaultWorkManager() {
                //look up by ObjectName        


It would probably be best to actually check at runtime that the api is in sync with the
plans actually deployed, in case people alter the plans.

Another approach that would greatly simplify things would be to use a separate file for
each GBean and let a directory represent a configuration, so that if you want to know the
name of some GBean you can do "find . | grep -v transaction" for example, and see this:


Although this approach alone would not let you catch dependency problems at compilation time.


In compliance with applicable rules and regulations, Instinet
reviews and archives incoming and outgoing email communications,
copies of which may be produced at the request of regulators.
This message is intended only for the personal and confidential
use of the recipients named above. If the reader of this email
is not the intended recipient, you have received this email in
error and any review, dissemination, distribution or copying is
strictly prohibited. If you have received this email in error,
please notify the sender immediately by return email and
permanently delete the copy you received.

Instinet accepts no liability for any content contained in the
email, or any errors or omissions arising as a result of email
transmission. Any opinions contained in this email constitute
the sender's best judgment at this time and are subject to change
without notice. Instinet does not make recommendations of a
particular security and the information contained in this email
should not be considered as a recommendation, an offer or a
solicitation of an offer to buy and sell securities.