Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@geronimo.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer;
  b=xe+q70fSvgo3mYYqelGGrHSrzGYXI3AX55TiIiYS/gx1glOG3kyTxQmf1FW2n01xPviQZZ6sCi+47TBOyxJc/yxAgUT0TgqBhOA6wZ5PWX15BBEEnTOMgq7+nFpbp0CFVPphgNwg314mMA1dundjeLkZRFXnBAJ+rfFftqJ1q4Q=
  ;
Message-Id: <192BCB6E-B47F-4072-8709-FEBD2D7E7325@yahoo.com>
From: David Jencks <david_jencks@yahoo.com>
To: user@geronimo.apache.org
In-Reply-To: <17464048.post@talk.nabble.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: GBean frustration -- please help
Date: Mon, 26 May 2008 23:40:12 -0700
References: <17464048.post@talk.nabble.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.
>