[vote]POJO design?

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

We have 2 concrete patches and 1 abstract proposal to vote on:

[  ] Greg's patch: A single tree of standard & geronimo elements
[  ] Aaron's/Jeremy's patch: Dual concrete trees
[  ] Proposal of a concrete geronimo tree with abstract standard tree.


My own vote is

[+1] Greg's patch: A single tree of standard & geronimo elements
[-0] Aaron's/Jeremy's patch: Dual concrete trees
[+0] Proposal of a concrete geronimo tree with abstract standard tree.

Re: [vote]POJO design?

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

Aaron Mulder wrote:
> Greg,
> 
> 	I know I was going to try to do it yesterday, but I still haven't
> had a chance to look at your latest patch, and I won't be able to do so
> today either.  So let me declare my intention to vote tomorrow, and please
> don't draw any conclusions before then.  Sorry for the delay!

Nah - I think we should restrict the vote to sad gits that work on
open source all weekend :-)

I'll probably put a new patch up tonight with a few more minor
cleanups - but no changes of substance.

cheers


> Aaron
> 
> On Sat, 13 Sep 2003, Greg Wilkins wrote:
> 
>>We have 2 concrete patches and 1 abstract proposal to vote on:
>>
>>[  ] Greg's patch: A single tree of standard & geronimo elements
>>[  ] Aaron's/Jeremy's patch: Dual concrete trees
>>[  ] Proposal of a concrete geronimo tree with abstract standard tree.
>>
>>
>>My own vote is
>>
>>[+1] Greg's patch: A single tree of standard & geronimo elements
>>[-0] Aaron's/Jeremy's patch: Dual concrete trees
>>[+0] Proposal of a concrete geronimo tree with abstract standard tree.
> 
> 
> 

Re: [vote]POJO design?

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

Jeremy Boynes wrote:
> JNDIEnvironmentRefs was added to allow ComponentContextBuilder to work
> with different POJOs representing unrelated objects (EJBs and AppClients
> for sure, possibly Servlet's and Filters if needed). It works for either
> proposal.

It is supertype defined schemas, so it should be there regardless I think.

> This is a view used during container configuration and is not really
> part of the data model. The issue I had with your initial proposal was
> that it made the entire spec model abstract which meant that it could
> not me used to implement the DDBeans Aaron needs for the deployment
> tool.

Why not? The DDBeans would have used the abstract model and not known
that there was a geronimo implementation behind it.

As it is, the DDBeans or standard schema will not be able to be used to
generate something  that is directly usable by geronimo code.

We can't even pass in a geronimo tree to be manipulated by code written
against the standard tree - any sets it does will fail due to the wrong
type of element.

But we can build a geronimo tree and pass it into code that does read-only
from a standard tree.  Hopefully that will be our only cross tree use-case?

> I might be wrong, but I can't for now think of another view that is
> common across several components - maybe JNDIBindable, but if all it is
> is the JNDI name then I'm not convinced a separate interface is needed
> (this can just be handled by the respective container).

The whole point of OO design is to handle things you have not thought of yet.

But enough sour grapes from me:-)  I was not able to convince people
of my ideas, so lets move on with what we have.  I think it is a little
better for all this discussion.

cheers

Re: [vote]POJO design?

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

On Tue, 16 Sep 2003, Greg Wilkins wrote:
> Well as you are pretty much approved as a committer now - I'll take
> that as a veto.

	My intention was not for it to be an unalterable veto -- I'm sure
you could revise the patch in such a way as to accomodate my objections
and then I would withdraw it.  But in truth, I'd rather not go another
round of patch revisions at this point, so if you're willing to go with my
alternative then let's do it.

> Kind of decides the issue as few others have voted anyway.

	Ahh, but you get the last laugh, because I haven't heard from the 
PMC so I can't actually commit anything yet.  :)

> ... 
> So I would say that we should either add ALL interfaces for one of the
> trees now, or just add them if/when they are needed.  As we are not adding
> all the interfaces now, then I'd say leave it as is.

	Okay.

	Let's try to huddle with Jeremy in IM tomorrow and see if we can 
get this committed and move on.

Aaron

RE: [vote]POJO design?

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

