geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From daniel_k <m...@danielkastenholz.de>
Subject Re: GBean frustration -- please help
Date Tue, 27 May 2008 20:32:23 GMT

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.



>> - 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.

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?



>> 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.



>> 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.

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.



>> 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?

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.


Mime
View raw message