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
>> EJBs, JNDI
>> 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 [EMAIL PROTECTED] 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:
>> http://www.nabble.com/GBean-frustration----please-help-tp17464048s134p17499362.html
>> Sent from the Apache Geronimo - Users mailing list archive at
>> Nabble.com.
>>
>
>
>
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?
Cheers
Daniel
--
View this message in context:
http://www.nabble.com/GBean-frustration----please-help-tp17464048s134p17574957.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
