Geronimo Deployment Descriptors

[Jeremy Boynes <je...@coredevelopers.net>]

I have recently checked in a XML Schema for a couple of
Geronimo-specific deployment descriptors. These rely on namespaces to
allow vendor-specific elements to be included in standard deployment
descriptors.

For example, an ejb-ref would be defined as:
    <ejb-ref>
        <ejb-ref-name>ejb/MyEJB</ejb-ref-name>
        <ejb-ref-type>Session</ejb-ref-type>
        <home>my.EJB.Home</home>
        <remote>my.EJB.Remote</remote>
        <ger:jndi-name>TestEJB</ger:jndi-name>
    </ejb-ref>

where ger: is the prefix for the Geronimo namespace.

The way this is intended to work is that the deployer will copy the
standard deployment descriptor file to the Geronimo one and then add in
out entries. If a geronimo descriptor exists, we will not use the
standard one at all so developers will be able to work exclusively with
the geronimo version. We will provide a tool for generating a standard
descriptor by stripping out all geronimo-specific elements.

This is working for the application-client descriptor and we will be
building out the EJB one once we know what the container-specific
elements actually are.

This is a little different from the old-style form of vendor descriptors
(e.g. as used by Weblogic or JBoss) where they were separate documents
that contained just supplemental information. In light of this, I would
appreciate feedback on the approach before we get too far along.

--
Jeremy

Re: Geronimo Deployment Descriptors

[Siva <si...@sivasundaram.com>]

-1

Duplicating of the deployment information
isnt good.

Siva

RE: Coordinating Web App DD Work

[Jeremy Boynes <je...@coredevelopers.net>]

Greg and I just had a 4 hour IM session which I am trying to summarize
to the list right now. In it, we have a plan for doing this (plus some
other stuff).

--
Jeremy

> -----Original Message-----
> From: Aaron Mulder [mailto:ammulder@alumni.princeton.edu] 
> Sent: Sunday, September 07, 2003 9:23 PM
> To: geronimo-dev@incubator.apache.org
> Subject: Coordinating Web App DD Work
> 
> 
> 	If anyone's actually going to write either a web.xml 
> loader or a Geronimo-specific DD for web apps, please reply 
> to this before you start.  
> I had thought to do so myself in the next couple days, but 
> I'm happy to let someone else do it (I haven't really started 
> that part yet), I just want to make sure we don't all do it 
> at the same time.
> 
> Thanks,
> 	Aaron
> 
> On Mon, 8 Sep 2003, Greg Wilkins wrote:
> > > I can probably get a simple loader done tonight - would that help?
> > 
> > I am (or probably Jan) is happy to write the code for the web.xml 
> > loader (although I see the POJO model has been created/generated - 
> > thanks whoever).
> > 
> > It's not a matter of writing the loader, it is a matter of 
> designing 
> > the loader and the geronimo-web.xml schema.
> > 
> > If you think having working code is good for the debate, then I'll 
> > write a web POJO loader that loads from web.xml and 
> geronimo-web.xml?
> 
> 

Coordinating Web App DD Work

[Aaron Mulder <am...@alumni.princeton.edu>]

	If anyone's actually going to write either a web.xml loader or a
Geronimo-specific DD for web apps, please reply to this before you start.  
I had thought to do so myself in the next couple days, but I'm happy to
let someone else do it (I haven't really started that part yet), I just
want to make sure we don't all do it at the same time.

Thanks,
	Aaron

On Mon, 8 Sep 2003, Greg Wilkins wrote:
> > I can probably get a simple loader done tonight - would that help?
> 
> I am (or probably Jan) is happy to write the code for the web.xml
> loader (although I see the POJO model has been created/generated - thanks
> whoever).
> 
> It's not a matter of writing the loader, it is a matter of designing
> the loader and the geronimo-web.xml schema.
> 
> If you think having working code is good for the debate, then I'll
> write a web POJO loader that loads from web.xml and geronimo-web.xml?

Re: Geronimo Deployment Descriptors

[Greg Wilkins <gr...@mortbay.com>]

Jeremy Boynes wrote:
>>Using the "code is checked in" resolution to discussions is 
>> not a good precident to set.
> The "I don't like what you did but don't have a working alternative" one
> isn't either :-)

I think the proceedural point is that you should have flagged your
intent to  try a single file approach before writing and checking in
the code.  Then both bad discussion styles could have been avoided.


> If you turn the thought process around so that the 'merge' becomes
> stripping all geronimo-namespace elements from the file, the sync is
> trivial. It is much simpler than trying to merge the structure elements
> of two partial files.

Except if there are modifications to the standard elements of
the files - with some modifications done in the standard file
by developers/tools working on jboss/websphere etc and other
modifications done to the standard elements in the geronimo file.


> I don't see the problem here - if Jasper is using web.xml, then
> a) generating it from a unified geronimo-web.xml is trivial
> b) as all the geronimo elements are in a different namespace,
>    it would be easy for Jasper to ignore them (if it doesn't
>    already) 

I'm not worried about the geronimo elements.  I'm worried about
the duplicate content of the standard elements.

Think of an IDE that is running a webapp itself.  It is
going to be parsing and/or generating web.xml.   The developer
adds some filters, adjusts some initparams, fixes some
security constraints.

They now want to deploy the results in geronimo, but have an
geronimo-web.xml in existance.

But they can't just regenerate that geronimo-web.xml because another
developer may have been fixing their servlets using geronimo and may
have added some filters, adjusted some initparams, fixed some
security constraints etc. etc.

If the geronimo using developer was forced to make those changes
in the standard web.xml (instead of geronimo-web.xml) then the
IDE developer will be able to use normal change control to merge
the differences.  If they just regenerate geronimo-web.xml they
may blat over the changes of the geronimo developer.


OK, you can come back with other examples of how changes in
web.xml by the IDE developer will totally break a geronimo-web.xml.
However, I think it is the case that both approaches ugly sync and
maintenance scenarios.  We can both come up with nightmare scenarios,
so I don't think we can  say one is better than the other for all
uses and lifecycles.

So given that I see no clear advantage, I believe it is best
to go with defacto standard practises and good comp sci
principals of normalized data.

> c) you have already said you wanted to avoid duplicate parsing
>    which would mean exposing the POJO model to Jasper. As the
>    standard one is a generalization of the geronimo one, this
>    should be simple.

Eventually.  Don't hold your breath waiting for this.

But the two files approach can still create a single POJO tree
that we pass to a modified jasper.


> I can probably get a simple loader done tonight - would that help?

I am (or probably Jan) is happy to write the code for the web.xml
loader (although I see the POJO model has been created/generated - thanks
whoever).

It's not a matter of writing the loader, it is a matter of designing
the loader and the geronimo-web.xml schema.

If you think having working code is good for the debate, then I'll
write a web POJO loader that loads from web.xml and geronimo-web.xml?

cheers

RE: Geronimo Deployment Descriptors

[Jeremy Boynes <je...@coredevelopers.net>]

> From: Gmane Remailer [mailto:public@main.gmane.org] On Behalf 
> Of Greg Wilkins
> 
> Jeremy Boynes wrote:
> > 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.
> 
> Using the "code is checked in" resolution to discussions is 
> not a good precident to set.
> 

The "I don't like what you did but don't have a working alternative" one
isn't either :-)

> Sorry but I really think that duplicating/ignoring the 
> standard descriptors is fundamentally *wrong* and we should 
> not move forward on that basis (not unless there is 
> significant support for the idea and it is me that is *wrong* :-)
> 
> I understand the problem you are trying to fix - but I think 
> this cure is worse than the disease.
> 
> As you say, any time you have two files you have a sync 
> problem. Thus your solution, having two files, does not avoid 
> the need for manual or tool based syncs - but having 
> duplicate content introduced the need for merge as part of 
> that sync process.
> 

If you turn the thought process around so that the 'merge' becomes
stripping all geronimo-namespace elements from the file, the sync is
trivial. It is much simpler than trying to merge the structure elements
of two partial files.


> We should use the one approach for all deployment descriptors 
> - so if we do decide to go this way, we will have to 
> duplicate the content of web.xml into geronimo-web.xml.  
> There are many many tools that generate and/or parse web.xml 
> and JSR88 is not going to replace them overnight.  Jasper for 
> one is going to continue parsing the web.xml file itself, so 
> this approch applied to webapps is going to be difficult.
> 

I don't see the problem here - if Jasper is using web.xml, then
a) generating it from a unified geronimo-web.xml is trivial
b) as all the geronimo elements are in a different namespace,
   it would be easy for Jasper to ignore them (if it doesn't
   already) 
c) you have already said you wanted to avoid duplicate parsing
   which would mean exposing the POJO model to Jasper. As the
   standard one is a generalization of the geronimo one, this
   should be simple.

> We need to write the geronimo-web.xml and web.xml handling 
> code.  I really do not want to duplicate/ignore the content 
> of web.xml and I don't want to use a different solution to 
> the other deployment descripts.
> 

