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.
