geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: GBean frustration -- please help
Date Tue, 27 May 2008 21:02:49 GMT
I wish I had more time to reply more extensively right now.... a few  
comments inline.
On May 27, 2008, at 1:32 PM, daniel_k wrote:

> Hi David,
> thanks for taking the time for this extensive and constructive  
> answer and
> for clearing out some essential questions about the GBeans  
> architecture.
>>> I'm not quite sure what you expect.
> What I'm missing is the link between GBeans and the J2EE world, or,  
> a more
> extensive chapter on that in the Geronimo documentation. From what  
> you're
> saying I conclude GBeans were once intended as a rather internal  
> building
> block for Geronimo, and not intended as the building blocks for  
> applications
> that run "on" Geronimo.

Originally we wanted to build a really solid component framework  
infrastructure and use that to implement a j2ee server.  It took  
longer than we expected :-), we've lost a lot of the original  
contributors along the way, and there are some new ideas in the air.
>>> - deployment of javaee apps will consist of translating the javaee
>>> descriptors and associated geronimo plans to an "intermediate
>>> language" of gbean configurations
> But isn't there more potential in GBeans? I wouldn't mind building  
> my entire
> applications as networks of GBeans. I don't see the necessity for  
> etc. either. But then there should be more information on how to  
> wrap and/or
> address "traditional" Java/J2EE items in GBeans.

I can't say I'm thrilled with how jndi is used to back annotations in  
javaee 5, but the ejbs are really pretty simple, easy to use, and  
powerful for what you get out of them.  If you need transactions I  
can't really imagine a reason to do it without CMT and ejb3.
> Concretely: I really need instructions on how to connect to a  
> datasource
> from a GBean, and, preferably, without the circumstantial way  
> through an EJB
> or web application, as you pointed out. If the idea was really to  
> make the
> server "a bunch of components" and everything can be connected via
> annotations to avoid fishing expiditions (which is indeed a  
> beautiful and
> appropriate term), then why isn't my data pool already one of these
> components, or, (if it is), why doesn't the hint page at the end of  
> the
> wizard suggest
> @map(gbean-whatever)
> DataSource d;
> or
> @map(gbean-whatever)
> ConnectionPool p;
> instead of this circumstantial J2EE stuff?

It is possible to do what you want.... perhaps not quite as simply as  
you would like.  We don't have an actual datasource gbean, but you can  
get the datasource (or other connection factory) by calling a method  
on a gbean.  In fact this is how the jndi implementation works: when  
you look up your datasource, the jndi Reference object calls this  
method on the gbean.

So, your gbean needs a gbean reference to the  
ManagedConnectionFactoryWrapper gbean created as part of the db pool  
deployment.  So you'll have something like
//constructor injection
private final ManagedConnectionFactoryWrapper myDbPoolWrapper;


    DataSource ds = (DataSource)myDbPoolWrapper.$getResource();

//also need to declare the gbean-reference in the gbean info, or use  
an annotation.

(this is from memory so I hope I didn't make too many mistakes.   
There's at least one example of this in the geronimo (not openejb)  
timer code.  However I think this code is unused so will probably be  
removed soon)

>>> In particular many people
>>> find them too hard to write and use
> Again, I really liked the concept for its striking simplicity when I  
> read
> it. What you're saying about binding at activation time really hits  
> the
> mark. Unfortunately, the "gbean info" construction with all its string
> literals eats up a lot of the beauty of the concept in practice,  
> especially
> of the safety that is achieved elsewhere.
> Why not use annotations to mark "public" GBean methods/ 
> references/... as
> such? (Again, sorry if it's already there, couldn't find it.) Using  
> the
> GBeanFactory doesn't fit into the modern (java5?) approach at all. The
> GBeanBuilder is really springing forward like a Java 1.2 artifact.

Recently in trunk Gianny implemented this.  I have a couple gbeans I'm  
working on (not yet comitted) and it really simplifies things.
>>> I also think we don't have the balance
>>> right yet between "original configuration" and overrides or "tuning
>>> knobs".
> Absolutely. The documentation is growing, but still too short for a  
> big
> thing like Geronimo. Take the JFC. A lot of the classes contain as  
> much
> documentation as code. It's just an assumption, but I would hold a  
> bet that
> the Geronimo code is far from that. Not that I'm a Javadoc  
> fetishist, but I
> think it simply needs a lot of what many developers consider as  
> "bushwah" to
> make a project feasible for outsiders. And there could be a lot more
> "bushwah" for geronimo.
> The masses would probably accomodate better with GBeans if they knew  
> more
> about them, or if the web console (which is supposedly the "first
> impression" of Geronimo for 99% of all new Geronimo users) would point
> people right at the GBeans concept and make its simplicity so  
> obvious that
> all this unneeded J2EE complexity becomes just a minor matter.
> I was so delighted to find the example code for accessing my newly  
> created
> data code on the last page of the wizard. Probably boring for a  
> Geronimo
> developer or an experienced user. For me it was helpful. Why not  
> take this
> brightly shining example of usability a few steps further? When I  
> create a
> data source in J2EE fashion, couldn't there be a box saying: "Aha,  
> you're
> creating a new data source! Good you're working with Geronimo.  
> Because if
> you're used to addressing it like this -{ ugly InitialContext  
> example }-,
> with Geronimo, all you do is {@gbean-ref DataSource x}. Read all  
> about it
> [here]."
> Cool features are one thing. But they need to be made accessible to be
> useful. And by accessible I mean not to the developers, but to the  
> people
> who are supposed to "use" them.

yes..... time is the limiting factor.  If you would like to help with  
any of this that would be really great!
> There is an entry for "modules" in the GUI. If "modules" are really  
> just the
> "shrinkwrap" and GBeans the true essentials in Geronimo, then how  
> about a
> page to browse and view GBeans and their dependencies? Currently, I  
> have no
> idea how many GBeans are running on my box or what they might be  
> doing, or
> how I could reference GBean A to do X, simply because I don't know  
> that A
> exists and offers an X service.

Down near the end of the admin console menu there is a way to browse  
all the gbeans and see their attributes etc.  I think it might be the  
jmx viewer... every gbean is also exposed through jmx.  I don't think  
its all that easy to tell what services a gbean offers.
>>> From a philosophical point of view, the original attitude was, don't
>>> use jndi at all in gbeans, use gbean references instead
> Yes, to get back to this DataSource issue. After spending some more  
> time
> with Google, I found wrapper GBean classes for ActiveMQ connections.  
> With
> these I guess it's possible to wrap a queue as a GBean and then use
> gbean-references as you suggested. But are there any similar classes  
> for
> doing the same with regular SQL DB connections/data pools or even XA
> connections/data pools or to address the global Transaction Manager?  
> Or does
> Geronimo already instantiate such GBeans by default, but I'm just  
> not aware
> of it?

Yes, every datasource you deploy gets a  
ManagedConnectionFactoryWrapper, a ConnectionManager, and a (more or  
less useless) connection factory gbean.  If you have a j2ca resource  
adapter with a ResourceAdapter implementation you also get a  
ResourceAdapterWrapper gbean, and every admin object also gets a gbean.
> Thanks again
> Daniel
> -- 
> View this message in context:
> Sent from the Apache Geronimo - Users mailing list archive at  

View raw message