I can probably get a simple loader done tonight - would that help?

--
Jeremy

Re: Geronimo Deployment Descriptors

[Greg Wilkins <gr...@mortbay.com>]

Jeremy Boynes wrote:
> 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.

Using the "code is checked in" resolution to discussions is not a good
precident to set.

Sorry but I really think that duplicating/ignoring the standard descriptors
is fundamentally *wrong* and we should not move forward on that basis (not
unless there is significant support for the idea and it is me that is *wrong* :-)

I understand the problem you are trying to fix - but I think this cure is
worse than the disease.

As you say, any time you have two files you have a sync problem. Thus your
solution, having two files, does not avoid the need for manual or tool based
syncs - but having duplicate content introduced the need for merge as part
of that sync process.

We should use the one approach for all deployment descriptors - so if we
do decide to go this way, we will have to duplicate the content of web.xml
into geronimo-web.xml.  There are many many tools that generate and/or
parse web.xml and JSR88 is not going to replace them overnight.  Jasper for
one is going to continue parsing the web.xml file itself, so this approch
applied to webapps is going to be difficult.

We need to write the geronimo-web.xml and web.xml handling code.  I really do
not want to duplicate/ignore the content of web.xml and I don't want to use a
different solution to the other deployment descripts.

cheers

Re: Geronimo Deployment Descriptors

[Greg Wilkins <gr...@mortbay.com>]

Dain,

I think you have to think about our POJO approach to XML parsing
more.  Just because handling multiple descriptors in JB was a nightmare,
does not mean that it needs to be so in G.    One of the good things
about our POJO approach to XML parsing is that the marshalling code
should be able to hide any multiple files or override mechanisms that
we wish to have.


taking your points out of order....

Dain Sundstrom wrote:
 > Greg I think this is a difference in perspective again.  The web.xml
 > file is way better designed the the ejb stuff, and you simply don't have
 > the amount of metadata you get in a persistence engine.

We need an approach that works for all deployment desciptors, simple or
complex, well designed or not.    I don't think we should have a
different approach to each and every deployment descriptor.   So whatever
we do needs to work for ejb-jar.xml, web.xml, application.xml, etc.


 > For web, I bet it feels like over kill to dupe the file to add things,
 > and for web you have more tools.

I'm not worried about overkill.  I'm worried about duplication.
Duplicating content is just *BAD*, no matter how many tools you have to
try to sync the duplication.

Why write a tool to fix duplication if you can avoid the duplication in
the first place.

If you are going to have a tool, then use the tool to write the
the multiple files rather than trying to resolve duplication between
them.

Our XML parsing code should be able to put the multiple files
together into a single POJO structure and implement any
override mechansims that we may want.


 > On the other hand having ejb do the add bits in a
 > separate file model falls apart as you add higher level services like
 > persistence.  Anyway for web, how often do people need a vendor specific
 > extension?  Is this really a concern for you?

You need container specific configuration for all the ejb-ref, resource
references etc. etc.

So what ever approach we take for geronimo-ejb-jar.xml, we should do the same
for geronimo-web.xml



>>  + 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.
> 
> So what?  Sun was the one that remove the ability to extend the files.  
> I think it a much bigger pain to maintain an ejb-jar.xml file and one 
> that has the same structure with just a few bits added.

If you find it a pain, then use a tool to generate the file(s).

Being a pain is not a reason to de-normalize your data.  The files
have the same structure and same "indexing" but they have different
semantic content.


>>  + 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.
> 
> The spec expects custom tools provided by the vendor to configure an 
> application before deployment. We will be writing the tags for XDoclet, 
> so that is taken care of.  As for other tools, we just make the 
> requirement that they are 88 compliant.  From what I understand an 88 
> compliant tool must use the Config beans we write and we simply code our 
> beans to maintain the geronimo config file to match the ejb-jar one the 
> tool will write out.  So I don't think this is a problem for tools.


If tools is the answer to the problem, then tools are just as happy
to write two files rather than one.

We have to have a better reason that it being a bit of a pain to break
every tool out there that currently generates or parses standard deployment
descriptors.

Also it is not just tools.  What if in a multi container project it is
other developers working with weblogic or jboss that are making changes
to the standard descriptors.  How do you automate that their changes
propogate back to the geronimo descriptors?


>> 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.
> 
> -1 That sucked in JB.  

Well I was not too keen on the idea either - just suggesting it as a more
acceptable way to allow a *optional* single file solution.   So I'd prefer
the normal 2 file solution (without duplication or overrides), but will
answer your points below anyway....     don't read on if you think it
is TOTALLY a bad idea (as I probably agree with you).



 > It was a huge pain.  You were always switching
> back an forth between many deployment files.  I think if we find a 
> geronimo-ejb-jar.xml file we don't even go looking for an ejb-jar.xml file.

Which you would be doing anyway if the content was generated/copied.
At least with override you have the option of putting all the content in the
geronimo-ejb-jar.xml and never switching back and forth.


>> In this way, content of the geronimo-ejb-jar.xml is not *duplicating* the
>> ejb-jar.xml, it is *overriding* it.  Which is a subtle but meaningful 
>> difference.
> 
> It just means that you end up searching through files an matching stuff 
> up.  When you get into stuff that has heavy metadata needs like 
> persistence, it becomes a nightmare.

Why a nightmare?  We load the standard descriptor into our descriptor
POJOs. Then we load the container specific descriptor into the same POJOs
then we use them - overide is now handled already and no searching required.
Note that even if we don't allow overrides, the POJOs we use for descriptors
will hide multiple descriptors from us.

There are no nightmares of duplicate content, because the content
is never duplicated - it is overridden (only if the developer wishes it
to be).


>> If developers want to avoid the lifecycle issues, they simply don't 
>> duplicate
>> the content to the geronimo file.
> 
> You can't avoid that when you have things like persistence.  You 
> basically end up redeclaring the entire bean in you persistence metadata 
> because you want to do explicit mappings or special indexing.

You duplicate structure and naming - but you should not duplicate content.


>> If they are not concerned about cross container deployment then they 
>> don't
>> need to generate the standards file.
> 
> They can always back a standard file out of ours by removing everything 
> in out name space.  We will provide a simple style sheet to do this.

That helps in some situations, but not all.   If the standard descriptor
is being generated then they need a tool to apply diffs - style sheets
are not up to this.

>> If they have a standard file supplied by a third party, they can deploy
>> on geronimo and change specific content without changing the original 
>> file
>> (and thus allowing simple updates from the third party).
> 
> 
> That is a nightmare... go pick through the descrptiors in the JB test 
> suite... I have been to several sites where these the JB separate file 
> thing was a huge problem.  Also every site I went to that was targeting 
> several containers used XDoclet to do it.

I totally agree that the descriptors are not nice.

But duplicating data and making it difficult for 3rd party tools
is only going to make it worse.

If you are using XDoclet or similar, then it is not relevant that
the files are ugly or a pain to deal with.



cheers

RE: Geronimo Deployment Descriptors

[Jeremy Boynes <je...@coredevelopers.net>]

> > Are there any spec requirements that must be considered?
>
>
> Jeremy and I could not agree if there were or not :-)
>
> I think that it is agains the spirit (if not the letter) of the
> spec to ignore the contents of a standard DD just because of the
> presence of a vendor DD.
>
> Jeremy thinks that it is not, as he sees the generation of the
> vendor DD as being part of the deployment step.
>
> But if we do go with Jeremies model, we have agreed that the
> standard DD must at least be check for consistency with the
> geronimo DD - so it will not be ignored.
>

To clarify, I think the spec defines deployment as the process of taking a
generic (vendor-neutral) assembled application and getting it to run on a
platform. The [J2EE] spec sub-divides this into three tasks: Installation,
Configuration and Execution [pp 17]; the Deployment spec [88] keeps the same
concepts in a different order: Configuration, Distribution and Start [pp 8].
This latter makes more sense in a clustered environment.

I believe that the Deployment Descriptors are the standardized input to the
Configuration process. The specification does not define what a platform's
configuration data looks like, allowing solutions such as WebLogic's where
is it stored in the archive as XML files, or solutions such as WebSphere's
where it is stored in a configuration repository.

There is no requirement for the platform to read the deployment descriptor
itself at runtime; a platform may choose to do so (especially if that is the
sole location for configuration information, e.g. BEA or JBoss) but it is
not required.

This allows us, if we wish, to pre-compile the configuration information
into other forms. For example, it could be an archive of serialized MBean
states that can simply be unmarshalled by the server and started. This has
many potential advantages, such as reducing the startup time for very large
applications or reducing the resources required for an embedded server.

--
Jeremy

Re: Geronimo Deployment Descriptors

[Aaron Mulder <am...@alumni.princeton.edu>]

	FYI, JSR-88 requires that a tool be able to save and load its
