geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From daniel_k <m...@danielkastenholz.de>
Subject GBean frustration -- please help
Date Mon, 26 May 2008 00:35:04 GMT

Hi,

when I started working with Geronimo a few weeks ago, one of the key
arguments for Geronimo (rather than Glassfish or others) was the striking
simplicity of its GBean concept, or at least what "appeared" simple to me at
that time.

I've never understood what's could fascinate SUN or anyone about
one-dimensional concepts. But they keep producing them again and again. Why
does every new standard come with a black and white distinction, i.e.
something is either a class or an instance, or: something is either a web
application or a bean, and so forth; just to notice in revision 1.5 that
this division was arbitrary and it is particularly the gray area "between"
black and white that could leverage productivity.

When I read about GBeans, I was amazed: why not reduce all this ZIP, EAR,
WAR, JAR, etc. madness to just one file format? Why not leave it to a module
whether it wants to be a resource adapter, a web application, a persistence
unit, or none of it or all of it? Geronimo sounded so cool. GBeans seemed to
offer a "flat" concept: no one-dimensional separation. Start off with the
least possible restrictions and the full range of possibilities. Provide a
very, very general concept for "building blocks", and permit an entity to do
everything and but demand nothing in advance (home/remote interface) that
might turn out as overhead for 90% of the cases. Awesome.

Well, the initial amazement has suffered. Just two examples. Maybe I'm
wrong, but could it be that:

- it is NOT irrelevant for Geronimo whether I deploy my content as JAR, WAR,
or CAR? Because it DOES lead to different results (error and success
actually) whether I name a file with WEB-INF/web.xml /
WEB-INF/geronimo-web.xml inside a ".WAR" or a ".JAR". In fact, Geronimo
treats archives so strictly, it will even reject the deployment if the file
is not a .WAR. Question:  WHY?!?

- there is really no way for a GBean to access the JNDI directory? If so:
why? WHY? WHY???? Isn't it the bare "intention" of a "directory service" to
connect arbitrary units so they can get in touch and talk to each other?
I've spent hours with Google to find an answer to this question, just to
read that "GBeans aren't part of J2EE, and thus so they don't have access to
the context or JNDI registry". And thus can't look up a simple, boldly
announced data source. -- Excuse me ... WHAT?!?? So I'm now running a
beautiful application server which can maintain all kinds dependency graphs,
class loader hierarchies and bean interconnections, but it won't tell me how
A and B can talk to each other because some paper spec doesn't explicitly
"require" it???

Wow. If that's true, I'm really disappointed. I still hope it's not, and I'm
eager to learn, so PLEASE correct me if these assumptions are wrong, because
I'm tossing my hair over these questions.

Thanks in advance.


Daniel
-- 
View this message in context: http://www.nabble.com/GBean-frustration----please-help-tp17464048s134p17464048.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.


Mime
View raw message