geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From daniel_k <>
Subject Re: GBean frustration -- please help
Date Sat, 31 May 2008 12:58:34 GMT

djencks wrote:
> 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;
> Then...
>     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  

Hi David,

as you have certainly noticed, I'm far from writing English at near-native
level, and I am not too deeply involved in Geronimo yet, so the ration
between follow-up inquiries and actual output would be ... suboptimal.

If you keep that in mind while you're finding a few minor open issues for me
to work on, I will see what I can do. How about the documentation for this
new annotation-driven GBean Info thing that you're working on?



View this message in context:
Sent from the Apache Geronimo - Users mailing list archive at

View raw message