server-specific deployment information to a file separate from the
packaged module.  Now, when it comes time to actually deploy, it's given
access to the module (as a File or InputStream), so it could dynamically
unpack the module, overwrite the standard DD, and repack the module, but
it seems like a bit of a hack.

	One of the consequences of this that I haven't given much thought
to is that we need some format where we can store all the server-specific
deployment information for an EAR and all the modules in it to a single
save file.  Then we'd also need to either have a deployment mechanism
accepting an EAR and a Map (presumably) of DDs, or we'd need to repack the
whole thing anyway.  I'd still prefer to avoid the repacking, if for no
other reasons than it won't perform well and we don't have a very good
solution for using disk space from our JSR-88 plugin.

	On the other hand, I guess there's no reason why we couldn't
conceptually say the server-specific content goes in the standard DD, but
when we deploy through JSR-88 we ignore the standard DD and treat our
external copy as the true standard DD.  But I think this pretty much
reduces to what Jeremy is advocating, since the files are actually going
to be different, regardless of whther we think of them as having the same
name or not.

Aaron

On Mon, 8 Sep 2003, James Strachan wrote:
> Quick question. While the J2EE specs might be moving away from the 
> 'embedding namespaced-extensions inside the standard XML descriptors' - 
> is there anything in the spec anywhere which says a container cannot 
> support it? i.e. could one of our options be to use our deployment 
> extensions inside the standard deployment descriptors. This would avoid 
> some of Gregs concerns - we can just use web.xml and ejb-jar.xml with 
> our extensions inside it.
> 
> There seems to be a few different ways of skinning this particular cat 
> and it seems to depend on your exact usage patterns. For developers 
> wishing to target many different containers for a single deployment 
> unit then making a standard deployment descriptor + extra container 
> specific files seems the best approach. In this model a tool like 
> XDoclet would probably be used and so the fact that duplicate stuff 
> occurs in geronimo-ejb-jar.xml and ejb-jar.xml probably wouldn't be 
> that much of an issue.
> 
> Another class of users could be those targeting just Geronimo - where 
> they have no main need to also support other containers - in which case 
> they may prefer to embed the Geronimo extensions directly inside 
> web.xml or ejb-jar.xml etc.
> 
> The other option is Jeremy's approach, where the standard deployment 
> descriptors remain completely clean & so guaranteed to work on any 
> container - and the geronimo-*.xml overload them.
> 
> I can see all these approaches having value to users; so having a way 
> for folks to configure Geronimo to suit their needs sounds like a good 
> idea.
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 

Re: Geronimo Deployment Descriptors

[James Strachan <ja...@yahoo.co.uk>]

On Monday, September 8, 2003, at 11:30  am, Greg Wilkins wrote:
> Geir Magnusson Jr. wrote:
>> On Monday, September 8, 2003, at 02:36 AM, Greg Wilkins wrote:
>>>>
>> [SNIP]
>>>
>>> But I don't want that to stop discussion while the code is being 
>>> written.
>>> I think what is best for web is bad for ejb and what is best for ejb 
>>> is bad
>>> for web - so Jeremy and I are a little entrenched in our view points 
>>> - and
>>> would appreciated input from others.
>>>
>> Are there any spec requirements that must be considered?
>
>
> Jeremy and I could not agree if there were or not :-)
>
> I think that it is agains the spirit (if not the letter) of the
> spec to ignore the contents of a standard DD just because of the
> presence of a vendor DD.
>
> Jeremy thinks that it is not, as he sees the generation of the
> vendor DD as being part of the deployment step.
>
> But if we do go with Jeremies model, we have agreed that the
> standard DD must at least be check for consistency with the
> geronimo DD - so it will not be ignored.


Quick question. While the J2EE specs might be moving away from the 
'embedding namespaced-extensions inside the standard XML descriptors' - 
is there anything in the spec anywhere which says a container cannot 
support it? i.e. could one of our options be to use our deployment 
extensions inside the standard deployment descriptors. This would avoid 
some of Gregs concerns - we can just use web.xml and ejb-jar.xml with 
our extensions inside it.

There seems to be a few different ways of skinning this particular cat 
and it seems to depend on your exact usage patterns. For developers 
wishing to target many different containers for a single deployment 
unit then making a standard deployment descriptor + extra container 
specific files seems the best approach. In this model a tool like 
XDoclet would probably be used and so the fact that duplicate stuff 
occurs in geronimo-ejb-jar.xml and ejb-jar.xml probably wouldn't be 
that much of an issue.

Another class of users could be those targeting just Geronimo - where 
they have no main need to also support other containers - in which case 
they may prefer to embed the Geronimo extensions directly inside 
web.xml or ejb-jar.xml etc.

The other option is Jeremy's approach, where the standard deployment 
descriptors remain completely clean & so guaranteed to work on any 
container - and the geronimo-*.xml overload them.

I can see all these approaches having value to users; so having a way 
for folks to configure Geronimo to suit their needs sounds like a good 
idea.

James
-------
http://radio.weblogs.com/0112098/

Re: Geronimo Deployment Descriptors

[Greg Wilkins <gr...@mortbay.com>]

Geir Magnusson Jr. wrote:
> 
> On Monday, September 8, 2003, at 02:36 AM, Greg Wilkins wrote:
> 
>>>
> 
> [SNIP]
> 
>>
>> But I don't want that to stop discussion while the code is being written.
>> I think what is best for web is bad for ejb and what is best for ejb 
>> is bad
>> for web - so Jeremy and I are a little entrenched in our view points - 
>> and
>> would appreciated input from others.
>>
> 
> Are there any spec requirements that must be considered?


Jeremy and I could not agree if there were or not :-)

I think that it is agains the spirit (if not the letter) of the
spec to ignore the contents of a standard DD just because of the
presence of a vendor DD.

Jeremy thinks that it is not, as he sees the generation of the
vendor DD as being part of the deployment step.

But if we do go with Jeremies model, we have agreed that the
standard DD must at least be check for consistency with the
geronimo DD - so it will not be ignored.

cheers

Re: Geronimo Deployment Descriptors

["Geir Magnusson Jr." <ge...@adeptra.com>]

On Monday, September 8, 2003, at 02:36 AM, Greg Wilkins wrote:

>>

[SNIP]

>
> But I don't want that to stop discussion while the code is being 
> written.
> I think what is best for web is bad for ejb and what is best for ejb 
> is bad
> for web - so Jeremy and I are a little entrenched in our view points - 
> and
> would appreciated input from others.
>

Are there any spec requirements that must be considered?

-- 
Geir Magnusson Jr                                   203-956-2604(w)
Adeptra, Inc.                                       203-434-2093(m)
geirm@adeptra.com                                   203-247-1713(m)

Re: Geronimo Deployment Descriptors

[Greg Wilkins <gr...@mortbay.com>]

Jeremy,

a good summary of a very long conversation.  Just a few small differences
I'd put at the end....

Jeremy Boynes wrote:
> Greg and I ended up having a very long IM discussion on the subject. We
> did not reach agreement on a solution, but we did come up with a plan to
> proceed.
> 
> Firstly, a couple of things we did reach agreement on.
> 
> A lot of the usage problem here comes from a difference in where the
> majority of changes happen between the web and ejb tiers. For a web
> container configuration, most of the changes happen in the standard
> deployment information (for example, adding servlets or filters,
> changing security constraints) and the vendor deployment information is
> fairly static. In an EJB configuration, there tend to be a lot more
> changes to the vendor deployment information, especially with CMP.
> 
> This tends to encourage people in the EJB tier to generate their
> deployment descriptors using tools like XDoclet rather than editing them
> by hand. If people do that, then the true source becomes the meta-tags
> and which approach we use becomes fairly irrelevant.
> 
> The trend is toward tools, especially with JSR88 on the horizon and when
> that gets here which approach we use is again irrelevant. However, that
> utopian solution is not with us now.
> 
> Finally, the current POJO model (where the Geronimo POJOs specialize the
> standard ones leading to a unified data mode) is a good idea and will
> remain.
> 
> 
> With the new approach, the biggest problem is the duplication of
> configuration data between the standard and geronimo descriptors. This
> is especially true for the web layer where the majority of changes occur
> to the standard descriptor, often by IDEs, and may not be reflected in
> the geronimo configuration (leading to a consistency problem).
> 
> With the traditional approach, the biggest problem is the separation of
> data into different files with the need to keep the structure in sync
> between them. This is especially true for CMP EJBs where changes often
> need to be made in two or three files, with the potential for
> inconsistencies between them.
> 
> 
> To address these issues, we have the following plan:
> Firstly, we will implement a loader for the web POJOs Aaron just defined
> that represent the standard web.xml data model. We need this regardless.
> 
> We will also generate an XML Schema definition for geronimo-web.xml that
> uses the new approach (this is fairly easy given as most of the
> extensions are already in geronimo-j2ee.xml).
> 
> We will then implement a loader for a new-style combined DD as utilities
> already exist for the extended J2EE schema (GeronimoJ2EELoader), making
> this a trivial specialization of the one above.
> 
> To solve the consistency problem with the new approach, we will
> implement a consistency checker that verifies that the two documents are
> in sync.
> 
> To solve the structure sync problem with the old approach, we will
> implement a fuzzy match algorithm that will build up the unified POJO
> model by combining information from multiple files. If necessary, we
> will also implement a tool that allows changes to the standard DD to be
> propogated to the vendor DDs (keeping the structures in sync).

