You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by daniel_k <ma...@danielkastenholz.de> on 2008/05/26 02:35:04 UTC
GBean frustration -- please help
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.
Re: GBean frustration -- please help
Posted by Kevan Miller <ke...@gmail.com>.
On May 31, 2008, at 8:58 AM, daniel_k wrote:
>
> 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.
Hi Daniel,
Your English seems very good to me. It's the ideas and concepts behind
the words that are important. We'd welcome your contributions and
discussion.
>
>
> 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?
I think that would be an excellent topic. You'll find some general
discussion here --
http://www.nabble.com/Heads-up---GBeanInfo-via-annotations-tt16379389.html#a16379389
And here's the Jira -- https://issues.apache.org/jira/browse/GERONIMO-3952
To directly edit documentation on our Wiki, you'll need to submit an
ICLA to the Apache Software Foundation.
http://www.apache.org/licenses/icla.txt
Once filled out, you can mail or fax the document to address/phone
number in the document. Or you can scan the document and email to:
secretary@apache.org and legal-archive@apache.org
The ICLA insures that the ASF has license to use your contributions
under the Apache License. The alternative is to attach files to Jira's
with the "Grant license to ASF" button clicked.
--kevan
Re: GBean frustration -- please help
Posted by daniel_k <ma...@danielkastenholz.de>.
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 {@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:
>> 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.
Re: GBean frustration -- please help
Posted by David Jencks <da...@yahoo.com>.
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 {@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: http://www.nabble.com/GBean-frustration----please-help-tp17464048s134p17499362.html
> Sent from the Apache Geronimo - Users mailing list archive at
> Nabble.com.
>
Re: GBean frustration -- please help
Posted by daniel_k <ma...@danielkastenholz.de>.
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.
Re: GBean frustration -- please help
Posted by David Jencks <da...@yahoo.com>.
On May 25, 2008, at 5:35 PM, daniel_k wrote:
>
> 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?!?
I'm not quite sure what you expect. To me the idea behind gbeans was...
- every server when running consists of a bunch of components wired
together
- we'll formalize this by making the components gbeans with explicit
metadata (GBeanInfo) and uniform "plans" for the wiring and
configuration
- deployment of javaee apps will consist of translating the javaee
descriptors and associated geronimo plans to an "intermediate
language" of gbean configurations, which can then be loaded and
started without further analysis.
This says nothing about how strict the interpretation of javaee
artifacts is. In fact based on some incidental results from tck
testing we may be significantly more strict about what we accept than
other servers.
I'm not as sure as I used to be that this strictness is a good idea.
If you have some suggestions for making geronimo easier to use in this
way, please discuss them.
>
>
> - 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???
From a philosophical point of view, the original attitude was, don't
use jndi at all in gbeans, use gbean references instead: this supports
container managed dependency injection rather than requiring your code
to go on a fishing expedition in jndi with no way to predict what it
will find. If you use gbean references, the container will make sure
that the components are started in an order so that all the references
are available before the component is started. With jndi there is no
way to guarantee that within a module.
From a javaee perspective, the contents of the java:comp/env context
is specified explicitly for each kind of component, and there is no
requirement that anything in particular be available in any global
jndi context. To provide something similar for gbeans, we'd have to
have an equivalent way of specifying just what is supposed to be
available in a gbean's java:comp/env context and what it is supposed
to point to. Since we have what I regard as technically superior
dependency injection without jndi, this doesn't seem like a good use
of code or time.
From a practical perspective, there is a bunch of stuff available in
jndi to gbeans. First of all if a javaee component calls a gbean in a
service or initialization thread, the gbean will get the java:comp/env
context of the javaee component calling it. If you switch threads
you'll lose the java:comp/env context. Secondly, most all the
components you can access in java:comp/env are also now bound in
global jndi, including ejbs, j2ca connectors, and j2ca admin objects.
We even have some documentation on this...
http://cwiki.apache.org/GMOxDOC21/jndi.html
http://cwiki.apache.org/GMOxDEV/client-jndi-names.html
While there are a lot of things I still like a lot about gbeans I
think some problems are starting to appear. In particular many people
find them too hard to write and use, and they often don't relate well
to other component frameworks. I also think we don't have the balance
right yet between "original configuration" and overrides or "tuning
knobs". We could certainly use more input, points of view, or help
with this.
thanks
david jencks
>
>
> 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.
>