JNDIEnvironmentRefs was added to allow ComponentContextBuilder to work
with different POJOs representing unrelated objects (EJBs and AppClients
for sure, possibly Servlet's and Filters if needed). It works for either
proposal.

This is a view used during container configuration and is not really
part of the data model. The issue I had with your initial proposal was
that it made the entire spec model abstract which meant that it could
not me used to implement the DDBeans Aaron needs for the deployment
tool.

I might be wrong, but I can't for now think of another view that is
common across several components - maybe JNDIBindable, but if all it is
is the JNDI name then I'm not convinced a separate interface is needed
(this can just be handled by the respective container).

--
Jeremy

> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Greg Wilkins
> Sent: Monday, September 15, 2003 7:29 PM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: [vote]POJO design?
> 
> 
> 
> 
> Aaron Mulder wrote:
> 
> > [-1] Greg's patch: A single tree of standard & geronimo elements
> 
> Well as you are pretty much approved as a committer now - 
> I'll take that as a veto.
> 
> Kind of decides the issue as few others have voted anyway.
> 
> 
> >  - The set of interfaces provided (JNDIEnvironmentRefs, 
> JNDINameable, 
> > and
> > JNDIRef) could be used as is for the other proposal, so there is no
> > advantage granted by just using interfaces.  Would 
> interface supporters
> > cheerfully agree to the other patch if I add the same 3 
> interfaces to it?
> 
> That again would be better.  But my main object remains that 
> it the current dual tree approach has been hand crafted and 
> we are only adding these interfaces where pragmatism dictates.
> 
> Adding these interfaces is just going part way to my initial 
> proposal of having one of the two trees as interfaces so that 
> both hierarchies can be correct.
> 
> So I would say that we should either add ALL interfaces for 
> one of the trees now, or just add them if/when they are 
> needed.  As we are not adding all the interfaces now, then 
> I'd say leave it as is.
> 
> 
> cheers
> 
> 
> 

Re: [vote]POJO design?

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

Aaron Mulder wrote:

> [-1] Greg's patch: A single tree of standard & geronimo elements

Well as you are pretty much approved as a committer now - I'll take
that as a veto.

Kind of decides the issue as few others have voted anyway.


>  - The set of interfaces provided (JNDIEnvironmentRefs, JNDINameable, and
> JNDIRef) could be used as is for the other proposal, so there is no
> advantage granted by just using interfaces.  Would interface supporters
> cheerfully agree to the other patch if I add the same 3 interfaces to it?

That again would be better.  But my main object remains that it
the current dual tree approach has been hand crafted and we are only
adding these interfaces where pragmatism dictates.

Adding these interfaces is just going part way to my initial proposal of
having one of the two trees as interfaces so that both hierarchies can
be correct.

So I would say that we should either add ALL interfaces for one of the
trees now, or just add them if/when they are needed.  As we are not adding
all the interfaces now, then I'd say leave it as is.


cheers

Re: [vote]POJO design?

[Jan Bartel <ja...@mortbay.com>]

It seems to me that a single tree will be by far the simplest and 
cleanest to deal with, irrespective of whether it is populated by 2 xml 
files or just one unified one.

So my vote is:
[ X ] Greg's patch: A single tree of standard & geronimo elements
[   ] Aaron's/Jeremy's patch: Dual concrete trees
[   ] Proposal of a concrete geronimo tree with abstract standard tree.

Jan

Greg Wilkins wrote:
> 
> 
> We have 2 concrete patches and 1 abstract proposal to vote on:
> 
> [  ] Greg's patch: A single tree of standard & geronimo elements
> [  ] Aaron's/Jeremy's patch: Dual concrete trees
> [  ] Proposal of a concrete geronimo tree with abstract standard tree.
> 
> 
> My own vote is
> 
> [+1] Greg's patch: A single tree of standard & geronimo elements
> [-0] Aaron's/Jeremy's patch: Dual concrete trees
> [+0] Proposal of a concrete geronimo tree with abstract standard tree.
> 
> 
> 
> 

Re: [vote]POJO design?

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

	I'm not able to fully apply Greg's latest patch:

patch: **** malformed patch at line 4838: RCS file: 
modules/core/src/java/org/apache/geronimo/deployment/model/web/AbstractWebApp.java

	It doesn't apply anything after that, and that's only 60% of the 
file.  Nevertheless, it appears that all the EJB content applied, so I'll 
base my comments on that:

[-1] Greg's patch: A single tree of standard & geronimo elements
[+1] Aaron's/Jeremy's patch: Dual concrete trees
[??] Proposal of a concrete geronimo tree with abstract standard tree.

	I'll take these in reverse order:

I don't have a clear understanding of the third option.

I am obviously in favor of my own suggestion

I cannot agree to Greg's patch "as is" for the following reasons:

 - Classes in the non-Geronimo J2EE package depend on classes in the
Geronimo package, which does not make sense to me

 - There is not actually a way to use only the standard J2EE DD tree; you 
cannot figure out whether any given field is a Geronimo field or a 
standard field

 - The set of interfaces provided (JNDIEnvironmentRefs, JNDINameable, and
JNDIRef) could be used as is for the other proposal, so there is no
advantage granted by just using interfaces.  Would interface supporters
cheerfully agree to the other patch if I add the same 3 interfaces to it?

Aaron

Re: [vote]POJO design?

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

Greg,

	I know I was going to try to do it yesterday, but I still haven't
had a chance to look at your latest patch, and I won't be able to do so
today either.  So let me declare my intention to vote tomorrow, and please
don't draw any conclusions before then.  Sorry for the delay!

Aaron

On Sat, 13 Sep 2003, Greg Wilkins wrote:
> We have 2 concrete patches and 1 abstract proposal to vote on:
> 
> [  ] Greg's patch: A single tree of standard & geronimo elements
> [  ] Aaron's/Jeremy's patch: Dual concrete trees
> [  ] Proposal of a concrete geronimo tree with abstract standard tree.
> 
> 
> My own vote is
> 
> [+1] Greg's patch: A single tree of standard & geronimo elements
> [-0] Aaron's/Jeremy's patch: Dual concrete trees
> [+0] Proposal of a concrete geronimo tree with abstract standard tree.