I also proposed that once we have the a mechanism to build the POJOs out
of multiple files, that I would removed the duplicated elements from
the geronimo-web.xml file so that duplicate content would not be supported.

So we would have ejb's implementing the single file model and the web tier
implementing the distinct multiple file model, but with an infrastructure
that could support the merged multiple file model.

> This will provide us with a framework in which to discuss the merits of
> the different solutions.

But I don't want that to stop discussion while the code is being written.
I think what is best for web is bad for ejb and what is best for ejb is bad
for web - so Jeremy and I are a little entrenched in our view points - and
would appreciated input from others.

cheers


> --
> Jeremy
> 
> 

RE: Geronimo Deployment Descriptors

[Jeremy Boynes <je...@coredevelopers.net>]

Greg and I ended up having a very long IM discussion on the subject. We
did not reach agreement on a solution, but we did come up with a plan to
proceed.

Firstly, a couple of things we did reach agreement on.

A lot of the usage problem here comes from a difference in where the
majority of changes happen between the web and ejb tiers. For a web
container configuration, most of the changes happen in the standard
deployment information (for example, adding servlets or filters,
changing security constraints) and the vendor deployment information is
fairly static. In an EJB configuration, there tend to be a lot more
changes to the vendor deployment information, especially with CMP.

This tends to encourage people in the EJB tier to generate their
deployment descriptors using tools like XDoclet rather than editing them
by hand. If people do that, then the true source becomes the meta-tags
and which approach we use becomes fairly irrelevant.

The trend is toward tools, especially with JSR88 on the horizon and when
that gets here which approach we use is again irrelevant. However, that
utopian solution is not with us now.

Finally, the current POJO model (where the Geronimo POJOs specialize the
standard ones leading to a unified data mode) is a good idea and will
remain.


With the new approach, the biggest problem is the duplication of
configuration data between the standard and geronimo descriptors. This
is especially true for the web layer where the majority of changes occur
to the standard descriptor, often by IDEs, and may not be reflected in
the geronimo configuration (leading to a consistency problem).

With the traditional approach, the biggest problem is the separation of
data into different files with the need to keep the structure in sync
between them. This is especially true for CMP EJBs where changes often
need to be made in two or three files, with the potential for
inconsistencies between them.


To address these issues, we have the following plan:
Firstly, we will implement a loader for the web POJOs Aaron just defined
that represent the standard web.xml data model. We need this regardless.

We will also generate an XML Schema definition for geronimo-web.xml that
uses the new approach (this is fairly easy given as most of the
extensions are already in geronimo-j2ee.xml).

We will then implement a loader for a new-style combined DD as utilities
already exist for the extended J2EE schema (GeronimoJ2EELoader), making
this a trivial specialization of the one above.

To solve the consistency problem with the new approach, we will
implement a consistency checker that verifies that the two documents are
in sync.

To solve the structure sync problem with the old approach, we will
implement a fuzzy match algorithm that will build up the unified POJO
model by combining information from multiple files. If necessary, we
will also implement a tool that allows changes to the standard DD to be
propogated to the vendor DDs (keeping the structures in sync).

This will provide us with a framework in which to discuss the merits of
the different solutions.

--
Jeremy

Re: Geronimo Deployment Descriptors

[Greg Wilkins <gr...@mortbay.com>]

Jeremy Boynes wrote:

> Why not try it out?

Because I have a fundamental disagreement with the approach.
Duplication and ignoring the standard descriptors is bad.
This is a strong felt concern, and I would need to see a lot more
support for your approach before I put this concern aside.

I'm also dubious if ignoring the standards descriptor is the right thing
to do when it comes to certification time.  It probably will pass the
test suite in practise, but not in spirit.

Also because I want all deployment descriptors to work the same
way and I don't want to start writing code to duplicate the content
of web.xml.


 >>Would it be possible to change the descriptor loading code so
 >>that when it needs load a GeronimoEjbJarDocument it:
 >>
 >>  1) loads ejb-jar.xml into a GeronimoEjbJarDocument
 >>  2) loads geronimo-ejb-jar.xml on top of the Document loaded from 1)
 >>
 > The problem is conflict resolution and validation (my example on
 > conflicting views). If we can solve both of those then this might work.

OK then remove the standard elements for the geronimo-ejb-jar.xsd and
we have no more conflict problems.    Validation is still somewhat of
an issue, as we need to ensure that items described in the geronimo descriptor
are included in the standards descriptor, but that is not a difficult validation
to perform over the pojos once they are built in memory.

Besides, it must be solvable problem - as all other containers use
the standard + container style of deployment descriptors.

As Aaron and I have both suggested, I think having a unified POJO model
in memory is good - but that the model should be loaded/saved from multiple
files for standard + container.

cheers

RE: Geronimo Deployment Descriptors

[Jeremy Boynes <je...@coredevelopers.net>]

> From: news [mailto:news@sea.gmane.org] On Behalf Of Greg Wilkins
> Would it be possible to change the descriptor loading code so 
> that when it needs load a GeronimoEjbJarDocument it:
> 
>   1) loads ejb-jar.xml into a GeronimoEjbJarDocument
>   2) loads geronimo-ejb-jar.xml on top of the Document loaded from 1)
> 

The problem is conflict resolution and validation (my example on
conflicting views). If we can solve both of those then this might work.

Why not try it out?

--
Jeremy

Re: Geronimo Deployment Descriptors

[Greg Wilkins <gr...@mortbay.com>]

Jeremy Boynes wrote:

> Then let's do that :-) 
> 
> But let's not stop dead in the water while we debate.

Would it be possible to change the descriptor loading code so that
when it needs load a GeronimoEjbJarDocument it:

  1) loads ejb-jar.xml into a GeronimoEjbJarDocument
  2) loads geronimo-ejb-jar.xml on top of the Document loaded from 1)

We could then remove the standard elements from
   modules/core/src/schema/geronimo-ejb-jar.xsd
to get the traditional two file approach, or leave them in to get
the override behaviour I have previously suggested (but don't like too much).
We could even make step 1) optional if you wanted your behavior as an
option.

This should be able to be done abstractly so that we have the same double
load behaviour of all xxx.xml and geronimo-xxx.xml descriptors.

Thus we can write code while we debate - the webcontainer will not be
stopped dead because ejb descriptor solution is not appropriate for it - and
once the debate is complete it will be simple to change the behaviour for
all descriptors to what is agreed.

cheers

Re: Geronimo Deployment Descriptors

[Greg Wilkins <gr...@mortbay.com>]

Jeremy Boynes wrote:

> Then let's do that :-) 
> 
> But let's not stop dead in the water while we debate.

Would it be possible to change the descriptor loading code so that
when it needs load a GeronimoEjbJarDocument it:

  1) loads ejb-jar.xml into a GeronimoEjbJarDocument
  2) loads geronimo-ejb-jar.xml on top of the Document loaded from 1)

We could then remove the standard elements from
   modules/core/src/schema/geronimo-ejb-jar.xsd
to get the traditional two file approach, or leave them in to get
the override behaviour I have previously suggested (but don't like too much).
We could even make step 1) optional if you wanted your behavior as an
option.

This should be able to be done abstractly so that we have the same double
load behaviour of all xxx.xml and geronimo-xxx.xml descriptors.

Thus we can write code while we debate - the webcontainer will not be
stopped dead because ejb descriptor solution is not appropriate for it - and
once the debate is complete it will be simple to change the behaviour for
all descriptors to what is agreed.

cheers

RE: Geronimo Deployment Descriptors

[Jeremy Boynes <je...@coredevelopers.net>]

> From: Aaron Mulder [mailto:ammulder@alumni.princeton.edu] 
> 	I disagree - I don't think you should "win by default" 
> by putting 
> something in the repository first.
> 

It is not a case of 'winning' - its about getting stuff to work. If
there had been something there I would have checked this into a
revolutionary branch; because there wasn't I checked it into HEAD. We
now get to discuss around something concrete and people depending on the
ENC (like Hiram and I who are trying to get IIOP working) can move on.


> > Applying that code would not get us to where we are now. It had 
> > loaders for the two different models, but nothing for 
> matching them up 
> > and getting the data into a form where something like the 
> > ComponentContextBuilder could work on it. It was trying to add that 
> > stuff that made change approach.
> 
> 	Yeah, but the JSR-88 code doesn't work for the new approach.  
> You've just broken something *different*.  (Plus, as I point 
> out below, 
> you left the EJB POJOs working "the old way".)
> 
> > If you want to pursue that as an alternative, perhaps in 
> conjunction 
> > with Greg's proposal for overlays, that would be cool.
> 
> 	Well, are you going to fix the JSR-88 implementation?  
> I mean, right now if you try to save Geronimo-specific 
> customizations to an EJB JAR, it writes the Geronimo stuff 
> only, producing a tree of POJOs from 
> o.a.g.deployment.model.ejb, which if you look, doesn't even 
> include the stuff from ejb-jar.xml (i.e. an "Ejb" doesn't 
> have an "ejb-class" field, home & component interaces, etc.).
> 
> 	Bottom line, it doesn't look to me like the "new 
> approach" is any more working than the old one!

