Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
From: "Jeremy Boynes" <jeremy@coredevelopers.net>
To: <geronimo-dev@incubator.apache.org>
Subject: RE: Geronimo Deployment Descriptors
Date: Sun, 7 Sep 2003 13:28:16 -0700
Message-ID: <000b01c3757e$920ed300$b625a8c0@ABU>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <3F5AD291.1050903@mortbay.com>
Importance: Normal

> From: Gmane Remailer [mailto:public@main.gmane.org] On Behalf Of Greg
Wilkins
> Oops - I have re-read Jeremys email - and yes he is not 
> extending the standard based descriptor, but moving it's 
> content to our own descriptor.
> 
> That is better than extending the standards descriptor.
> 
> However, I am still concerned with this proposal as many of 
> the tools, lifecycle and duplication issues remain:
> 
>   + Content will be duplicated in a ejb-jar.xml and 
> geronimo-ejb-jar.xml
>     This will have to be kept is sync, or validated that it 
> is in sync.
>     Either way, this is a pain.   Not having the ejb-jar.xml is not an
>     option, as we are then encouraging non-standard deployments.
> 

Whenever you have multiple files, you have the problem of keeping things
in sync. I believe this is actually easier with the current
implementation than with one with multiple files containing partial
information.

If you are deploying an existing assembly by hand, then the process is
simply to copy the standard descriptor and add in the geronimo-specific
elements. I believe this is simpler than creating extra additional files
from scratch by copying in the right combination of structural matching
elements then adding in the new content.

The deployment process is *much* more complicated for EJBs than, for
example web-apps. I would ask those who have not done this before to try
deploying EJBs in a real application (e.g. the Sun Petstore) by hand for
a container such as JBoss or Weblogic.

I also believe the new approach is easier if you are a developer rapidly
iterating an implementation. You can make all your changes in one file
(ours), rather than having to synchronize changes to 2 or 3 different
files. Once you are done, the revised standard descriptor can easily be
generated by stripping out the geronimo-specific elements from our
descriptor. Providing a tool to do this is trivial.

Of course, if someone is using a (good) deployment tool then there is no
real difference in the approaches. For example, with a tool like XDoclet
the master copy is in the meta-tags so in reality both the standard and
geronimo descriptors are duplicates; with this tool both DDs are
regenerated each time so maintenance of the XML is not an issue.

More sophisticated tools (like IDEs) will use the Deployment API (JSR88)
rather than editing XML files so for them the format of our descriptors
is irrelevant.


>   + The lifecycle of the file will still be an issue for any 
> tools that
>     generates ejb-jar.xml files.  Merging will need to be done with
>     any content added to the geronimo version after the last 
> generation
>     was done.
> 
> So I am still -1 on this...
> 
> UNLESS we have it that all the contents of the 
> geronimo-ejb-jar.xml file is optional and IFF present 
> overrides the contents of an ejb-jar.xml file on an element 
> by element basis.
> 

I considered this but thought that it was really an enhancement to what
I already had and that is presented some challenges that we did not need
to tackle at this time.

For example, how do you resolve inconsistencies between the two
definitions? Say the geronimo DD defines a local view but the standard
DD defines a remote view; did the deployer mean we have a local view, a
remote view or both? Do we change the model for the view tags so that
empty means drop the view? I was uncomfortable with changes like that
which modified the validation criteria in the standard schema.

I would say this needs exploration, so it might be an idea to start a
branch to try this out.

I am reluctant to back out the current code as we don't have an
alternative at this time and so other stuff that depends on being able
to load DDs will break. I suggest we stay with what we have until an
alternative is available and then restart this discussion then.

--
Jeremy