I guess it depends on where your focus is. The stuff I was doing with
AppClient was stalled because I did not have a way to load the ENC from
the DD - now I can so I am happy :-)

Nothing in the code I checked in deals with writing XML. As I understand
it, that is going to be handled at some point using XMLBeans. I have no
idea where we are on that, except it is a different approach to what is
there right now.

> 
> > But let's not stop dead in the water while we debate.
> 
> 	Okay.  Well, I put my thoughts on it out in an e-mail this 
> morning (9:24), and I don't think you've replied to that yet...  In 
> particular, what if we keep the files separate, but keep your 
> proposed 
> changes to the POJO structure, and something yet to be 
> written does the 
> combining of multiple files into a single POJO tree, so the 
> file format 
> is transparent to the ComponentContextBuilder?

There are two aspects to this:
1) The POJO structure - I changed the geronimo ones to specialize the
   standard ones (as they add in additional information). I think that
is 
   a useful change because it separates the in-memory form from the
   XML form.

2) The XML form. It was much easier to build an XML loader for a
   unified document as it does not need to worry about matching
   nodes. If we want to split into two and introduce the code
   for matching up the documents, we can.

These issues were discussed in both your and Greg's emails and I thought
my response covered both; sorry if I missed something.

I think an alternative XML form can be tried out without changing the
POJO structure. When it works, we have two solutions to compare side by
side and can have a vote on the approach.

--
Jeremy

RE: Geronimo Deployment Descriptors

[Aaron Mulder <am...@alumni.princeton.edu>]

On Sun, 7 Sep 2003, Jeremy Boynes wrote:
> I didn't call for a vote, just feedback on the approach.

	Fair enough.

> I also think its wrong to veto a change without having an alternative
> available - if I was changing something that already worked it would be
> different, but we didn't have anything.

	I disagree - I don't think you should "win by default" by putting 
something in the repository first.

> Applying that code would not get us to where we are now. It had loaders
> for the two different models, but nothing for matching them up and
> getting the data into a form where something like the
> ComponentContextBuilder could work on it. It was trying to add that
> stuff that made change approach.

	Yeah, but the JSR-88 code doesn't work for the new approach.  
You've just broken something *different*.  (Plus, as I point out below, 
you left the EJB POJOs working "the old way".)

> If you want to pursue that as an alternative, perhaps in conjunction
> with Greg's proposal for overlays, that would be cool.

	Well, are you going to fix the JSR-88 implementation?  I mean,
right now if you try to save Geronimo-specific customizations to an EJB
JAR, it writes the Geronimo stuff only, producing a tree of POJOs from
o.a.g.deployment.model.ejb, which if you look, doesn't even include the
stuff from ejb-jar.xml (i.e. an "Ejb" doesn't have an "ejb-class" field,
home & component interaces, etc.).

	Bottom line, it doesn't look to me like the "new approach" is any
more working than the old one!

> But let's not stop dead in the water while we debate.

	Okay.  Well, I put my thoughts on it out in an e-mail this 
morning (9:24), and I don't think you've replied to that yet...  In 
particular, what if we keep the files separate, but keep your proposed 
changes to the POJO structure, and something yet to be written does the 
combining of multiple files into a single POJO tree, so the file format 
is transparent to the ComponentContextBuilder?

Aaron

RE: Geronimo Deployment Descriptors

[Jeremy Boynes <je...@coredevelopers.net>]

> From: Aaron Mulder [mailto:ammulder@alumni.princeton.edu] 
> On Sun, 7 Sep 2003, Jeremy Boynes wrote:
> > 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.
> 
> 	Regardless of the technical merits, I think it's 
> procedurally wrong to call for a (vetoable) vote, get vetoed, 
> and then claim that in effect the vetos don't count because 
> you've already committed the code.  
> Until the -1s are retracted, I think we have to assume that 
> the code should be removed, right?
> 

I didn't call for a vote, just feedback on the approach. I also think
its wrong to veto a change without having an alternative available - if
I was changing something that already worked it would be different, but
we didn't have anything.

> 	I'm also a bit confused as to why you don't think 
> there's an alternative -- if you apply the code I sent 
> originally (we could piece the loader back together from JIRA 
> 67 & 68, the EJB POJOs haven't changed, and the J2EE POJOs 
> would be simple enough to restore), you get a Geronimo EJB DD 
> that's separate from the J2EE EJB DD.  I could send another patch if 
> that would be helpful.
> 

Applying that code would not get us to where we are now. It had loaders
for the two different models, but nothing for matching them up and
getting the data into a form where something like the
ComponentContextBuilder could work on it. It was trying to add that
stuff that made change approach.

If you want to pursue that as an alternative, perhaps in conjunction
with Greg's proposal for overlays, that would be cool.

> 	On the technical merits, my preference would be to 
> pursue this conversation a little longer (now) and resolve 
> the issue and put it behind us.
> 

Then let's do that :-) 

But let's not stop dead in the water while we debate.

--
Jeremy

RE: Geronimo Deployment Descriptors

[Aaron Mulder <am...@alumni.princeton.edu>]

On Sun, 7 Sep 2003, Jeremy Boynes wrote:
> 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.

	Regardless of the technical merits, I think it's procedurally
wrong to call for a (vetoable) vote, get vetoed, and then claim that in
effect the vetos don't count because you've already committed the code.  
Until the -1s are retracted, I think we have to assume that the code
should be removed, right?

	I'm also a bit confused as to why you don't think there's an
alternative -- if you apply the code I sent originally (we could piece the
loader back together from JIRA 67 & 68, the EJB POJOs haven't changed, and
the J2EE POJOs would be simple enough to restore), you get a Geronimo EJB
DD that's separate from the J2EE EJB DD.  I could send another patch if 
that would be helpful.

	On the technical merits, my preference would be to pursue this
conversation a little longer (now) and resolve the issue and put it behind
us.

Aaron

RE: Geronimo Deployment Descriptors

[Jeremy Boynes <je...@coredevelopers.net>]

> 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

Re: Geronimo Deployment Descriptors

[Dain Sundstrom <da...@coredevelopers.net>]

On Sunday, September 7, 2003, at 01:39 AM, Greg Wilkins wrote:

> 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.

So what?  Sun was the one that remove the ability to extend the files.  
I think it a much bigger pain to maintain an ejb-jar.xml file and one 
that has the same structure with just a few bits added.

>  + 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.

The spec expects custom tools provided by the vendor to configure an 
application before deployment. We will be writing the tags for XDoclet, 
so that is taken care of.  As for other tools, we just make the 
requirement that they are 88 compliant.  From what I understand an 88 
compliant tool must use the Config beans we write and we simply code 
our beans to maintain the geronimo config file to match the ejb-jar one 
the tool will write out.  So I don't think this is a problem for tools.

> 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.

-1 That sucked in JB.  It was a huge pain.  You were always switching 
back an forth between many deployment files.  I think if we find a 
geronimo-ejb-jar.xml file we don't even go looking for an ejb-jar.xml 
file.

> In this way, content of the geronimo-ejb-jar.xml is not *duplicating* 
> the
> ejb-jar.xml, it is *overriding* it.  Which is a subtle but meaningful 
> difference.

It just means that you end up searching through files an matching stuff 
up.  When you get into stuff that has heavy metadata needs like 
persistence, it becomes a nightmare.

> If developers want to avoid the lifecycle issues, they simply don't 
> duplicate
> the content to the geronimo file.

You can't avoid that when you have things like persistence.  You 
basically end up redeclaring the entire bean in you persistence 
metadata because you want to do explicit mappings or special indexing.

> If they are not concerned about cross container deployment then they 
> don't
> need to generate the standards file.

They can always back a standard file out of ours by removing everything 
in out name space.  We will provide a simple style sheet to do this.

> If they have a standard file supplied by a third party, they can deploy
> on geronimo and change specific content without changing the original 
> file
> (and thus allowing simple updates from the third party).

That is a nightmare... go pick through the descrptiors in the JB test 
suite... I have been to several sites where these the JB separate file 
thing was a huge problem.  Also every site I went to that was targeting 
several containers used XDoclet to do it.

> I have often wanted this in web.xml, where I can override initparams
> without editing the original web.xml (and losing them when I update the
> software).

Greg I think this is a difference in perspective again.  The web.xml 
file is way better designed the the ejb stuff, and you simply don't 
have the amount of metadata you get in a persistence engine.  For web, 
I bet it feels like over kill to dupe the file to add things, and for 
web you have more tools. On the other hand having ejb do the add bits 
in a separate file model falls apart as you add higher level services 
like persistence.  Anyway for web, how often do people need a vendor 
specific extension?  Is this really a concern for you?

-dain

Re: Geronimo Deployment Descriptors

[Greg Wilkins <gr...@mortbay.com>]

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.

  + 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.

In this way, content of the geronimo-ejb-jar.xml is not *duplicating* the
ejb-jar.xml, it is *overriding* it.  Which is a subtle but meaningful difference.

If developers want to avoid the lifecycle issues, they simply don't duplicate
the content to the geronimo file.

If they are not concerned about cross container deployment then they don't
need to generate the standards file.

If they have a standard file supplied by a third party, they can deploy
on geronimo and change specific content without changing the original file
(and thus allowing simple updates from the third party).

I have often wanted this in web.xml, where I can override initparams
without editing the original web.xml (and losing them when I update the
software).



Dain Sundstrom wrote:
> That is not what Jeremy did.  He has extended the j2ee schema using the 
> xml extension system.  If the spec committee did not want the schemas 
> extended they would have marked them as final.  So we have our own 
> schema the extends the j2ee one and allows for our tags to be added.
> 
> Also note he wrote that out files our files would have a different 
> name.  For example, ejb-jar.xml would be named geronimo-ejb-jar.xml.  If 
> the user had the geronimo file, that is what we would use to deploy, if 
> they only had an ejb-jar.xml file then they would get a default 
> deployment.  Basically this is the same thing as what JB does, except 
> instead of having a weird 2 file thing we put everything in a single 
> consistent descriptor.
> 
> -dain
> 
> On Saturday, September 6, 2003, at 08:26 PM, Greg Wilkins wrote:
> 
>> -1
>>
>> I understand that the single file nature of this approach is considered
>> attractive.  JSR154 was considering supporting such descriptor extensions
>> as part of the spec.  However, this was removed from the spec and the
>> feeling is that the J2EE jsrs will no longer favour such descriptor 
>> extensions
>> (as was once going to be the case for all j2ee 1.4 descriptors).
>>
>> The problems listed included:
>>
>>  + difficulties in file lifecycles for tools that generate descriptors.
>>    Anything that does not know about geronimo would probably constantly
>>    overwrite any geronimo specific elements.
>>
>>  + Difficulties in maintaining multi container deployment.  Change 
>> control
>>    and generation of container specific configuration will be 
>> difficult if
>>    multiple tools want to add container specific information into the
>>    standards descriptors.
>>
>>
>>
>> Jeremy Boynes wrote:
>>
>>> I have recently checked in a XML Schema for a couple of
>>> Geronimo-specific deployment descriptors. These rely on namespaces to
>>> allow vendor-specific elements to be included in standard deployment
>>> descriptors.
>>> For example, an ejb-ref would be defined as:
>>>     <ejb-ref>
>>>         <ejb-ref-name>ejb/MyEJB</ejb-ref-name>
>>>         <ejb-ref-type>Session</ejb-ref-type>
>>>         <home>my.EJB.Home</home>
>>>         <remote>my.EJB.Remote</remote>
>>>         <ger:jndi-name>TestEJB</ger:jndi-name>
>>>     </ejb-ref>
>>> where ger: is the prefix for the Geronimo namespace.
>>> The way this is intended to work is that the deployer will copy the
>>> standard deployment descriptor file to the Geronimo one and then add in
>>> out entries. If a geronimo descriptor exists, we will not use the
>>> standard one at all so developers will be able to work exclusively with
>>> the geronimo version. We will provide a tool for generating a standard
>>> descriptor by stripping out all geronimo-specific elements.
>>> This is working for the application-client descriptor and we will be
>>> building out the EJB one once we know what the container-specific
>>> elements actually are.
>>> This is a little different from the old-style form of vendor descriptors
>>> (e.g. as used by Weblogic or JBoss) where they were separate documents
>>> that contained just supplemental information. In light of this, I would
>>> appreciate feedback on the approach before we get too far along.
>>> -- 
>>> Jeremy
>>
>>
>>
>>
>>
> 
> /*************************
>  * Dain Sundstrom
>  * Partner
>  * Core Developers Network
>  *************************/
> 
> 

Re: Geronimo Deployment Descriptors

[Dain Sundstrom <da...@coredevelopers.net>]

We don't have problems with third party tools.  They must use our 
config beans... it is required by JSR 88.

-dain

On Sunday, September 7, 2003, at 05:41 AM, Jason Dillon wrote:

> Is the spec leaning towards using namespaces to handle this ?  if it 
> is then we should impl this way, otherwise we are just asking for 
> trouble with 3rd deployment tools and shit.  Personally I like using 
> namespaces though, makes more sense IMO.
>
> --jason
>
>
> On Sunday, September 7, 2003, at 05:20  PM, Emerson Cargnin wrote:
>
>> -1. I think that changing the default thinking of ejb-jar.xml for
>> non-specific server config. and server-name-ejb-jar.xml for specific
>> deploying settings is a bad thing. Good or bad this is a pattern that 
>> is
>> going on for a while in J2EE, why changing it? Let ejb-jar.xml be the
>> default one, and geronimo-ejb-jar.xml be our specific server 
>> configuration
>> file. IMHO.
>>
>> Emerson Cargnin
>>
>> ----- Original Message -----
>> From: "Dain Sundstrom" <da...@coredevelopers.net>
>> To: <ge...@incubator.apache.org>
>> Sent: Saturday, September 06, 2003 10:50 PM
>> Subject: Re: Geronimo Deployment Descriptors
>>
>>
>>> That is not what Jeremy did.  He has extended the j2ee schema using 
>>> the
>>> xml extension system.  If the spec committee did not want the schemas
>>> extended they would have marked them as final.  So we have our own
>>> schema the extends the j2ee one and allows for our tags to be added.
>>>
>>> Also note he wrote that out files our files would have a different
>>> name.  For example, ejb-jar.xml would be named geronimo-ejb-jar.xml.
>>> If the user had the geronimo file, that is what we would use to 
>>> deploy,
>>> if they only had an ejb-jar.xml file then they would get a default
>>> deployment.  Basically this is the same thing as what JB does, except
>>> instead of having a weird 2 file thing we put everything in a single
>>> consistent descriptor.
>>>
>>> -dain
>>>
>>> On Saturday, September 6, 2003, at 08:26 PM, Greg Wilkins wrote:
>>>
>>>> -1
>>>>
>>>> I understand that the single file nature of this approach is 
>>>> considered
>>>> attractive.  JSR154 was considering supporting such descriptor
>>>> extensions
>>>> as part of the spec.  However, this was removed from the spec and 
>>>> the
>>>> feeling is that the J2EE jsrs will no longer favour such descriptor
>>>> extensions
>>>> (as was once going to be the case for all j2ee 1.4 descriptors).
>>>>
>>>> The problems listed included:
>>>>
>>>>  + difficulties in file lifecycles for tools that generate 
>>>> descriptors.
>>>>    Anything that does not know about geronimo would probably 
>>>> constantly
>>>>    overwrite any geronimo specific elements.
>>>>
>>>>  + Difficulties in maintaining multi container deployment.  Change
>>>> control
>>>>    and generation of container specific configuration will be
>>>> difficult if
>>>>    multiple tools want to add container specific information into 
>>>> the
>>>>    standards descriptors.
>>>>
>>>>
>>>>
>>>> Jeremy Boynes wrote:
>>>>> I have recently checked in a XML Schema for a couple of
>>>>> Geronimo-specific deployment descriptors. These rely on namespaces 
>>>>> to
>>>>> allow vendor-specific elements to be included in standard 
>>>>> deployment
>>>>> descriptors.
>>>>> For example, an ejb-ref would be defined as:
>>>>>     <ejb-ref>
>>>>>         <ejb-ref-name>ejb/MyEJB</ejb-ref-name>
>>>>>         <ejb-ref-type>Session</ejb-ref-type>
>>>>>         <home>my.EJB.Home</home>
>>>>>         <remote>my.EJB.Remote</remote>
>>>>>         <ger:jndi-name>TestEJB</ger:jndi-name>
>>>>>     </ejb-ref>
>>>>> where ger: is the prefix for the Geronimo namespace.
>>>>> The way this is intended to work is that the deployer will copy the
>>>>> standard deployment descriptor file to the Geronimo one and then 
>>>>> add
>>>>> in
>>>>> out entries. If a geronimo descriptor exists, we will not use the
>>>>> standard one at all so developers will be able to work exclusively
>>>>> with
>>>>> the geronimo version. We will provide a tool for generating a 
>>>>> standard
>>>>> descriptor by stripping out all geronimo-specific elements.
>>>>> This is working for the application-client descriptor and we will 
>>>>> be
>>>>> building out the EJB one once we know what the container-specific
>>>>> elements actually are.
>>>>> This is a little different from the old-style form of vendor
>>>>> descriptors
>>>>> (e.g. as used by Weblogic or JBoss) where they were separate 
>>>>> documents
>>>>> that contained just supplemental information. In light of this, I
>>>>> would
>>>>> appreciate feedback on the approach before we get too far along.
>>>>> --
>>>>> Jeremy
>>>>
>>>>
>>>>
>>>>
>>>
>>> /*************************
>>>   * Dain Sundstrom
>>>   * Partner
>>>   * Core Developers Network
>>>   *************************/
>>>
>>
>
>

/*************************
  * Dain Sundstrom
  * Partner
  * Core Developers Network
  *************************/

Re: Geronimo Deployment Descriptors

[Jason Dillon <ja...@coredevelopers.net>]

Is the spec leaning towards using namespaces to handle this ?  if it is 
then we should impl this way, otherwise we are just asking for trouble 
with 3rd deployment tools and shit.  Personally I like using namespaces 
though, makes more sense IMO.

--jason


On Sunday, September 7, 2003, at 05:20  PM, Emerson Cargnin wrote:

> -1. I think that changing the default thinking of ejb-jar.xml for
> non-specific server config. and server-name-ejb-jar.xml for specific
> deploying settings is a bad thing. Good or bad this is a pattern that 
> is
> going on for a while in J2EE, why changing it? Let ejb-jar.xml be the
> default one, and geronimo-ejb-jar.xml be our specific server 
> configuration
> file. IMHO.
>
> Emerson Cargnin
>
> ----- Original Message -----
> From: "Dain Sundstrom" <da...@coredevelopers.net>
> To: <ge...@incubator.apache.org>
> Sent: Saturday, September 06, 2003 10:50 PM
> Subject: Re: Geronimo Deployment Descriptors
>
>
>> That is not what Jeremy did.  He has extended the j2ee schema using 
>> the
>> xml extension system.  If the spec committee did not want the schemas
>> extended they would have marked them as final.  So we have our own
>> schema the extends the j2ee one and allows for our tags to be added.
>>
>> Also note he wrote that out files our files would have a different
>> name.  For example, ejb-jar.xml would be named geronimo-ejb-jar.xml.
>> If the user had the geronimo file, that is what we would use to 
>> deploy,
>> if they only had an ejb-jar.xml file then they would get a default
>> deployment.  Basically this is the same thing as what JB does, except
>> instead of having a weird 2 file thing we put everything in a single
>> consistent descriptor.
>>
>> -dain
>>
>> On Saturday, September 6, 2003, at 08:26 PM, Greg Wilkins wrote:
>>
>>> -1
>>>
>>> I understand that the single file nature of this approach is 
>>> considered
>>> attractive.  JSR154 was considering supporting such descriptor
>>> extensions
>>> as part of the spec.  However, this was removed from the spec and the
>>> feeling is that the J2EE jsrs will no longer favour such descriptor
>>> extensions
>>> (as was once going to be the case for all j2ee 1.4 descriptors).
>>>
>>> The problems listed included:
>>>
>>>  + difficulties in file lifecycles for tools that generate 
>>> descriptors.
>>>    Anything that does not know about geronimo would probably 
>>> constantly
>>>    overwrite any geronimo specific elements.
>>>
>>>  + Difficulties in maintaining multi container deployment.  Change
>>> control
>>>    and generation of container specific configuration will be
>>> difficult if
>>>    multiple tools want to add container specific information into the
>>>    standards descriptors.
>>>
>>>
>>>
>>> Jeremy Boynes wrote:
>>>> I have recently checked in a XML Schema for a couple of
>>>> Geronimo-specific deployment descriptors. These rely on namespaces 
>>>> to
>>>> allow vendor-specific elements to be included in standard deployment
>>>> descriptors.
>>>> For example, an ejb-ref would be defined as:
>>>>     <ejb-ref>
>>>>         <ejb-ref-name>ejb/MyEJB</ejb-ref-name>
>>>>         <ejb-ref-type>Session</ejb-ref-type>
>>>>         <home>my.EJB.Home</home>
>>>>         <remote>my.EJB.Remote</remote>
>>>>         <ger:jndi-name>TestEJB</ger:jndi-name>
>>>>     </ejb-ref>
>>>> where ger: is the prefix for the Geronimo namespace.
>>>> The way this is intended to work is that the deployer will copy the
>>>> standard deployment descriptor file to the Geronimo one and then add
>>>> in
>>>> out entries. If a geronimo descriptor exists, we will not use the
>>>> standard one at all so developers will be able to work exclusively
>>>> with
>>>> the geronimo version. We will provide a tool for generating a 
>>>> standard
>>>> descriptor by stripping out all geronimo-specific elements.
>>>> This is working for the application-client descriptor and we will be
>>>> building out the EJB one once we know what the container-specific
>>>> elements actually are.
>>>> This is a little different from the old-style form of vendor
>>>> descriptors
>>>> (e.g. as used by Weblogic or JBoss) where they were separate 
>>>> documents
>>>> that contained just supplemental information. In light of this, I
>>>> would
>>>> appreciate feedback on the approach before we get too far along.
>>>> --
>>>> Jeremy
>>>
>>>
>>>
>>>
>>
>> /*************************
>>   * Dain Sundstrom
>>   * Partner
>>   * Core Developers Network
>>   *************************/
>>
>

Re: Geronimo Deployment Descriptors

[Emerson Cargnin <ec...@bol.com.br>]

-1. I think that changing the default thinking of ejb-jar.xml for
non-specific server config. and server-name-ejb-jar.xml for specific
deploying settings is a bad thing. Good or bad this is a pattern that is
going on for a while in J2EE, why changing it? Let ejb-jar.xml be the
default one, and geronimo-ejb-jar.xml be our specific server configuration
file. IMHO.

Emerson Cargnin

----- Original Message -----
From: "Dain Sundstrom" <da...@coredevelopers.net>
To: <ge...@incubator.apache.org>
Sent: Saturday, September 06, 2003 10:50 PM
Subject: Re: Geronimo Deployment Descriptors


> That is not what Jeremy did.  He has extended the j2ee schema using the
> xml extension system.  If the spec committee did not want the schemas
> extended they would have marked them as final.  So we have our own
> schema the extends the j2ee one and allows for our tags to be added.
>
> Also note he wrote that out files our files would have a different
> name.  For example, ejb-jar.xml would be named geronimo-ejb-jar.xml.
> If the user had the geronimo file, that is what we would use to deploy,
> if they only had an ejb-jar.xml file then they would get a default
> deployment.  Basically this is the same thing as what JB does, except
> instead of having a weird 2 file thing we put everything in a single
> consistent descriptor.
>
> -dain
>
> On Saturday, September 6, 2003, at 08:26 PM, Greg Wilkins wrote:
>
> > -1
> >
> > I understand that the single file nature of this approach is considered
> > attractive.  JSR154 was considering supporting such descriptor
> > extensions
> > as part of the spec.  However, this was removed from the spec and the
> > feeling is that the J2EE jsrs will no longer favour such descriptor
> > extensions
> > (as was once going to be the case for all j2ee 1.4 descriptors).
> >
> > The problems listed included:
> >
> >  + difficulties in file lifecycles for tools that generate descriptors.
> >    Anything that does not know about geronimo would probably constantly
> >    overwrite any geronimo specific elements.
> >
> >  + Difficulties in maintaining multi container deployment.  Change
> > control
> >    and generation of container specific configuration will be
> > difficult if
> >    multiple tools want to add container specific information into the
> >    standards descriptors.
> >
> >
> >
> > Jeremy Boynes wrote:
> >> I have recently checked in a XML Schema for a couple of
> >> Geronimo-specific deployment descriptors. These rely on namespaces to
> >> allow vendor-specific elements to be included in standard deployment
> >> descriptors.
> >> For example, an ejb-ref would be defined as:
> >>     <ejb-ref>
> >>         <ejb-ref-name>ejb/MyEJB</ejb-ref-name>
> >>         <ejb-ref-type>Session</ejb-ref-type>
> >>         <home>my.EJB.Home</home>
> >>         <remote>my.EJB.Remote</remote>
> >>         <ger:jndi-name>TestEJB</ger:jndi-name>
> >>     </ejb-ref>
> >> where ger: is the prefix for the Geronimo namespace.
> >> The way this is intended to work is that the deployer will copy the
> >> standard deployment descriptor file to the Geronimo one and then add
> >> in
> >> out entries. If a geronimo descriptor exists, we will not use the
> >> standard one at all so developers will be able to work exclusively
> >> with
> >> the geronimo version. We will provide a tool for generating a standard
> >> descriptor by stripping out all geronimo-specific elements.
> >> This is working for the application-client descriptor and we will be
> >> building out the EJB one once we know what the container-specific
> >> elements actually are.
> >> This is a little different from the old-style form of vendor
> >> descriptors
> >> (e.g. as used by Weblogic or JBoss) where they were separate documents
> >> that contained just supplemental information. In light of this, I
> >> would
> >> appreciate feedback on the approach before we get too far along.
> >> --
> >> Jeremy
> >
> >
> >
> >
>
> /*************************
>   * Dain Sundstrom
>   * Partner
>   * Core Developers Network
>   *************************/
>

Re: Geronimo Deployment Descriptors

[Dain Sundstrom <da...@coredevelopers.net>]

That is not what Jeremy did.  He has extended the j2ee schema using the 
xml extension system.  If the spec committee did not want the schemas 
extended they would have marked them as final.  So we have our own 
schema the extends the j2ee one and allows for our tags to be added.

Also note he wrote that out files our files would have a different 
name.  For example, ejb-jar.xml would be named geronimo-ejb-jar.xml.  
If the user had the geronimo file, that is what we would use to deploy, 
if they only had an ejb-jar.xml file then they would get a default 
deployment.  Basically this is the same thing as what JB does, except 
instead of having a weird 2 file thing we put everything in a single 
consistent descriptor.

-dain

On Saturday, September 6, 2003, at 08:26 PM, Greg Wilkins wrote:

> -1
>
> I understand that the single file nature of this approach is considered
> attractive.  JSR154 was considering supporting such descriptor 
> extensions
> as part of the spec.  However, this was removed from the spec and the
> feeling is that the J2EE jsrs will no longer favour such descriptor 
> extensions
> (as was once going to be the case for all j2ee 1.4 descriptors).
>
> The problems listed included:
>
>  + difficulties in file lifecycles for tools that generate descriptors.
>    Anything that does not know about geronimo would probably constantly
>    overwrite any geronimo specific elements.
>
>  + Difficulties in maintaining multi container deployment.  Change 
> control
>    and generation of container specific configuration will be 
> difficult if
>    multiple tools want to add container specific information into the
>    standards descriptors.
>
>
>
> Jeremy Boynes wrote:
>> I have recently checked in a XML Schema for a couple of
>> Geronimo-specific deployment descriptors. These rely on namespaces to
>> allow vendor-specific elements to be included in standard deployment
>> descriptors.
>> For example, an ejb-ref would be defined as:
>>     <ejb-ref>
>>         <ejb-ref-name>ejb/MyEJB</ejb-ref-name>
>>         <ejb-ref-type>Session</ejb-ref-type>
>>         <home>my.EJB.Home</home>
>>         <remote>my.EJB.Remote</remote>
>>         <ger:jndi-name>TestEJB</ger:jndi-name>
>>     </ejb-ref>
>> where ger: is the prefix for the Geronimo namespace.
>> The way this is intended to work is that the deployer will copy the
>> standard deployment descriptor file to the Geronimo one and then add 
>> in
>> out entries. If a geronimo descriptor exists, we will not use the
>> standard one at all so developers will be able to work exclusively 
>> with
>> the geronimo version. We will provide a tool for generating a standard
>> descriptor by stripping out all geronimo-specific elements.
>> This is working for the application-client descriptor and we will be
>> building out the EJB one once we know what the container-specific
>> elements actually are.
>> This is a little different from the old-style form of vendor 
>> descriptors
>> (e.g. as used by Weblogic or JBoss) where they were separate documents
>> that contained just supplemental information. In light of this, I 
>> would
>> appreciate feedback on the approach before we get too far along.
>> --
>> Jeremy
>
>
>
>

/*************************
  * Dain Sundstrom
  * Partner
  * Core Developers Network
  *************************/

Re: Geronimo Deployment Descriptors

[Greg Wilkins <gr...@mortbay.com>]

-1

I understand that the single file nature of this approach is considered
attractive.  JSR154 was considering supporting such descriptor extensions
as part of the spec.  However, this was removed from the spec and the
feeling is that the J2EE jsrs will no longer favour such descriptor extensions
(as was once going to be the case for all j2ee 1.4 descriptors).

The problems listed included:

  + difficulties in file lifecycles for tools that generate descriptors.
    Anything that does not know about geronimo would probably constantly
    overwrite any geronimo specific elements.

  + Difficulties in maintaining multi container deployment.  Change control
    and generation of container specific configuration will be difficult if
    multiple tools want to add container specific information into the
    standards descriptors.



Jeremy Boynes wrote:
> I have recently checked in a XML Schema for a couple of
> Geronimo-specific deployment descriptors. These rely on namespaces to
> allow vendor-specific elements to be included in standard deployment
> descriptors.
> 
> For example, an ejb-ref would be defined as:
>     <ejb-ref>
>         <ejb-ref-name>ejb/MyEJB</ejb-ref-name>
>         <ejb-ref-type>Session</ejb-ref-type>
>         <home>my.EJB.Home</home>
>         <remote>my.EJB.Remote</remote>
>         <ger:jndi-name>TestEJB</ger:jndi-name>
>     </ejb-ref>
> 
> where ger: is the prefix for the Geronimo namespace.
> 
> The way this is intended to work is that the deployer will copy the
> standard deployment descriptor file to the Geronimo one and then add in
> out entries. If a geronimo descriptor exists, we will not use the
> standard one at all so developers will be able to work exclusively with
> the geronimo version. We will provide a tool for generating a standard
> descriptor by stripping out all geronimo-specific elements.
> 
> This is working for the application-client descriptor and we will be
> building out the EJB one once we know what the container-specific
> elements actually are.
> 
> This is a little different from the old-style form of vendor descriptors
> (e.g. as used by Weblogic or JBoss) where they were separate documents
> that contained just supplemental information. In light of this, I would
> appreciate feedback on the approach before we get too far along.
> 
> --
> Jeremy
> 
> 

Re: Geronimo Deployment Descriptors

[Aaron Mulder <am...@alumni.princeton.edu>]

	It seems like there are two advantages to this approach:

 - No code needs to be written to read through multiple DDs and match up 
the content in each (i.e. find the "ejb/MyEJB" EJB ref for the same bean 
for multiple DDs).

 - We wouldn't require the developer to use optional nodes (such as the
relationship name or the ID attributes), just so we could do the
aforementioned matching up

	I also see a number of disadvantages:

 - It becomes much hard to maintain these things by hand.  Every change
you make in the ejb-jar.xml needs to be made in the geronimo-ejb-jar.xml,
and the place to do it may be inobvious because the standard content
you're looking for may be drowned in the ger: content (try to change a 
CMP field in a JAR full of entities).

 - If we ignore the ejb-jar.xml in favor of reading only the Geronimo DD, 
then we introduce bugs where someone updated the standard DD but we ignore 
it.  See OC4J, where you have to delete your application-deployments 
directory every time you make a substantive change to the DDs, because it 
generates its own authoritative DD based on the input you supply, and 
then it doesn't update the authoritative one often enough.

 - If we do not ignore the ejb-jar.xml in favor of reading only the 
Geronimo DD, we have the same matching-up problem as before if the content 
differs between the two DDs.  Let's say the user changes the name of an 
EJB -- do we just trash all the settings we had before?  We still need to 
add new Geronimo content for new EJBs and remove old Geronimo content for 
removed ones too.

 - Bottom line, I think this amounts to requiring the developer to use a
tool to create their DDs -- I don't think it will be manageable otherwise.  
But we can't do that (users will be users), so I think we'd just be
setting ourselves up for a lot of trouble.


	All that said, I would support the Geronimo POJOs fitting in with 
the J2EE POJOs this way, so we can have the XML reader do the matching-up, 
and then all the Geronimo code can access one unified set of POJO 
metadata.

Aaron

On Sat, 6 Sep 2003, Jeremy Boynes wrote:
> I have recently checked in a XML Schema for a couple of
> Geronimo-specific deployment descriptors. These rely on namespaces to
> allow vendor-specific elements to be included in standard deployment
> descriptors.
> 
> For example, an ejb-ref would be defined as:
>     <ejb-ref>
>         <ejb-ref-name>ejb/MyEJB</ejb-ref-name>
>         <ejb-ref-type>Session</ejb-ref-type>
>         <home>my.EJB.Home</home>
>         <remote>my.EJB.Remote</remote>
>         <ger:jndi-name>TestEJB</ger:jndi-name>
>     </ejb-ref>
> 
> where ger: is the prefix for the Geronimo namespace.
> 
> The way this is intended to work is that the deployer will copy the
> standard deployment descriptor file to the Geronimo one and then add in
> out entries. If a geronimo descriptor exists, we will not use the
> standard one at all so developers will be able to work exclusively with
> the geronimo version. We will provide a tool for generating a standard
> descriptor by stripping out all geronimo-specific elements.
> 
> This is working for the application-client descriptor and we will be
> building out the EJB one once we know what the container-specific
> elements actually are.
> 
> This is a little different from the old-style form of vendor descriptors
> (e.g. as used by Weblogic or JBoss) where they were separate documents
> that contained just supplemental information. In light of this, I would
> appreciate feedback on the approach before we get too far along.
> 
> --
> Jeremy
>