You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Greg Wilkins <gr...@mortbay.com> on 2003/09/08 16:08:05 UTC
[XML][Deployment]POJO design?
I'm looking at the POJOs for the deployment descriptors and I'm a
little confused by their design and what conventions they are meant
to follow.
The source of my confusion is that there are two inheritance
hierarchies that are partially implemented in the POJOs
One hierarchy is the standard typing of elements :
ejb.Entity is-a ejb.RpcBean is-a ejb.Ejb is-a j2ee.Displayable is-a Describable
The other is the vendor typing of elements :
geronimo.j2ee.EjbRef is-a j2ee.EJBRef
geronimo.web.WebApp is-a web.AbstractWebApp
But as multiple inheritance is not supported in java classes, the hierarchies
are not complete. For example:
geronimo.ejb.Entity is-NOT-a ejb.Entity
geronimo.ejb.Ejb is-NOT-a ejb.Ejb
I work out if there is a pattern for when which hierarchy is used?
And there are strange artifacts of this. eg
+ multiple implementations of methods like *.Ejb.getEjbLocalRef
+ methods like j2ee.Describable.getDescription() are not available
on geronimo.ejb.Ejb, which is NOT a ejb.Ejb (which is a j2ee.Describable).
The basic problem here is that we just can't implement both
inheritance hierachies in java. So my question is should we try?
Do we actually need concrete classes in the o.a.g.deployment.model.* packages?
We will always be constructing o.a.g.deployment.model.geronimo.* instances
so do we need classes like ejb.Ejb, as we will always create geronimo.ejb.Ejb?
So I think that either
0) there is some pattern that I am missing about which hierarchy to use?
in which case we need to document what that is.
1) we just don't bother with the o.a.g.deployment.model.* versions
2) We make the o.a.g.deployment.model.* versions interfaces so that we
can multiply inherit them
1) is simpler and type safe, but does not indicate what is standard and
what is not.
I think 2) should work ok and we would end up with things like:
class Entity extends Ejb
implements o.a.g.deployment.model.ejb.Entity
{
...
}
The main problem with this approach is that methods like
getEjbRef() will return a o.a.g.deployment.model.ejb.Ejb[]
and we will have to cast to o.a.g.deployment.model.geronimo.ejb.Ejb
in order to get the geronimo specific methods.
Alternately we could double up the methods (which we have done anyway):
class Ejb extends Entity implements o.a.g.d.m.ejb.Ejb
{
EjbRef[] ejbRef;
EjbRef[] getGeronimoEjbRef() {
return ejbRef;
}
o.a.g.d.m.ejb.EjbRef getEjbRef() {
return ejbRef;
}
...
}
Let's call this option 2a)
Or we could we could just do 1):
class Ejb extends Entity
{
EjbRef[] ejbRef;
EjbRef[] getEjbRef() {
return ejbRef;
}
...
}
I'm a bit cautious about starting to fix this as I'm unclear about
exactly what XML tools we are intending to eventually use and what
conventions they require of the POJOs. I'm guessing we still have no tools
set selected, so we should be able to do anything?
In which case, I propose that we/I start working towards 2).
This can be easily extended to 2a) or 1) if we decide we want more type
safety and less casting. I think 2a) is probably the best compromise
between having a standards structure and vendor type safety.
There are also a few naming convention problems that need to be
fixed (we have both EjbRef and EJBRef and some field names EJBRef instead
of ejbRef). I'll start fixing these while we decide what to do about the
rest of this.
cheers
Re: [vote]POJO design?
Posted by 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?
Posted by 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?
Posted by 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?
Posted by 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?
Posted by 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?
Posted by 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?
Posted by 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?
Posted by 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.
[vote]POJO design?
Posted by 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: [XML][Deployment][vote]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
This is just a repeat of the vote email I sent earlier, but with
the same markers in the subject.
Aaron has asked for a bit of time to review the latest patches, so
we wont bring this to a close until late tuesday.
> 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: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
Jeremy Boynes wrote:
> For those who missed the Jira mail, I have uploaded a derivative of
> Aaron's patch that allows the geronimo EJB POJO's (like Session) to
> subclass the spec ones and still implement JNDIEnvironmentRefs
For me this patch is a little bit better - it is starting down the
path of my original proposal of linking the two trees with interfaces.
However there are still many things that I don't like about it:
- I see it as a pragmatic handcrafted rendering of the DD schema that will
work for current usage. But without a common pattern applied to all elements it
will be vulnerable to problems if/when we need to extend other elements with
geronimo config or find common uses for elements other than JNDIEnvironmentRefs.
- Without a strong design pattern being used to map from the schema(s) to the POJOs
we will have problems doing any automation that works from the schemas. This
will make it more difficult to implement what was decided in the XML Parsing discussion,
namely to look for an XML framework to load/store the POJOs.
- The use-case for have dual trees has not been well established.
All we have is "Tools that edit a standard-only DD", yet:
+ Will geronimo have any tools that deal with only the standard DD?
+ Tools are free to ignore the geronimo methods - which are not
great in number and we can identify with interfaces or javadoc.
+ We have elsewhere made the decision to merge the XML of the
standard and geronimo DD descriptors - so geronimo tools will probably
have to deal with merged DDs anyway.
+ The existance of a standard only tree may encourage dual parsing of DDs.
If code that only needs standard elements loads a standard tree, then that
tree will not be usable by other code that wants the geronimo tree. What is
the policy for loading - will we always load the geronimo tree to avoid double
handling?
- The dual method approach for getXxx and getGeronimoXxx is a bit
ugly and confusing (yeah I know I proposed it). Also the setXxx() methods
only provides runtime type safety not compile time type safety. I guess
we can't avoid this with dual trees.
- There are no methods for converting between standard and geronimo elements
and/or trees. So a lot more code is needed before this solution is complete and
generally usable.
I'm sorry but I still see the current approach as hand crafted pragmatism, when
there is no reason to avoid application of a rigourous design pattern.
I don't think there has been any real criticism of the patch that I have
done - other than the lack of a standard tree.
If the case for a standard tree is made, then I think we would be better of with
a rigorous application of a dual tree design pattern to the standard and geronimo
DD schemas. This is perhaps bit more code, but it is regular in design and easy
to understand and predice.
> I am not convinced we have reached conclusion yet and so would suggest
> that if we do start committing thigs they go in a different branch.
we need to move on, so lets have a vote. I'll post a vote messages shortly.
cheers
RE: [XML][Deployment]POJO design?
Posted by Jeremy Boynes <je...@coredevelopers.net>.
For those who missed the Jira mail, I have uploaded a derivative of
Aaron's patch that allows the geronimo EJB POJO's (like Session) to
subclass the spec ones and still implement JNDIEnvironmentRefs
This keeps two concrete trees so that tools that only deal with the spec
do not need to understand Geronimo objects but which preserves the type
safety for the subclasses.
I am not convinced we have reached conclusion yet and so would suggest
that if we do start committing thigs they go in a different branch.
--
Jeremy
> -----Original Message-----
> From: Gmane Remailer [mailto:public@main.gmane.org] On Behalf
> Of Greg Wilkins
> Sent: Friday, September 12, 2003 1:30 AM
> To:
> public-geronimo-dev=d1GL8uUpDdXTxqt0kkDzDmD2FQJk+8+b@ciao.gmane.org
> Subject: Re: [XML][Deployment]POJO design?
>
>
>
>
> Aaron Mulder wrote:
> > Stepping back a little, the truth is, any of the
> options on the table
> > at this point will likely meet the requirements, and I
> suspect we're
> > unlikely to reach 100% consensus on the design, so why don't you
> > either call a vote on which alternative with a time limit, or just
> > pick a deadline and say if there hasn't been a consensus by then
> > you'll just pick one and check it in so we can move on from
> here. If
> > you call a vote, it would help if the people voting +1 are
> willing to
> > put some time into implementing the code, since we have a
> fair bit of
> > DD coverage left (EAR, RAR, and the missing Geronimo schemas).
>
> I've had a look at your second patch and I'm still not
> convinced. So I'm going to apply my 2nd patch first thing
> tomorrow - unless Jeremy, Dain or other heavy user of the
> geronimo DDs objects.
>
> Once we start getting a lot of geronimo configuration added
> to the DD's then I think it would be a good time to restard
> the discussion for the support of a standard only POJO tree
> (either as interfaces or as per your patch).
>
> Just for the record, the following is what I don't like about
> your patch 2.
>
> Take o.a.g.d.m.e.Entity for example. It now reads:
>
> public class Entity extends
> org.apache.geronimo.deployment.model.ejb.Entity {
> private String jndiName;
>
> public String getJndiName() {
> return jndiName;
> }
>
> public void setJndiName(String jndiName) {
> this.jndiName = jndiName;
> }
>
> public SecurityRoleRef[] getGeronimoSecurityRoleRef() {
> return (SecurityRoleRef[])super.getSecurityRoleRef();
> }
>
> public SecurityRoleRef getGeronimoSecurityRoleRef(int i) {
> return (SecurityRoleRef)super.getSecurityRoleRef(i);
> }
> }
>
> So you have added Geronimo casting methods for
> SecurityRoleRef, but you really need to add the same for all
> the Geronimo types:
> EjbRef, EjbLocalRef, ServiceRef, ResourceRef,
> ResourceEnvRef, MessageDesinationRef
>
> Also it is not sufficient for type safety to just provide the
> getters. You need to provide geronimo setters as well so we
> can get compile time type checking.
>
> But then it will still be possible for the standard setters
> to be called, so they probably need to be overriden to make
> them check the type of the array being set is a geronimo
> array. Even then, that is only run time type checking.
>
> Finally I still don't have a geronimo version of
> JNDIEnvironmentRefs that will allow me to deal with Entity's,
> Sessions, etc as strongly typed providers of geronimo JNDIRef
> entities. All code written to this API will be able to fail
> at run-time with simple type errors of passing
> in the wrong type of POJO. As type safety was one of the
> main drivers
> for going for a POJO DD model, I think this is important.
>
> regards
>
>
>
>
>
>
>
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
Aaron Mulder wrote:
> Stepping back a little, the truth is, any of the options on the
> table at this point will likely meet the requirements, and I suspect we're
> unlikely to reach 100% consensus on the design, so why don't you either
> call a vote on which alternative with a time limit, or just pick a
> deadline and say if there hasn't been a consensus by then you'll just pick
> one and check it in so we can move on from here. If you call a vote, it
> would help if the people voting +1 are willing to put some time into
> implementing the code, since we have a fair bit of DD coverage left (EAR,
> RAR, and the missing Geronimo schemas).
I've had a look at your second patch and I'm still not convinced. So I'm
going to apply my 2nd patch first thing tomorrow - unless Jeremy, Dain or
other heavy user of the geronimo DDs objects.
Once we start getting a lot of geronimo configuration added to the DD's
then I think it would be a good time to restard the discussion for the
support of a standard only POJO tree (either as interfaces or as per your patch).
Just for the record, the following is what I don't like about your patch 2.
Take o.a.g.d.m.e.Entity for example. It now reads:
public class Entity extends org.apache.geronimo.deployment.model.ejb.Entity {
private String jndiName;
public String getJndiName() {
return jndiName;
}
public void setJndiName(String jndiName) {
this.jndiName = jndiName;
}
public SecurityRoleRef[] getGeronimoSecurityRoleRef() {
return (SecurityRoleRef[])super.getSecurityRoleRef();
}
public SecurityRoleRef getGeronimoSecurityRoleRef(int i) {
return (SecurityRoleRef)super.getSecurityRoleRef(i);
}
}
So you have added Geronimo casting methods for SecurityRoleRef, but
you really need to add the same for all the Geronimo types:
EjbRef, EjbLocalRef, ServiceRef, ResourceRef, ResourceEnvRef, MessageDesinationRef
Also it is not sufficient for type safety to just provide the getters.
You need to provide geronimo setters as well so we can get compile time
type checking.
But then it will still be possible for the standard setters to be called,
so they probably need to be overriden to make them check the type
of the array being set is a geronimo array. Even then, that is only run time
type checking.
Finally I still don't have a geronimo version of JNDIEnvironmentRefs that
will allow me to deal with Entity's, Sessions, etc as strongly typed
providers of geronimo JNDIRef entities. All code written to this API
will be able to fail at run-time with simple type errors of passing
in the wrong type of POJO. As type safety was one of the main drivers
for going for a POJO DD model, I think this is important.
regards
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
Lyndon Samson wrote:
> You could of course just use properties, with overlay accessor classes providing
> particular views and type safety.
The starting point of all this.... was that it was decided that we want POJOs as
the in-memory representation of DDs. So properties would not meet that requirement.
I'm not the best one to say why we want POJOs - I was happy using DOM :-)
But look for the "parsing XML" discussion last week for the reasoning.
> Just flatten
> <des>
> <item>
> <val>1</val>
> </item>
> </des>
>
> to
>
> des.item.1.val.1=1
Re[2]: [XML][Deployment]POJO design?
Posted by Lyndon Samson <sa...@dodo.net.au>.
You could of course just use properties, with overlay accessor classes providing
particular views and type safety.
Just flatten
<des>
<item>
<val>1</val>
</item>
</des>
to
des.item.1.val.1=1
Re: [XML][Deployment]POJO design?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Stepping back a little, the truth is, any of the options on the
table at this point will likely meet the requirements, and I suspect we're
unlikely to reach 100% consensus on the design, so why don't you either
call a vote on which alternative with a time limit, or just pick a
deadline and say if there hasn't been a consensus by then you'll just pick
one and check it in so we can move on from here. If you call a vote, it
would help if the people voting +1 are willing to put some time into
implementing the code, since we have a fair bit of DD coverage left (EAR,
RAR, and the missing Geronimo schemas).
Aaron
On Wed, 10 Sep 2003, Greg Wilkins wrote:
> I've had a look at Aarons patch posted to
> http://jira.codehaus.org/secure/ViewIssue.jspa?key=GERONIMO-76
>
> While better - it still suffers from trying to provide two inheritance
> trees and only fully implementing one of them. This works for now because
> we have so few geronimo specific elements in the tree.
>
> I've been working on the alternatives I have suggested. Firstly I stand corrected
> that the interface approach is not less code. It's about the same, what it gains
> in removed duplicate code it looses in the extra interface classes required.
> Again because we have so little geronimo specific config in the tree at the moment,
> it looks a little silly.
>
> Thus I have gone ahead with the much simpler model of just a single tree
> of geronimo DD POJOs. I have posted a tar of the code to the issue for
> people to review. I have also fixed up the naming convention of the classes (Ejb -> EJB etc.)
> It is compiling and passing the test harnesses - but I'm not sure how good they
> are so I'll do some more testing shortly.
>
> So I think it is over to people other than Aaron and myself to get some
> feedback.
>
> cheers
>
> PS. If somebody is really keen on the standard interface version - I have
> a copy of that which compiles for deployment - but I have not fixed up the rest of the
> code to use it.
>
>
>
>
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
I've had a look at Aarons patch posted to
http://jira.codehaus.org/secure/ViewIssue.jspa?key=GERONIMO-76
While better - it still suffers from trying to provide two inheritance
trees and only fully implementing one of them. This works for now because
we have so few geronimo specific elements in the tree.
I've been working on the alternatives I have suggested. Firstly I stand corrected
that the interface approach is not less code. It's about the same, what it gains
in removed duplicate code it looses in the extra interface classes required.
Again because we have so little geronimo specific config in the tree at the moment,
it looks a little silly.
Thus I have gone ahead with the much simpler model of just a single tree
of geronimo DD POJOs. I have posted a tar of the code to the issue for
people to review. I have also fixed up the naming convention of the classes (Ejb -> EJB etc.)
It is compiling and passing the test harnesses - but I'm not sure how good they
are so I'll do some more testing shortly.
So I think it is over to people other than Aaron and myself to get some
feedback.
cheers
PS. If somebody is really keen on the standard interface version - I have
a copy of that which compiles for deployment - but I have not fixed up the rest of the
code to use it.
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
I've got a new patch ready, which I'll attach to the JIRA issue shortly
and unless anybody object I will commit tomorrow morning (NB. but not to
stop discussion of a dual tree approach).
JNDINameable has been renamed to JNDIRef to match the jndi-refGroup
in the schema.
EJB is not longer a JNDIRef, but RPCBean now does. I'll look at
Aarons patch shortly to add support for jndi-name into the schema, as it
is missing.
JNDIEnvironmentRefs has been put back - and as part of that, lots more
naming convention stuff has been fixed.
cheers
Greg Wilkins wrote:
> Jeremy Boynes wrote:
>
>> Greg's is much larger, but I have reservations about the actual data
>> model.
>> For example, EJB extends JNDINameable but MDB's do not have a JNDI
>> binding.
>> I am also confused about the meaning of JNDINameable as both EJB and
>> EJBRef
>> are subclasses but the jndi-name element has very different meaning
>> between
>> them.
>
>
> JNDINameable probably should be an interface and just mixed in when needed.
> I think it is not genrally applicable to put geronimo types in to the
> extends inheritance tree.
>
>> We also seemed to have lost the JNDIEnvironmentRefs interface used by
>> ComponentContextBuilder so (and I admit I have not tested it) I am
>> curious
>> about how it works.
>
>
> That's an oops that I fixed up in my tree. I'll fix that and put
> another patch
> in soon.
>
> I think we are going to have problems evaluating the two approaches at
> the moment
> as we have so little geronimo specific configuration in the tree(s).
>
> What I'd like to propose as a way forward is that I commit my patch to
> create
> a single tree (with the naming issues fixed and the issues Jeremy
> pointed out
> addressed). As this is definitely the simplest solution with the least
> code.
>
> If Aaron and others really want dual trees, then a patch can be prepared
> against the single tree to move the geronimo config to a second tree,
> and we
> can discuss that once we have some more geronimo specific configuration to
> help resolve various approached.
>
> cheers
>
>
>
>
>
>
>
>
>
>
>
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
been offline for 36hrs with ISP failure...
Jeremy Boynes wrote:
> Greg's is much larger, but I have reservations about the actual data model.
> For example, EJB extends JNDINameable but MDB's do not have a JNDI binding.
> I am also confused about the meaning of JNDINameable as both EJB and EJBRef
> are subclasses but the jndi-name element has very different meaning between
> them.
JNDINameable probably should be an interface and just mixed in when needed.
I think it is not genrally applicable to put geronimo types in to the
extends inheritance tree.
> We also seemed to have lost the JNDIEnvironmentRefs interface used by
> ComponentContextBuilder so (and I admit I have not tested it) I am curious
> about how it works.
That's an oops that I fixed up in my tree. I'll fix that and put another patch
in soon.
I think we are going to have problems evaluating the two approaches at the moment
as we have so little geronimo specific configuration in the tree(s).
What I'd like to propose as a way forward is that I commit my patch to create
a single tree (with the naming issues fixed and the issues Jeremy pointed out
addressed). As this is definitely the simplest solution with the least code.
If Aaron and others really want dual trees, then a patch can be prepared
against the single tree to move the geronimo config to a second tree, and we
can discuss that once we have some more geronimo specific configuration to
help resolve various approached.
cheers
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
been offline for 36hrs with ISP failure...
Jeremy Boynes wrote:
> Greg's is much larger, but I have reservations about the actual data model.
> For example, EJB extends JNDINameable but MDB's do not have a JNDI binding.
> I am also confused about the meaning of JNDINameable as both EJB and EJBRef
> are subclasses but the jndi-name element has very different meaning between
> them.
JNDINameable probably should be an interface and just mixed in when needed.
I think it is not genrally applicable to put geronimo types in to the
extends inheritance tree.
> We also seemed to have lost the JNDIEnvironmentRefs interface used by
> ComponentContextBuilder so (and I admit I have not tested it) I am curious
> about how it works.
That's an oops that I fixed up in my tree. I'll fix that and put another patch
in soon.
I think we are going to have problems evaluating the two approaches at the moment
as we have so little geronimo specific configuration in the tree(s).
What I'd like to propose as a way forward is that I commit my patch to create
a single tree (with the naming issues fixed and the issues Jeremy pointed out
addressed). As this is definitely the simplest solution with the least code.
If Aaron and others really want dual trees, then a patch can be prepared
against the single tree to move the geronimo config to a second tree, and we
can discuss that once we have some more geronimo specific configuration to
help resolve various approached.
cheers
RE: [XML][Deployment]POJO design?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
So far, there doesn't seem to be a conclusive answer -- Greg and I
have two proposals on the table, and I think Jeremy's the only one who's
looked at the code for both, and he didn't like either. I tried to
address his concerns (see below), but if anyone else wants to take a look
and chip in, that would be great.
On Wed, 10 Sep 2003, Jeremy Boynes wrote:
> I had a quick look over the two solutions and have concerns with both.
>
> Aaron's seems like a much smaller fix and I am not sure it addresses all the
> issues that people have brought up on this thread. If I read it correctly,
> it requires everyone using the geronimo model to cast the results of methods
> inherited from the spec model (e.g. (geronimo.EJBRef) getEJBRef() ). This
> could quickly become a PITA.
FWIW, I updated the patch so the Geronimo POJOs do the casts for
you. Also, I think one of the JSR-88 classes failed to compile against
the patch, so a revision is included with the new patch. This is the
"geronimo-ejb2.patch" file on the GERONIMO-76 issue. If there are other
issues (besides the cast) that need to be addressed, let me know.
Aaron
> Greg's is much larger, but I have reservations about the actual data model.
> For example, EJB extends JNDINameable but MDB's do not have a JNDI binding.
> I am also confused about the meaning of JNDINameable as both EJB and EJBRef
> are subclasses but the jndi-name element has very different meaning between
> them.
>
> We also seemed to have lost the JNDIEnvironmentRefs interface used by
> ComponentContextBuilder so (and I admit I have not tested it) I am curious
> about how it works.
>
> --
> Jeremy
>
RE: [XML][Deployment]POJO design?
Posted by Jeremy Boynes <je...@coredevelopers.net>.
> From: Gmane Remailer [mailto:public@main.gmane.org]On Behalf Of Greg
> Wilkins
> Sent: Tuesday, September 09, 2003 9:51 PM
> To: public-geronimo-dev=d1GL8uUpDdXTxqt0kkDzDmD2FQJk+8+b@ciao.gmane.org
>>>>>>>>>>>> Greg, please can you fix your mailer. <<<<<<<<<<<<<<<<
> Anyway - I'm almost ready with my own patch - so we can compare
> and contrast
> that with yours in a few hours
>
I had a quick look over the two solutions and have concerns with both.
Aaron's seems like a much smaller fix and I am not sure it addresses all the
issues that people have brought up on this thread. If I read it correctly,
it requires everyone using the geronimo model to cast the results of methods
inherited from the spec model (e.g. (geronimo.EJBRef) getEJBRef() ). This
could quickly become a PITA.
Greg's is much larger, but I have reservations about the actual data model.
For example, EJB extends JNDINameable but MDB's do not have a JNDI binding.
I am also confused about the meaning of JNDINameable as both EJB and EJBRef
are subclasses but the jndi-name element has very different meaning between
them.
We also seemed to have lost the JNDIEnvironmentRefs interface used by
ComponentContextBuilder so (and I admit I have not tested it) I am curious
about how it works.
--
Jeremy
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
Aaron Mulder wrote:
> What can I say? I am not convinced by your concerns. I don't
> mean to be rude,
Disagreement is not rude - so don't worry about it.
People disagree - it happens and we have to work it out as best we can.
> I just don't mind a cast here or there, and if you want
> to wrap the property with additional helper methods that do the cast for
> you, you can even eliminate that.
I think the reason we are disagreeing is at the moment there is
little more than getJndiName as an extra method here or there. So my
concerns about the typing hierarchy don't look huge and can be
overcome with a bit of cut and paste and a few casts.
But I still maintain that if the type hierarchy is not correct, then we
are just going to have more and more problems if and when we add more
geronimo specific configuration.
Anyway - I'm almost ready with my own patch - so we can compare and contrast
that with yours in a few hours
cheers
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
I've had a look at Aarons patch posted to
http://jira.codehaus.org/secure/ViewIssue.jspa?key=GERONIMO-76
While better - it still suffers from trying to provide two inheritance
trees and only fully implementing one of them. This works for now because
we have so few geronimo specific elements in the tree.
I've been working on the alternatives I have suggested. Firstly I stand corrected
that the interface approach is not less code. It's about the same, what it gains
in removed duplicate code it looses in the extra interface classes required.
Again because we have so little geronimo specific config in the tree at the moment,
it looks a little silly.
Thus I have gone ahead with the much simpler model of just a single tree
of geronimo DD POJOs. I have posted a tar of the code to the issue for
people to review. I have also fixed up the naming convention of the classes (Ejb -> EJB etc.)
It is compiling and passing the test harnesses - but I'm not sure how good they
are so I'll do some more testing shortly.
So I think it is over to people other than Aaron and myself to get some
feedback.
cheers
PS. If somebody is really keen on the standard interface version - I have
a copy of that which compiles for deployment - but I have not fixed up the rest of the
code to use it.
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
In the interest of progress and explaination, I have
started making the changes for both the geronimo only
model and the standard as interfaces model.
I'll make the code available later today, but wont commit
unless we get a rough concensus.
So don't let the writing of code stop anybody putting their
views forward - or preparing alternative code.
cheers
Re: [XML][Deployment]POJO design?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Wed, 10 Sep 2003, Greg Wilkins wrote:
> They have a lot more in common. Even for the standard methods (eg getEjbRef)
> they all need this to be a collection of geronimo EjbRefs rather than
> standard EjbRefs.
I don't think they "need to be", though certainly it's handy to
avoid casts.
> But that does not work, as foo.getEJBRef may be an array of standard
> EJBRefs. It may contain geronimoEJBRef or it may not! If we support
> both sets of concrete instances, then we will always need to check
> which has be passed before we attempt a downcast.
This, I disagree with. Who's ever going to build a tree of
Geronimo objects and put non-Geronimo data in there? When would you ever
literally have an array of EJBRef, some of which were Geronimo ones and
some of which were not? This would be really dumb. Either you're using
the plain J2EE-only DD, or you're using the Geronimo DD. If you mix, it's
a bug.
> No - it is the other way around. I'm proposing that we up-cast
> not down-cast.
>
> We only support concrete storage of arrays of geronimo Object.
> IF (and that is a big IF) we need to write code that does not know about
> geronimo, then we can cast that arrary to a standard array. Up-casting
> is safe and can always be done. Down casting is not safe and can't be
> done if the array or anything it contains is not a geronimo instance.
I don't see why we'd want to always create subclasses even when we
don't want them (i.e. editing a J2EE DD). That just seems wrong.
> But I also don't understand why you don't like my proposal? It correctly
> provides both a standard and geronimo hierarchy type hierarchy and
> I have demonstrated that it is less code. I'm happy to do it so long as we
> have some concensus that it is at least not wrong (we don't all have to
> agree that it is 100% the best way).
I haven't seen a demonstration that it is less code. I maintain
that it's more code. If you look at the patch that's in JIRA for my
proposal, I updated the existing classes for ejb-jar, enterprise-beans,
entity, session, and message-driven. There are a total of 4 methods
across all of them (getJndiName and setJndiName on Entity and Session).
How many methods do you propose putting in that same set of classes? Is
it fewer than 4? Or do all of them have fewer than 1 line? Are the two
interfaces plus one implementation fewer than the one implementation plus
one subclass? Where are the savings?
> My objection to your proposal remains that we need a common geronimo.ejb.EJB
> type, because many of the standard methods need to be extended to
> work with geronimo types (GeronimoEjbRefs etc.). While these subtypes
> could be stored in the standard type array, I have enumerated a number
> of concerns with that approach which have not been addressed.
What can I say? I am not convinced by your concerns. I don't
mean to be rude, I just don't mind a cast here or there, and if you want
to wrap the property with additional helper methods that do the cast for
you, you can even eliminate that. If the only down side is that you have
to copy and paste some helper methods from Session to Entity, live with
it. I don't see a huge maintenance issue because you have two helper
methods that read "return (GeronimoFoo[])super.getFoo();" (one in Entity,
one in Session) These properties will *never* change.
> And the other view point being expressed is that maybe we don't need
> the standard only pojos at all. I could easily convinced of that, but am
> happy to use interfaces if others really want the just the standard API.
For everyone who isn't concerned with a JSR-88 tool that edits
J2EE deployment descriptors, this is a valid point of view. I am not a
member of that group.
> This is a classic problem that we are trying to solve - that is why there
> are lots of chapters in patterns books about how to do this. I really
> don't think we should ignore past experience and think that we can get
> by with a few casts. We should either avoid the problem with just a
> single type hierarchy or adopt one of the standards solutions - which is
> going to involve interfaces for multiple typing.
Please! I can't seem to respond to this paragraph without being
rude. Let me just say that I also don't find it compelling to say "there
are lots of chapters in patterns books about how to do this" and I'll
leave it at that.
> To futher this discussion, I think we need two questions answered:
>
> What exactly is the use case for having standard-only API for these classes?
Tools that edit a standard-only DD.
> Given that there is a use-case for standard-only, why is a set of standard
> interfaces to the geronimo implementations insufficient?
It is not insufficient, it is overkill. Creating objects of the
wrong type and then upcasting them to purposely restrict yourself to a
subset of their available properties is not an advantage.
Aaron
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
Aaron,
Aaron Mulder wrote:
>>Eg. If we don't have a common geronimo.ejb.EJB class for Session, Entity
>>and Message, then we can't write any code that deals with these beans in
>>common - eg we are going to have to write the marshalling code 3 times, etc. etc.
>
>
> The only thing these classes have in common (currently) is the
> content in (j2ee.)ejb.EJB! And you can treat them in common in that way!
> Then when you go to write the children (refs and so on), you'll have to
> write a cast, but give me a break!!!
They have a lot more in common. Even for the standard methods (eg getEjbRef)
they all need this to be a collection of geronimo EjbRefs rather than
standard EjbRefs.
> public void marshallGeronimoEjb(j2ee.ejb.EJB foo) {
> marshallGeronimoEjbRef((GeronimoEJBRef[])foo.getEJBRef());
> marshallGeronimoEnvEntry((GeronimoEnvEntry[])foo.getEnvEntry());
> ...
> }
But that does not work, as foo.getEJBRef may be an array of standard
EJBRefs. It may contain geronimoEJBRef or it may not! If we support
both sets of concrete instances, then we will always need to check
which has be passed before we attempt a downcast.
> public void marshallGeronimoEjbRef(GeronimoEjbRef[] foo) {
> ...
> }
>
> Apparently, you even proposed adding some getters to do the cast
> for you, so even that goes away. I really don't see what your issue is.
No - it is the other way around. I'm proposing that we up-cast
not down-cast.
We only support concrete storage of arrays of geronimo Object.
IF (and that is a big IF) we need to write code that does not know about
geronimo, then we can cast that arrary to a standard array. Up-casting
is safe and can always be done. Down casting is not safe and can't be
done if the array or anything it contains is not a geronimo instance.
But I also don't understand why you don't like my proposal? It correctly
provides both a standard and geronimo hierarchy type hierarchy and
I have demonstrated that it is less code. I'm happy to do it so long as we
have some concensus that it is at least not wrong (we don't all have to
agree that it is 100% the best way).
My objection to your proposal remains that we need a common geronimo.ejb.EJB
type, because many of the standard methods need to be extended to
work with geronimo types (GeronimoEjbRefs etc.). While these subtypes
could be stored in the standard type array, I have enumerated a number
of concerns with that approach which have not been addressed.
And the other view point being expressed is that maybe we don't need
the standard only pojos at all. I could easily convinced of that, but am
happy to use interfaces if others really want the just the standard API.
This is a classic problem that we are trying to solve - that is why there
are lots of chapters in patterns books about how to do this. I really
don't think we should ignore past experience and think that we can get
by with a few casts. We should either avoid the problem with just a
single type hierarchy or adopt one of the standards solutions - which is
going to involve interfaces for multiple typing.
To futher this discussion, I think we need two questions answered:
What exactly is the use case for having standard-only API for these classes?
Given that there is a use-case for standard-only, why is a set of standard
interfaces to the geronimo implementations insufficient?
Re: [XML][Deployment]POJO design?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Tue, 9 Sep 2003, Greg Wilkins wrote:
> This is not just about code duplication - I was just responding to the
> suggestion that my proposal is more complex or more code. The main issue
> that I started talking about is that the type hierarchy is wrong.
>
> Eg. If we don't have a common geronimo.ejb.EJB class for Session, Entity
> and Message, then we can't write any code that deals with these beans in
> common - eg we are going to have to write the marshalling code 3 times, etc. etc.
The only thing these classes have in common (currently) is the
content in (j2ee.)ejb.EJB! And you can treat them in common in that way!
Then when you go to write the children (refs and so on), you'll have to
write a cast, but give me a break!!!
public void marshallGeronimoEjb(j2ee.ejb.EJB foo) {
marshallGeronimoEjbRef((GeronimoEJBRef[])foo.getEJBRef());
marshallGeronimoEnvEntry((GeronimoEnvEntry[])foo.getEnvEntry());
...
}
public void marshallGeronimoEjbRef(GeronimoEjbRef[] foo) {
...
}
Apparently, you even proposed adding some getters to do the cast
for you, so even that goes away. I really don't see what your issue is.
Now it's possible that some new common properties will be added,
but what can you think of that all EJBs have? Caching and pooling and
clustering are probably all different across Sessions, Entities, and MDBs,
only Entities have CMP and CMR, only MDBs have JMS, etc. Even MDBs don't
have a JNDI name...
> If the geronimo classes don't implement/extend the standard classes then
> we can't pass them into any class that takes the standard classes.
But they *will* extend the standard class!
geronimo.ejb.Session->ejb.Session->ejb.RpcBean->ejb.EJB->j2ee.Displayable
Anything that takes an ejb.Session is totally OK taking a
geronimo.ejb.Session!
> So I am not proposing change based on code volume - I'm proposing change
> because the design is currently not correct.
The code actually checked in at this moment is not correct, I
agree, but that's not what I'm talking about. Perhaps it would help if I
submit a patch, and you can look at what I'm actually suggesting.
Aaron
Re: [XML][Deployment]POJO design?
Posted by "Luigi R. Viggiano" <lv...@tiscali.it>.
> My god Greg, get a real IDE, and click the implement interface button,
> or click the delegate button and done with it.
Which IDE are you talking about? Is this an intelliJ feature, or Eclipse,
or what else? I just leaved from JBuilder ($$$) and I am trying Eclipse,
and don't feel so accustomed with it.
It's not intended to open flames, just wanna know what IDE are you using
and you think to be a real IDE.
~Luigi
__________________________________________________________________
Partecipa al concorso Tiscali "collegati e vinci",
il primo premio e' un viaggio per 2 persone a Zanzibar!
http://point.tiscali.it/numerounico/
Re: [XML][Deployment]POJO design?
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Sep 9, 2003, at 15:56 Europe/London, James Strachan wrote:
> On Tuesday, September 9, 2003, at 01:06 pm, Alex Blewitt wrote:
>> You could set the bridge up so that Geronimo doesn't even have to
>> care about what the types are (and/or generate delegation methods to
>> their normal counterparts). Plus, it could then be extended to deal
>> with other flavours, such as the WebSphere or Weblogic deployment
>> descriptors at the same time.
>
> Whoah. I know about bridges and the like. I'm asking *why* do we have
> to support any other deployment metadata other than Geronimo. e.g. why
> should the Geronimo project ever have to deal with non-Geronimo
> metadata. Lets figure out the use cases first before we dive off
> coding stuff we don't need.
Good thinking. What could this allow us to do, and would those
extensions be useful?
For starters, having separate Geronimo beans over the standard would
make it interoperate better with other containers and their deployment
stuff. For example, if the deployment tool was integrated into an IDE,
then it may be desirable to generate DDs for not only Geronimo, but
also other app servers as well. A bridge could solve that.
IMHO it's a lot better to take an EAR that has been pre-configured for
straight installation into a server than to have to do setup (where
possible). As such, some EARs have deployment configuration/code in
them already which allows them to be plugged straight in with no or
minimal intervention.
But in terms of deploying directly into Geronimo, this may not matter.
So can anyone else think of other advantages/uses that this would give
that others don't? If not, we may not need it.
Alex.
Re: [XML][Deployment]POJO design?
Posted by James Strachan <ja...@yahoo.co.uk>.
On Tuesday, September 9, 2003, at 01:06 pm, Alex Blewitt wrote:
> On Tuesday, Sep 9, 2003, at 10:56 Europe/London, James Strachan wrote:
>
>> What is the use case for having 'standard' beans separate from
>> geronimo beans - on't we just need Geronimo beans? i.e. it seems very
>> complex to have 2 separate trees of standard J2EE descriptors and
>> another tree of geronimo-extended J2EE descriptor beans. This leads
>> to a messy dual-inheritence hierarchy that Greg's brought up.
>
> I don't think you need to worry about having two separate trees --
> it's called the Bridge pattern. It's what the GUI AWT toolkit uses to
> present different flavours of widgets depending on OS.
>
> You could set the bridge up so that Geronimo doesn't even have to care
> about what the types are (and/or generate delegation methods to their
> normal counterparts). Plus, it could then be extended to deal with
> other flavours, such as the WebSphere or Weblogic deployment
> descriptors at the same time.
Whoah. I know about bridges and the like. I'm asking *why* do we have
to support any other deployment metadata other than Geronimo. e.g. why
should the Geronimo project ever have to deal with non-Geronimo
metadata. Lets figure out the use cases first before we dive off coding
stuff we don't need.
James
-------
http://radio.weblogs.com/0112098/
Re: [XML][Deployment]POJO design?
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Sep 9, 2003, at 10:56 Europe/London, James Strachan wrote:
> What is the use case for having 'standard' beans separate from
> geronimo beans - on't we just need Geronimo beans? i.e. it seems very
> complex to have 2 separate trees of standard J2EE descriptors and
> another tree of geronimo-extended J2EE descriptor beans. This leads to
> a messy dual-inheritence hierarchy that Greg's brought up.
I don't think you need to worry about having two separate trees -- it's
called the Bridge pattern. It's what the GUI AWT toolkit uses to
present different flavours of widgets depending on OS.
You could set the bridge up so that Geronimo doesn't even have to care
about what the types are (and/or generate delegation methods to their
normal counterparts). Plus, it could then be extended to deal with
other flavours, such as the WebSphere or Weblogic deployment
descriptors at the same time.
You can also use interfaces to merge the two types where appropriate.
public class SpecEJB implements EJB {
}
public class EJBPeer implements EJB {
private SpecEJB spec;
protected EJBPeer(SpecEJB spec) {
this.spec = spec;
}
public SpecEJB getSpec() {
return spec;
}
public String getName() {
return spec.getName();
}
}
public class GeronimoEJB extends EJBPeer {
public GeronimoEJB(SpecEJB spec) {
super(spec);
}
public String getGeronimoSpecificBit() {
}
}
public class WebSphereEJB extends EJBPeer {
public WebSphereEJB(SpecEJB spec) {
super(spec);
}
public String getWebSphereSpecificBit() {
}
}
Code (deployment descriptors) can then use the interface type EJB or
method calls on the specific part to return the generic bits, and the
Geronimo stuff separately. You'd probably also use a Visitor to be able
to generate the appropriate configuration files over a bridge.
> But this is the Geronimo project - so do we need to support both of
> these things? i.e. can't we just have a simple POJO hierarchy which
> merges the standard + geronimo POJOs together for simplicity? It'll be
> much easier, take less code & require much less testing of the
> marshalling code.
Probably don't need to, no, but a good design will allow for future
uses (e.g. the deployment code could be used to generate both Geronimo,
WebSphere and Weblogic descriptors at the same time in much the way
that XDoclet can) outside of Geronimo.
Alex.
Re: [XML][Deployment]POJO design?
Posted by James Strachan <ja...@yahoo.co.uk>.
What is the use case for having 'standard' beans separate from geronimo
beans - on't we just need Geronimo beans? i.e. it seems very complex to
have 2 separate trees of standard J2EE descriptors and another tree of
geronimo-extended J2EE descriptor beans. This leads to a messy
dual-inheritence hierarchy that Greg's brought up.
But this is the Geronimo project - so do we need to support both of
these things? i.e. can't we just have a simple POJO hierarchy which
merges the standard + geronimo POJOs together for simplicity? It'll be
much easier, take less code & require much less testing of the
marshalling code.
So I'd like to understand the use case for why we can't just have POJOs
for Geronimo's descriptors - afterall all the additional Geronimo
properties can just be ignored when working with just standard J2EE
descriptor stuff.
On Tuesday, September 9, 2003, at 09:50 am, Greg Wilkins wrote:
>
>
>
> Dain Sundstrom wrote:
>> On Tuesday, September 9, 2003, at 02:02 AM, Greg Wilkins wrote:
>>> Jeremy Boynes wrote:
>>> > I think a concrete class hierarchy is easiest here, with the
>>> Geronimo
>>> > POJOs extending the Standard ones. That way tools can work with
>>> standard
>>> > objects or geronimo objects as they like (provided they remain
>>> > consistent) - this fits Aaron's use cases and I think simplifies
>>> the
>>> > structure.
>>>
>>> That approach is going to result in some really ugly duplication
>>> of code and hundreds of extra implementation methods.
>> My god Greg, get a real IDE, and click the implement interface
>> button, or click the delegate button and done with it.
>
> you're joking right???
>
> This is not just about code duplication - I was just responding to the
> suggestion that my proposal is more complex or more code. The main
> issue
> that I started talking about is that the type hierarchy is wrong.
>
> Eg. If we don't have a common geronimo.ejb.EJB class for Session,
> Entity
> and Message, then we can't write any code that deals with these beans
> in
> common - eg we are going to have to write the marshalling code 3
> times, etc. etc.
>
> If the geronimo classes don't implement/extend the standard classes
> then
> we can't pass them into any class that takes the standard classes.
>
> So I am not proposing change based on code volume - I'm proposing
> change
> because the design is currently not correct.
>
> whatever.... I give up
>
>
>
>
>
>
>
>
James
-------
http://radio.weblogs.com/0112098/
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
Aaron Mulder wrote:
> On Tue, 9 Sep 2003, Alex Blewitt wrote:
> The rationale for not having geronimo.ejb.EJB (the abstract
> supertype for Session/Entity/Message beans) is that geronimo.ejb.Session
> can't extend it!
>
> That's why Greg is proposing that everything in J2EE land should
> turn into interfaces, but I continue to object to having all the
> implementation in the Geronimo objects only, especially since you STILL
> can't avoid duplicating code.
The rational for the interfaces and dual inheritance trees is not to
avoid code duplication with the POJOs - but code reduction is a benefit.
The main thing is that it allows the correct inheritance hierarchy to
be defined.
Thus I can write code that deals with a geronimo.ejb.EJB. Without the
correct inheritance tree, I may have to write the same code to deal
with geronimo.ejb.Session, g.e.Entity and g.e.MessageDriven
because they would not be subtypes of a common g.e.EJB. Our hand
crafted marshalling code is one example that comes to mind here!
Ditto for subtypes of the standard beans. Currently the geronimo.ejb.Ejb
is not a subtype of the standard EJB. Thus I can't pass the geronimo
object to code written against the standard API, even though all the
methods exist.
So my primary concern was to get the typing hierarchy correct.
The fact that both my proposals also reduce the code volume is bonus (and
a reflection that the type hierarchy is better).
> but I continue to object to having all the implementation in the Geronimo
> objects only.
Can you expand on your objections?
Note that my idea of removing the setters from the standard API was
probably not a good one, and we should be able to keep them there. So
code could be written against the standard APIs.
cheers
Re: [XML][Deployment]POJO design?
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Sep 9, 2003, at 14:28 Europe/London, Aaron Mulder wrote:
> Comments below...
>
> On Tue, 9 Sep 2003, Alex Blewitt wrote:
>> Why should session not be able to extend it? I don't understand:
>>
>> public interface EJB
>> public interface EntityBean extends EJB
>> public interface SessionBean extends EJB
>> public interface MessageDrivenBean extends EJB
>>
>> public class J2EEEJB implements EJB
>> public class J2EEEntityBean extends J2EEEJB implements EntityBean
>> public class J2EESessionBean extends J2EEEJB implements SessionBean
>> public class J2EEMessagDrivenBean extends J2EEEJB implements
>> MessageDrivenBean
>>
>> public class GeronimoEJB implements EJB
>> public class GeronimoEntityBean extends GeronimoEJB implements
>> EntityBean
>> public class GeronimoSessionBean extends GeronimoEJB implements
>> SessionBean
>> public class GeronimoMessageDrivenBean extends GeronimoEJB implements
>> MessageDrivenBean
>
>
> It does not make sense for GeronimoEJB to extend nothing, and for
> GeronimoEntityBean to extends GeronimoEJB. All the content that
> GeronimoEntityBean needs to inherit is in J2EEEntityBean.
I disagree with your thought that GeronimoEJB needs to subclass
something, or for the fact that GeronimoEntityBean is a subclass of
J2EEEntityBean.
This is a common issue on OO projects -- to use inheritance, or to use
composition. The right answer is almost always to use composition.
What you get with composition is the flexibility to change the
underlying structure at runtime (at either end). With inheritance, this
is a 1-1 fix and cannot be changed (one instance always has one
superclass instance). Such structures tend to result in somewhat ugly
copy-constructors that convert between the two types where necessary.
So I argue that it does entirely make sense for GeronimoEJB to extend
nothing, in the same way that the J2EEEJB extends nothing. It's a
composition relationship; a GeronimoEJB contains geronimo-specific
stuff and a reference to the non-specific J2EE object.
> The way you've
> set it up above, GeronimoEJB needs to duplicate all the code in
> J2EEEJB in
> order to implement the EJB interface, and likewise GeronimoEntityBean
> needs to duplicate the code in J2EEEntityBean, and so on. Whereas if
> GeronimoEntityBean extends J2EEEntityBean, all that is inherited not
> duplicated.
Not necessarily; if there were methods in the EJB that were required as
part of the standard, these could simply be forwarded to the
appropriate J2EE object:
interface EJB { public String getName(); }
class GeronimoEJB implements EJB {
public String getName() { getSpec().getName(); }
}
class J2EEEJB implements EJB {
public String getName() {
return name;
}
}
That way, no data is duplicated, and methods are simply delegated
through. This would only need to happen once and would be trivial to
set up using an IDE that generates delegation methods.
>> ...
>> I agree that there should be interfaces (hence above).
>
> I disagree; the interfaces add nothing, and require lots of code
> duplication. If GeronimoEJB extends J2EEEJB, then you can treat both
> types as a J2EEEJB without an interface.
Interfaces allow you to treat two different hierarchies as the same
type. If you merge them in to one hierarchy, the main reason for using
them disappears. So depending on which model goes forward, they may or
may not be necessary.
>> I also agree that the code shouldn't be in one place; it should be
>> split across the two hierarchies. The J2EE stuff should have the
>> vendor-neutral representation, the rest should go into the Geronimo
>> representation. And you can still achieve the transparent connection
>> by
>> providing delegate methods from the Geronimo stuff to the J2EE stuff.
> Yes, two sets of POJOs, one J2EE-only, one Geronimo-only. You can
> do this without interfaces (but with inheritance). See comments above.
It then becomes more difficult to write out a web-deployment descriptor
or Geronimo-deployment descriptor without assuming that (a) all
elements in a tree are J2EE ones, or (b) all elements in a tree are
Geronimo ones. With the dual-hierarchy approach, this isn't an issue at
all, and you simply use a Visitor to walk over the content.
>> If the above types don't gel, I can knock up a skeletal code example
>> for how to represent it, but my thoughts are that the representation
>> should be in a pair of POJOs, not just a single one.
>
> I understand your position, no code necessary. I simply disagree.
> Look at the GERONIMO-76 patch for the POJO hierarchy I'm recommending.
> Note that all of the Geronimo classes are virtually empty, though we
> need
> to introduce a few new ones to cover the references.
I don't think that a code sample will help fix the basic issue that I
have with your design. I simply disagree that it makes sense to merge
the two hierarchies into one, since it then results in a lot more work
in separating them out when you use them.
Remember; you only have to design a hierarchy ones. You get to use it a
lot of times throughout the code. Optimise the use, not the design.
Alex.
Re: [XML][Deployment]POJO design?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Comments below...
On Tue, 9 Sep 2003, Alex Blewitt wrote:
> Why should session not be able to extend it? I don't understand:
>
> public interface EJB
> public interface EntityBean extends EJB
> public interface SessionBean extends EJB
> public interface MessageDrivenBean extends EJB
>
> public class J2EEEJB implements EJB
> public class J2EEEntityBean extends J2EEEJB implements EntityBean
> public class J2EESessionBean extends J2EEEJB implements SessionBean
> public class J2EEMessagDrivenBean extends J2EEEJB implements
> MessageDrivenBean
>
> public class GeronimoEJB implements EJB
> public class GeronimoEntityBean extends GeronimoEJB implements
> EntityBean
> public class GeronimoSessionBean extends GeronimoEJB implements
> SessionBean
> public class GeronimoMessageDrivenBean extends GeronimoEJB implements
> MessageDrivenBean
It does not make sense for GeronimoEJB to extend nothing, and for
GeronimoEntityBean to extends GeronimoEJB. All the content that
GeronimoEntityBean needs to inherit is in J2EEEntityBean. The way you've
set it up above, GeronimoEJB needs to duplicate all the code in J2EEEJB in
order to implement the EJB interface, and likewise GeronimoEntityBean
needs to duplicate the code in J2EEEntityBean, and so on. Whereas if
GeronimoEntityBean extends J2EEEntityBean, all that is inherited not
duplicated.
> ...
> I agree that there should be interfaces (hence above).
I disagree; the interfaces add nothing, and require lots of code
duplication. If GeronimoEJB extends J2EEEJB, then you can treat both
types as a J2EEEJB without an interface.
> I also agree that the code shouldn't be in one place; it should be
> split across the two hierarchies. The J2EE stuff should have the
> vendor-neutral representation, the rest should go into the Geronimo
> representation. And you can still achieve the transparent connection by
> providing delegate methods from the Geronimo stuff to the J2EE stuff.
Yes, two sets of POJOs, one J2EE-only, one Geronimo-only. You can
do this without interfaces (but with inheritance). See comments above.
> If the above types don't gel, I can knock up a skeletal code example
> for how to represent it, but my thoughts are that the representation
> should be in a pair of POJOs, not just a single one.
I understand your position, no code necessary. I simply disagree.
Look at the GERONIMO-76 patch for the POJO hierarchy I'm recommending.
Note that all of the Geronimo classes are virtually empty, though we need
to introduce a few new ones to cover the references.
Aaron
Re: [XML][Deployment]POJO design?
Posted by Alex Blewitt <Al...@bandlem.com>.
On Tuesday, Sep 9, 2003, at 13:38 Europe/London, Aaron Mulder wrote:
> On Tue, 9 Sep 2003, Alex Blewitt wrote:
>> ...
>> I don't see the rationale for not having an abstract supertype for the
>> Session/Entity/Message beans. [It may be necessary to also have a
>> separate supertype for Session/Entity as well, since there are such
>> issues with the way in which the various Contexts work.]
>
> You can't have it both ways:
>
> j2ee.ejb.Session extends j2ee.ejb.EJB
> geronimo.ejb.EJB extends j2ee.ejb.EJB
> geronimo.ejb.Session extends (j2ee.ejb.Session and geronimo.ejb.EJB???)
I think perhaps I should have been clearer in the message; I had
suggested that we use an EJB super-interface to mean both the
geronimo-specific and j2ee neutral. That way, you can have two separate
hierarchies be used to represent implementation, whilst still
maintaining the type hierarchy on the top.
> The rationale for not having geronimo.ejb.EJB (the abstract
> supertype for Session/Entity/Message beans) is that
> geronimo.ejb.Session
> can't extend it!
Why should session not be able to extend it? I don't understand:
public interface EJB
public interface EntityBean extends EJB
public interface SessionBean extends EJB
public interface MessageDrivenBean extends EJB
public class J2EEEJB implements EJB
public class J2EEEntityBean extends J2EEEJB implements EntityBean
public class J2EESessionBean extends J2EEEJB implements SessionBean
public class J2EEMessagDrivenBean extends J2EEEJB implements
MessageDrivenBean
public class GeronimoEJB implements EJB
public class GeronimoEntityBean extends GeronimoEJB implements
EntityBean
public class GeronimoSessionBean extends GeronimoEJB implements
SessionBean
public class GeronimoMessageDrivenBean extends GeronimoEJB implements
MessageDrivenBean
and the GeronimoEJB has a 'to one' relationship with J2EEEJB.
So, it's possible to insert another interface/set of types
'EntityAndSessionBean' above; one more interface and two more classes:
public interface EntityAndSession
public class J2EEEntityAndSession extends J2EEEJB
public class GeronimoEntityAndSession extends GeronimoEJB
and change the 'extends GeronimoEJB' to 'extends
GeronimoEntityAndSession' for session/entities (and similarly for J2EE).
> That's why Greg is proposing that everything in J2EE land should
> turn into interfaces, but I continue to object to having all the
> implementation in the Geronimo objects only, especially since you STILL
> can't avoid duplicating code.
I agree that there should be interfaces (hence above).
I also agree that the code shouldn't be in one place; it should be
split across the two hierarchies. The J2EE stuff should have the
vendor-neutral representation, the rest should go into the Geronimo
representation. And you can still achieve the transparent connection by
providing delegate methods from the Geronimo stuff to the J2EE stuff.
If the above types don't gel, I can knock up a skeletal code example
for how to represent it, but my thoughts are that the representation
should be in a pair of POJOs, not just a single one.
Alex.
Re: [XML][Deployment]POJO design?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Tue, 9 Sep 2003, Alex Blewitt wrote:
> ...
> I don't see the rationale for not having an abstract supertype for the
> Session/Entity/Message beans. [It may be necessary to also have a
> separate supertype for Session/Entity as well, since there are such
> issues with the way in which the various Contexts work.]
You can't have it both ways:
j2ee.ejb.Session extends j2ee.ejb.EJB
geronimo.ejb.EJB extends j2ee.ejb.EJB
geronimo.ejb.Session extends (j2ee.ejb.Session and geronimo.ejb.EJB???)
The rationale for not having geronimo.ejb.EJB (the abstract
supertype for Session/Entity/Message beans) is that geronimo.ejb.Session
can't extend it!
That's why Greg is proposing that everything in J2EE land should
turn into interfaces, but I continue to object to having all the
implementation in the Geronimo objects only, especially since you STILL
can't avoid duplicating code.
Aaron
Re: [XML][Deployment]POJO design?
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Sep 9, 2003, at 09:50 Europe/London, Greg Wilkins wrote:
> Dain Sundstrom wrote:
>> On Tuesday, September 9, 2003, at 02:02 AM, Greg Wilkins wrote:
>>> Jeremy Boynes wrote:
>>> > I think a concrete class hierarchy is easiest here, with the
>>> Geronimo
>>> > POJOs extending the Standard ones. That way tools can work with
>>> standard
>>> > objects or geronimo objects as they like (provided they remain
>>> > consistent) - this fits Aaron's use cases and I think simplifies
>>> the
>>> > structure.
>>>
>>> That approach is going to result in some really ugly duplication
>>> of code and hundreds of extra implementation methods.
>> My god Greg, get a real IDE, and click the implement interface
>> button, or click the delegate button and done with it.
>
> you're joking right???
>
> This is not just about code duplication - I was just responding to the
> suggestion that my proposal is more complex or more code. The main
> issue
> that I started talking about is that the type hierarchy is wrong.
I'd agree completely with Greg's view here. It's not about inheritance
for the sake of it; it's about getting the type hierarchy right.
This can also be achieved with interfaces rather than classes, but I
don't see the rationale for not having an abstract supertype for the
Session/Entity/Message beans. [It may be necessary to also have a
separate supertype for Session/Entity as well, since there are such
issues with the way in which the various Contexts work.]
> So I am not proposing change based on code volume - I'm proposing
> change
> because the design is currently not correct.
+1
Alex.
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
Dain Sundstrom wrote:
> On Tuesday, September 9, 2003, at 02:02 AM, Greg Wilkins wrote:
>
>> Jeremy Boynes wrote:
>> > I think a concrete class hierarchy is easiest here, with the Geronimo
>> > POJOs extending the Standard ones. That way tools can work with
>> standard
>> > objects or geronimo objects as they like (provided they remain
>> > consistent) - this fits Aaron's use cases and I think simplifies the
>> > structure.
>>
>> That approach is going to result in some really ugly duplication
>> of code and hundreds of extra implementation methods.
>
>
> My god Greg, get a real IDE, and click the implement interface button,
> or click the delegate button and done with it.
you're joking right???
This is not just about code duplication - I was just responding to the
suggestion that my proposal is more complex or more code. The main issue
that I started talking about is that the type hierarchy is wrong.
Eg. If we don't have a common geronimo.ejb.EJB class for Session, Entity
and Message, then we can't write any code that deals with these beans in
common - eg we are going to have to write the marshalling code 3 times, etc. etc.
If the geronimo classes don't implement/extend the standard classes then
we can't pass them into any class that takes the standard classes.
So I am not proposing change based on code volume - I'm proposing change
because the design is currently not correct.
whatever.... I give up
Re: [XML][Deployment]POJO design?
Posted by Dain Sundstrom <da...@coredevelopers.net>.
On Tuesday, September 9, 2003, at 02:02 AM, Greg Wilkins wrote:
> Jeremy Boynes wrote:
> > I think a concrete class hierarchy is easiest here, with the Geronimo
> > POJOs extending the Standard ones. That way tools can work with
> standard
> > objects or geronimo objects as they like (provided they remain
> > consistent) - this fits Aaron's use cases and I think simplifies the
> > structure.
>
> That approach is going to result in some really ugly duplication
> of code and hundreds of extra implementation methods.
My god Greg, get a real IDE, and click the implement interface button,
or click the delegate button and done with it.
-dain
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
Jeremy Boynes wrote:
> I think a concrete class hierarchy is easiest here, with the Geronimo
> POJOs extending the Standard ones. That way tools can work with standard
> objects or geronimo objects as they like (provided they remain
> consistent) - this fits Aaron's use cases and I think simplifies the
> structure.
That approach is going to result in some really ugly duplication
of code and hundreds of extra implementation methods.
For example, the current implementation of o.a.g.d.m.g.ejb.MessageDriven is
public class MessageDriven extends Ejb {
}
Which is good, except that it does not implement/extend the standard EJB or
MessageDriven classes. So this is not a unified POJO tree. I'm proposing that
we change this to:
public class MessageDriven extends Ejb
implements o.a.g.d.m.ejb.MessageDriven
{
}
and remove the implementations from o.a.g.d.m.ejb.*. This is
simple and reduces our code volume. At the cost that we have
to use the geronimo instances of the POJOS (but can do so via
the standard interfaces if we wish).
If somebody really wants a non-geronimo version of the standard
interfaces, then we can provide implementations of them.
I think that what Jeremy & Aaron are proposing is that we change this to
public class MessageDriven extends o.a.g.d.m.ejb.MessageDriven
{
// reimplement all the array getters/setter & instance getter/setter for
// EjbRef
// ResourceRef
// ServiceRef
// EjbLocalRef
// JndiContextParam
// MessageDesination
// ResourceEnvRef
// SecurityRoleRef
// etc.
// to use geronimo object.
// reimplement them all again for type safe versions.
}
So that's at least 64 methods that need to be reimplemented.
And we can't reuse those implementations in Entity or Session, so
we have to reimplement them all over again -that's > 186 trivial methods
that we have cut and pasted by hand!!!
This can be simplified, if we don't reimplement the standard methods
and just store geronimo types in the base class arrays and fields.
But :
- we lose type safety (one of the reasons to use POJOs)
- the risk of having mixed trees is large
- we will have to write copy constructors for everything so we can
convert between standard trees and geronimo trees
- we have to have lots of explicit type checking and casting.
- if we add type safe methods, they will have to copy arrays
- We still have to have type safe impls replicated in Entity, MessageDriven
and Session.
> You had originally proposed additional methods like getGeronimoEjbRef()
> - what was wrong with them (apart from the name)? A user can use those
> or can cast the result from getEJBRef().
Because either we reimplement hundreds of methods or we end up
copying arrays every time the type safe methods are called.
> Have we made any progress on the names?
I've decided that progress is highly overrated and that I much prefer
to write long ranting emails:-) Sorry guys, but I am having trouble getting
into the "apache way" here. I don't want to do anything without consensus,
but I appear unable to reach consensus with anybody about anything - even
the neighbours cat is disagreeing with me about who is meant to feed it !-)
I did start the refactoring, but there is some code that relies
on the fact that EJB* comes from one package and Ejb* come from another.
So renaming all to EJB gives name clashes that need to be resolved
with package names. This is a lot of code to change and I would prefer
to remove most of it (as above) rather than fix it. So either we
need to reach consensus on the above or I have to stop worrying about it :-)
cheers
>>-----Original Message-----
>>From: Gmane Remailer [mailto:public=SUao4/DxUa3Z+VzJOa5vwg@public.gmane.org] On Behalf
>>Of Greg Wilkins
>>Sent: Monday, September 08, 2003 8:11 PM
>>To:
>>public-geronimo-dev=d1GL8uUpDdXTxqt0kkDzDmD2FQJk+8+b=8ByrlEUxsivZ+VzJOa5vwg@public.gmane.org
>>Subject: Re: [XML][Deployment]POJO design?
>>
>>
>>
>>
>>sorry,
>>
>>I tried to let this one go... but I can't... one more try :-)
>>
>>Aaron Mulder wrote:
>>
>>>>Or are you saying that we just just don't have a geronimo.ejb.EJB
>>>>class and multiple implement it's methods in geronimo.ejb.Session,
>>>>geronimo.ejb.Entity etc.
>>>
>>> Yes, I'm saying skip the geronimo.ejb.EJB. It would
>>
>>currently have
>>
>>>no properties beyond what ejb.EJB has, and later would support only
>>>the most basic (pool size perhaps?).
>>
>>But that does not work, because geronimo.ejb.EJB is need to
>>provide implementation of all the standard methods that
>>return the geronimo specific versions of EJBRef etc.
>>
>>If we don't have geronimo.ejb.EJB, then we have to implement
>>most the methods in most of the classes.
>>
>>
>>>>Note that as the Geronimo instances are the only concrete
>>
>>ones, then
>>
>>>>we will always be creating Geronimo objects. Thus I would propose
>>>>that the standards interfaces do not have setters, only getters.
>>>
>>> That is clearly unacceptable. You say above that I can use the
>>>J2EE interfaces to edit J2EE DDs, and below that the J2EE
>>
>>interfaces have
>>
>>>no setters.
>>
>>Why? We are writing geronimo code, so what it the problem with
>>creating geronimo versions of the DD POJOs? If you don't want to
>>do anything with the non-standard elements then don't set
>>them and don't render them in the XML.
>>
>>Note that jeremies current proposal has no difference between
>>the standard and vendor DD's anyway!
>>
>>
>>> But that aside, I still disagree with this approach.
>>
>>You're adding a
>>
>>>whole lot of complexity and baggage to save yourself the writing of
>>>getJndiName in more than one place. This is silly. Of the
>>
>>properties
>>
>>>that need to go in the Geronimo classes, about 5% would go
>>
>>in "EJB",
>>
>>>as opposed to 95% in "Session", "Entity", or
>>
>>"MessageDriven". If you
>>
>>>just leave out geronimo.ejb.EJB, then all these problems go away.
>>
>>No - the reason that the geronomo classes exist is to provide
>>typed versions of the methods, so you don't have to cast to
>>the geronimo specific instances all the time. If we are happy
>>with untyped interfaces - then let's just use DOM!
>>
>>I think my proposal is actually removing code and complexity.
>> We will only have concrete implementations for of geronimo
>>objects. There will be no standards only implementations, no
>>copy constructors to convert standard to geronimo, no
>>casting, no type checking before casting, no marshalling code
>>for standard only, etc.
>>
>>I am sure that we could get by without a standard version of
>>the DD POJOs and only use the G DD POJOs. But having the
>>standard interfaces is less code that we have already and at
>>least gives a good indication of what's standard and what's not.
>>
>>It seams bizarre to me that on one hand we are trying to
>>merge the standard and vender XML into a single file, but on
>>the other we are keeping separate implementations of the
>>elements as POJOs???
>>
>>cheers
>>
>>
>>
>>
>>
>>
>>
>
>
>
RE: [XML][Deployment]POJO design?
Posted by Jeremy Boynes <je...@coredevelopers.net>.
I think a concrete class hierarchy is easiest here, with the Geronimo
POJOs extending the Standard ones. That way tools can work with standard
objects or geronimo objects as they like (provided they remain
consistent) - this fits Aaron's use cases and I think simplifies the
structure.
You had originally proposed additional methods like getGeronimoEjbRef()
- what was wrong with them (apart from the name)? A user can use those
or can cast the result from getEJBRef().
Have we made any progress on the names?
Jeremy
> -----Original Message-----
> From: Gmane Remailer [mailto:public@main.gmane.org] On Behalf
> Of Greg Wilkins
> Sent: Monday, September 08, 2003 8:11 PM
> To:
> public-geronimo-dev=d1GL8uUpDdXTxqt0kkDzDmD2FQJk+8+b@ciao.gmane.org
> Subject: Re: [XML][Deployment]POJO design?
>
>
>
>
> sorry,
>
> I tried to let this one go... but I can't... one more try :-)
>
> Aaron Mulder wrote:
> >>Or are you saying that we just just don't have a geronimo.ejb.EJB
> >>class and multiple implement it's methods in geronimo.ejb.Session,
> >>geronimo.ejb.Entity etc.
> >
> > Yes, I'm saying skip the geronimo.ejb.EJB. It would
> currently have
> > no properties beyond what ejb.EJB has, and later would support only
> > the most basic (pool size perhaps?).
>
> But that does not work, because geronimo.ejb.EJB is need to
> provide implementation of all the standard methods that
> return the geronimo specific versions of EJBRef etc.
>
> If we don't have geronimo.ejb.EJB, then we have to implement
> most the methods in most of the classes.
>
> >>Note that as the Geronimo instances are the only concrete
> ones, then
> >>we will always be creating Geronimo objects. Thus I would propose
> >>that the standards interfaces do not have setters, only getters.
> >
> > That is clearly unacceptable. You say above that I can use the
> > J2EE interfaces to edit J2EE DDs, and below that the J2EE
> interfaces have
> > no setters.
>
> Why? We are writing geronimo code, so what it the problem with
> creating geronimo versions of the DD POJOs? If you don't want to
> do anything with the non-standard elements then don't set
> them and don't render them in the XML.
>
> Note that jeremies current proposal has no difference between
> the standard and vendor DD's anyway!
>
> > But that aside, I still disagree with this approach.
> You're adding a
> > whole lot of complexity and baggage to save yourself the writing of
> > getJndiName in more than one place. This is silly. Of the
> properties
> > that need to go in the Geronimo classes, about 5% would go
> in "EJB",
> > as opposed to 95% in "Session", "Entity", or
> "MessageDriven". If you
> > just leave out geronimo.ejb.EJB, then all these problems go away.
>
> No - the reason that the geronomo classes exist is to provide
> typed versions of the methods, so you don't have to cast to
> the geronimo specific instances all the time. If we are happy
> with untyped interfaces - then let's just use DOM!
>
> I think my proposal is actually removing code and complexity.
> We will only have concrete implementations for of geronimo
> objects. There will be no standards only implementations, no
> copy constructors to convert standard to geronimo, no
> casting, no type checking before casting, no marshalling code
> for standard only, etc.
>
> I am sure that we could get by without a standard version of
> the DD POJOs and only use the G DD POJOs. But having the
> standard interfaces is less code that we have already and at
> least gives a good indication of what's standard and what's not.
>
> It seams bizarre to me that on one hand we are trying to
> merge the standard and vender XML into a single file, but on
> the other we are keeping separate implementations of the
> elements as POJOs???
>
> cheers
>
>
>
>
>
>
>
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
sorry,
I tried to let this one go... but I can't... one more try :-)
Aaron Mulder wrote:
>>Or are you saying that we just just don't have a geronimo.ejb.EJB class
>>and multiple implement it's methods in geronimo.ejb.Session,
>>geronimo.ejb.Entity etc.
>
> Yes, I'm saying skip the geronimo.ejb.EJB. It would currently
> have no properties beyond what ejb.EJB has, and later would support only
> the most basic (pool size perhaps?).
But that does not work, because geronimo.ejb.EJB is need to provide
implementation of all the standard methods that return the geronimo
specific versions of EJBRef etc.
If we don't have geronimo.ejb.EJB, then we have to implement most the
methods in most of the classes.
>>Note that as the Geronimo instances are the only concrete ones,
>>then we will always be creating Geronimo objects. Thus I would
>>propose that the standards interfaces do not have setters, only
>>getters.
>
> That is clearly unacceptable. You say above that I can use the
> J2EE interfaces to edit J2EE DDs, and below that the J2EE interfaces have
> no setters.
Why? We are writing geronimo code, so what it the problem with
creating geronimo versions of the DD POJOs? If you don't want to
do anything with the non-standard elements then don't set them and
don't render them in the XML.
Note that jeremies current proposal has no difference between
the standard and vendor DD's anyway!
> But that aside, I still disagree with this approach. You're
> adding a whole lot of complexity and baggage to save yourself the writing
> of getJndiName in more than one place. This is silly. Of the properties
> that need to go in the Geronimo classes, about 5% would go in "EJB", as
> opposed to 95% in "Session", "Entity", or "MessageDriven". If you just
> leave out geronimo.ejb.EJB, then all these problems go away.
No - the reason that the geronomo classes exist is to provide typed versions
of the methods, so you don't have to cast to the geronimo specific instances
all the time. If we are happy with untyped interfaces - then let's just use DOM!
I think my proposal is actually removing code and complexity. We will only have
concrete implementations for of geronimo objects. There will be no
standards only implementations, no copy constructors to convert standard
to geronimo, no casting, no type checking before casting, no marshalling
code for standard only, etc.
I am sure that we could get by without a standard version of the DD POJOs
and only use the G DD POJOs. But having the standard interfaces is less code
that we have already and at least gives a good indication of what's standard
and what's not.
It seams bizarre to me that on one hand we are trying to merge the
standard and vender XML into a single file, but on the other we are
keeping separate implementations of the elements as POJOs???
cheers
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
Aaron,
I don't think my proposed approach was adding anything?
The classes all exist anyway, I'm just proposing moving the
implementations about a bit and cleaning up the inheritance tree
so that extend is used for geronimo classes and implement is used
for standards interfaces. It think it would have resulted in less code.
I find the current setup very confusing and it does not feel like a
unified standard+vendor structure to me. But it does not really effect
me much, as the web container POJOs are mostly standard anyway.
So if we are happy with it, I'll leave it alone.
cheers
Aaron Mulder wrote:
> On Tue, 9 Sep 2003, Greg Wilkins wrote:
>
>>>...Displayable->ejb.Ejb->ejb.RpcBean->ejb.Session->geronimo.ejb.Session
>>
>>But geronimo.ejb.Session should extend geronimo.ejb.EJB
>>
>>Or are you saying that we just just don't have a geronimo.ejb.EJB class
>>and multiple implement it's methods in geronimo.ejb.Session,
>>geronimo.ejb.Entity etc.
>
>
> Yes, I'm saying skip the geronimo.ejb.EJB. It would currently
> have no properties beyond what ejb.EJB has, and later would support only
> the most basic (pool size perhaps?). geronimo.ejb.RpcBean, if it existed,
> would have a JndiName. You're introducing an awful lot to avoid writing a
> very few properties in both Session and Entity -- it's really not worth
> it.
>
>
>>I don't know if that works as well as making the standard ones interfaces.
>>If the standard elements are interfaces, then I think we can implement
>>the POJOs with only a single implementation of every method. If the
>>standard elements are POJOs then we are going to have to do multiple
>>implementations methods on geronimo.ejb.EJB etc.
>
>
> I'm not sure I agree. Some classes have a description only. Some
> have a display name only. Others have a display name and a description.
> How can you have a single implementation of getDescription and
> getDisplayName?
>
>
>>There should be no problem generating the standard J2EE DDs using the
>>geronimo POJOs. You should be able to use the geronomo instances via
>>the standard interfaces and thus you will not know about the extra
>>geronimo methods unless you want to.
>
>
> Perhaps, but it seems like a bit of a runaround. If someone can
> edit both the J2EE and Geronimo DDs separately, then we have two complete
> Geronimo DD trees in memory? I don't think this is better.
>
>
>>So I still favour making the standard beans the interfaces. Just to
>>be clear, here is the code snippets that I'm proposing again.
>
>
> (code omitted)
>
>
>>Note that as the Geronimo instances are the only concrete ones,
>>then we will always be creating Geronimo objects. Thus I would
>>propose that the standards interfaces do not have setters, only
>>getters.
>
>
> That is clearly unacceptable. You say above that I can use the
> J2EE interfaces to edit J2EE DDs, and below that the J2EE interfaces have
> no setters.
>
> But that aside, I still disagree with this approach. You're
> adding a whole lot of complexity and baggage to save yourself the writing
> of getJndiName in more than one place. This is silly. Of the properties
> that need to go in the Geronimo classes, about 5% would go in "EJB", as
> opposed to 95% in "Session", "Entity", or "MessageDriven". If you just
> leave out geronimo.ejb.EJB, then all these problems go away.
>
> Aaron
>
>
Re: [XML][Deployment]POJO design?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Tue, 9 Sep 2003, Greg Wilkins wrote:
> > ...Displayable->ejb.Ejb->ejb.RpcBean->ejb.Session->geronimo.ejb.Session
>
> But geronimo.ejb.Session should extend geronimo.ejb.EJB
>
> Or are you saying that we just just don't have a geronimo.ejb.EJB class
> and multiple implement it's methods in geronimo.ejb.Session,
> geronimo.ejb.Entity etc.
Yes, I'm saying skip the geronimo.ejb.EJB. It would currently
have no properties beyond what ejb.EJB has, and later would support only
the most basic (pool size perhaps?). geronimo.ejb.RpcBean, if it existed,
would have a JndiName. You're introducing an awful lot to avoid writing a
very few properties in both Session and Entity -- it's really not worth
it.
> I don't know if that works as well as making the standard ones interfaces.
> If the standard elements are interfaces, then I think we can implement
> the POJOs with only a single implementation of every method. If the
> standard elements are POJOs then we are going to have to do multiple
> implementations methods on geronimo.ejb.EJB etc.
I'm not sure I agree. Some classes have a description only. Some
have a display name only. Others have a display name and a description.
How can you have a single implementation of getDescription and
getDisplayName?
> There should be no problem generating the standard J2EE DDs using the
> geronimo POJOs. You should be able to use the geronomo instances via
> the standard interfaces and thus you will not know about the extra
> geronimo methods unless you want to.
Perhaps, but it seems like a bit of a runaround. If someone can
edit both the J2EE and Geronimo DDs separately, then we have two complete
Geronimo DD trees in memory? I don't think this is better.
> So I still favour making the standard beans the interfaces. Just to
> be clear, here is the code snippets that I'm proposing again.
(code omitted)
> Note that as the Geronimo instances are the only concrete ones,
> then we will always be creating Geronimo objects. Thus I would
> propose that the standards interfaces do not have setters, only
> getters.
That is clearly unacceptable. You say above that I can use the
J2EE interfaces to edit J2EE DDs, and below that the J2EE interfaces have
no setters.
But that aside, I still disagree with this approach. You're
adding a whole lot of complexity and baggage to save yourself the writing
of getJndiName in more than one place. This is silly. Of the properties
that need to go in the Geronimo classes, about 5% would go in "EJB", as
opposed to 95% in "Session", "Entity", or "MessageDriven". If you just
leave out geronimo.ejb.EJB, then all these problems go away.
Aaron
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
Aaron
Aaron Mulder wrote:
> Let me address the Describable and Displayable issue first. They
> apply only to J2EE DDs (Geronimo has no additional requirements for *more*
> description, though it would inherit the J2EE descriptions). I added
> these strictly as a convenience, since loads of tags have descriptions and
> display names and so on, and I figured why not share a common
> implementation?
They are good classes/interfaces and I think they should be there.
But they need to be there in the geronimo instances also (even though
we may never actually use them :-) At the moment, some of the
geronimo classes do not inherit from anything that implements
Describable (eg geronimo.ejb.Ejb)
> If we're constrained for parent classes, then we should
> just copy the fields and properties into all the relavant classes, and
> declare an interface for them so the XML loader can treat them all the
> same. But I think these two are probably safe: it can go
> Object->Describable->Displayable->ejb.EjbJar->geronimo.ejb.EjbJar
That example is simple enough because EJBJar is a leaf of the tree.
But it does not work so well for nodes of the tree. see below.
> The "Ejb" and "RpcBean" classes are similar -- they just group
> fields and properties that would otherwise need to be copied into two or
> more subclasses. They can also be replaced by interfaces, but the J2EE
> ones are probably safe and the and the Geronimo ones probably need to be
> replaced, so it can go:
> ...Displayable->ejb.Ejb->ejb.RpcBean->ejb.Session->geronimo.ejb.Session
But geronimo.ejb.Session should extend geronimo.ejb.EJB
Or are you saying that we just just don't have a geronimo.ejb.EJB class
and multiple implement it's methods in geronimo.ejb.Session, geronimo.ejb.Entity
etc.
> All these superclasses were written before the idea came up to
> combine the Geronimo & J2EE bean trees,
Ah that explains a lot.
> but again I think it's just the
> extra Geronimo superclasses that need to be eliminated (and/or replaced
> with interfaces).
I don't know if that works as well as making the standard ones interfaces.
If the standard elements are interfaces, then I think we can implement
the POJOs with only a single implementation of every method. If the
standard elements are POJOs then we are going to have to do multiple
implementations methods on geronimo.ejb.EJB etc.
> Finally, I think we do want POJOs for the J2EE DDs alone, and then
> have the Geronimo ones extend those. The JSR-88 deployer tool is supposed
> to let you edit J2EE DDs (though it's not strictly required), and I
> suspect we'll want to make use of the J2EE POJOs for that.
There should be no problem generating the standard J2EE DDs using the
geronimo POJOs. You should be able to use the geronomo instances via
the standard interfaces and thus you will not know about the extra
geronimo methods unless you want to.
So I still favour making the standard beans the interfaces. Just to
be clear, here is the code snippets that I'm proposing again. I
now think that option 2a is best plus I think the geronimo classes
should be named Geronimo* to avoid needing o.a.g.d.m.g.ejb package
names to disambiguate the names.
package o.a.g.d.m.j2ee;
interface EJBRef extends Describable
{
public String getEJBLink();
...
}
package o.a.g.d.m.ejb;
interface EJB extends Describable
{
public EJBRef[] getEjbRef();
...
}
interface Entity extends EJB
{
...
}
package o.a.g.d.m.geronimo.j2ee;
class GeronimoEJBRef extends GeronimoDescribable implements EJBRef
{
String ejbLink; // standard implementation
String jndiName; // geronimo implementation
public String getEJBLink(){
return ejbLink;
}
public String getJndiName() {
return jndiName;
}
...
}
package o.a.g.d.m.geronimo.j2ee;
class GeronimoEJB extends GeronimoDescribable implements EJB
{
GeronimoEJBRef[] geronimoEjbRef;
public EJBRef[] getEjbRef() {
return geronimoEjbRef;
}
public GeronimoEJBRef[] getGeronimoEjbRef() {
return geronimoEjbRef;
}
...
}
class GeronimoEntity extends GeronimoEJB implements Entity
{
...
}
Note that as the Geronimo instances are the only concrete ones,
then we will always be creating Geronimo objects. Thus I would
propose that the standards interfaces do not have setters, only
getters.
cheers
RE: Is anybody working on J2EE deployment verifier ?
Posted by Srihari S <sr...@blr.pin.philips.com>.
I am also in the same dilemma and i my best guess is that it may not be
needed for implementing the J2ee product provider deployment apis. It will
be better if we start building a generic deployment tool..the code u have
written may
come handy there...the tool will require an implementation of Tool Provider
imterfaces specified in the
jsr 88 spec..working on the tool will also help in testing the server side
deployment components of
geronimo..i think the tool will be a better candidate to create..
-----Original Message-----
From: Siddhartha Chandurkar [mailto:siddharthachandurkar@yahoo.com]
Sent: Friday, September 12, 2003 4:23 PM
To: geronimo-dev@incubator.apache.org
Subject: RE: Is anybody working on J2EE deployment verifier ?
Hi,
I am almost done witht the implementation of
Verification of the Session Bean as per the new
Specification.
Is this really needed ... I dont have the totalistic
picture of Geronimo. Please let me know so that if it
is not necessary I can pick something else.
BR,
Siddhartha
--- Srihari S <sr...@blr.pin.philips.com> wrote:
> Hi
> Along with a couple of guys i had started on the
> design of it..but nothing
> came out of it.
> Nevertheless I have a design ready which i can
> share. But i think we must
> ask Aaron Mulder of its necessity
> since he is the one working on jsr 88 related stuff.
> Initially there was a
> lot of discussion on its need
> but later things chilled down..hope we can revive it
> if a need for such a
> component is felt by all!!!
> But early on we need to get some things clarified
> about how such a verifier
> would fit into the geronimo stack.
>
> -----Original Message-----
> From: Siddhartha Chandurkar
> [mailto:siddharthachandurkar@yahoo.com]
> Sent: Friday, September 12, 2003 2:51 PM
> To: geronimo-dev@incubator.apache.org
> Subject: Is anybody working on J2EE deployment
> verifier ?
>
>
> Hi,
> In the TODO list on the Wiki, It looks that the J2EE
> deployment Verifier hasnt been picked by anyone.
> Before starting to work on it I wanted to check if
> someone is already working on it. So that there is
> no
> duplication of work and I can pick up something
> else.
> Alternately if there is a Task Manager please send
> me
> the link so that I can check the statuses of vaious
> TODO's
>
> thanks & regards,
> /Siddhartha
> http://www.visioncodified.com
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site
> design software
> http://sitebuilder.yahoo.com
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
RE: Is anybody working on J2EE deployment verifier ?
Posted by Siddhartha Chandurkar <si...@yahoo.com>.
Hi,
I am almost done witht the implementation of
Verification of the Session Bean as per the new
Specification.
Is this really needed ... I dont have the totalistic
picture of Geronimo. Please let me know so that if it
is not necessary I can pick something else.
BR,
Siddhartha
--- Srihari S <sr...@blr.pin.philips.com> wrote:
> Hi
> Along with a couple of guys i had started on the
> design of it..but nothing
> came out of it.
> Nevertheless I have a design ready which i can
> share. But i think we must
> ask Aaron Mulder of its necessity
> since he is the one working on jsr 88 related stuff.
> Initially there was a
> lot of discussion on its need
> but later things chilled down..hope we can revive it
> if a need for such a
> component is felt by all!!!
> But early on we need to get some things clarified
> about how such a verifier
> would fit into the geronimo stack.
>
> -----Original Message-----
> From: Siddhartha Chandurkar
> [mailto:siddharthachandurkar@yahoo.com]
> Sent: Friday, September 12, 2003 2:51 PM
> To: geronimo-dev@incubator.apache.org
> Subject: Is anybody working on J2EE deployment
> verifier ?
>
>
> Hi,
> In the TODO list on the Wiki, It looks that the J2EE
> deployment Verifier hasnt been picked by anyone.
> Before starting to work on it I wanted to check if
> someone is already working on it. So that there is
> no
> duplication of work and I can pick up something
> else.
> Alternately if there is a Task Manager please send
> me
> the link so that I can check the statuses of vaious
> TODO's
>
> thanks & regards,
> /Siddhartha
> http://www.visioncodified.com
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site
> design software
> http://sitebuilder.yahoo.com
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
RE: Is anybody working on J2EE deployment verifier ?
Posted by Srihari S <sr...@blr.pin.philips.com>.
Hi
Along with a couple of guys i had started on the design of it..but nothing
came out of it.
Nevertheless I have a design ready which i can share. But i think we must
ask Aaron Mulder of its necessity
since he is the one working on jsr 88 related stuff. Initially there was a
lot of discussion on its need
but later things chilled down..hope we can revive it if a need for such a
component is felt by all!!!
But early on we need to get some things clarified about how such a verifier
would fit into the geronimo stack.
-----Original Message-----
From: Siddhartha Chandurkar [mailto:siddharthachandurkar@yahoo.com]
Sent: Friday, September 12, 2003 2:51 PM
To: geronimo-dev@incubator.apache.org
Subject: Is anybody working on J2EE deployment verifier ?
Hi,
In the TODO list on the Wiki, It looks that the J2EE
deployment Verifier hasnt been picked by anyone.
Before starting to work on it I wanted to check if
someone is already working on it. So that there is no
duplication of work and I can pick up something else.
Alternately if there is a Task Manager please send me
the link so that I can check the statuses of vaious
TODO's
thanks & regards,
/Siddhartha
http://www.visioncodified.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: Is anybody working on J2EE deployment verifier ?
Posted by Siddhartha Chandurkar <si...@yahoo.com>.
Hi Aaron,
Great! Since I have already written most of the code
for SessionBean I will reuse that code and put it in
the Validator and send the patch.
BR,
/Siddhartha
http://www.visioncodified.com
--- Aaron Mulder <am...@alumni.princeton.edu>
wrote:
> The framework for a verifier is there (see
> o.a.g.validator in the
> core module). All that needs to be done is
> implement tests. A sample
> test class is available:
> o.a.g.validator.ejb.SessionBeanTests (though it
> doesn't test much as of yet). There is also a Wiki
> page describing the
> validator and how to write tests:
>
>
http://wiki.codehaus.org/geronimo/Architecture/Validator
>
> We do need to improve the validator a bit yet,
> since right now it
> doesn't look up the messages in a resource bundle or
> format parameterized
> messages, but the hooks for that are there. So if
> you wanted to
> contribute to the validator itself, you could send
> in a patch for that
> feature.
>
> Aaron
>
> On Fri, 12 Sep 2003, Siddhartha Chandurkar wrote:
> > Hi,
> > In the TODO list on the Wiki, It looks that the
> J2EE
> > deployment Verifier hasnt been picked by anyone.
> > Before starting to work on it I wanted to check if
> > someone is already working on it. So that there is
> no
> > duplication of work and I can pick up something
> else.
> > Alternately if there is a Task Manager please send
> me
> > the link so that I can check the statuses of
> vaious
> > TODO's
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: Is anybody working on J2EE deployment verifier ?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
The framework for a verifier is there (see o.a.g.validator in the
core module). All that needs to be done is implement tests. A sample
test class is available: o.a.g.validator.ejb.SessionBeanTests (though it
doesn't test much as of yet). There is also a Wiki page describing the
validator and how to write tests:
http://wiki.codehaus.org/geronimo/Architecture/Validator
We do need to improve the validator a bit yet, since right now it
doesn't look up the messages in a resource bundle or format parameterized
messages, but the hooks for that are there. So if you wanted to
contribute to the validator itself, you could send in a patch for that
feature.
Aaron
On Fri, 12 Sep 2003, Siddhartha Chandurkar wrote:
> Hi,
> In the TODO list on the Wiki, It looks that the J2EE
> deployment Verifier hasnt been picked by anyone.
> Before starting to work on it I wanted to check if
> someone is already working on it. So that there is no
> duplication of work and I can pick up something else.
> Alternately if there is a Task Manager please send me
> the link so that I can check the statuses of vaious
> TODO's
Is anybody working on J2EE deployment verifier ?
Posted by Siddhartha Chandurkar <si...@yahoo.com>.
Hi,
In the TODO list on the Wiki, It looks that the J2EE
deployment Verifier hasnt been picked by anyone.
Before starting to work on it I wanted to check if
someone is already working on it. So that there is no
duplication of work and I can pick up something else.
Alternately if there is a Task Manager please send me
the link so that I can check the statuses of vaious
TODO's
thanks & regards,
/Siddhartha
http://www.visioncodified.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
list far of prefix's that are in elements that get capitalized in the POJOs
Cmr --> CMR
Cmp --> CMP
Ejb --> EJB
Jndi --> JNDI
Jsp --> JSP
Mime --> MIME
Also changing - but that is not in the xml
Rpc --> RPC
Greg Wilkins wrote:
>
>
> The name changes that I have been putting into my patch have all been
>
> Ejb --> EJB
> Cmr --> CMR
>
> I'll try extra a list shortly.
>
> cheers
>
>
> Aaron Mulder wrote:
>
>> On Mon, 8 Sep 2003, Jeremy Boynes wrote:
>>
>>> Please make sure you use all-caps as per the coding convention e.g.
>>> EJBRef.
>>> This was something I start to fix, but had problems with CVS on Windows
>>> which considers EjbRef and EJBRef so be the same file :-(
>>
>>
>>
>> Can you compile a list of namse where foo-bar doesn't become
>> FooBar? Or is it just "EJB" and "JSP" that we have to worry about? We
>> have a little translation routine to turn an XML XPath into a POJO XPath
>> (currently o.a.g.validator.AbstractValidator#javify) so we can use
>> JXPath,
>> and I suspect it will need to be updated accordingly.
>>
>> Aaron
>>
>>
>
>
>
>
Re: [XML][Deployment]POJO design?
Posted by Greg Wilkins <gr...@mortbay.com>.
The name changes that I have been putting into my patch have all been
Ejb --> EJB
Cmr --> CMR
I'll try extra a list shortly.
cheers
Aaron Mulder wrote:
> On Mon, 8 Sep 2003, Jeremy Boynes wrote:
>
>>Please make sure you use all-caps as per the coding convention e.g. EJBRef.
>>This was something I start to fix, but had problems with CVS on Windows
>>which considers EjbRef and EJBRef so be the same file :-(
>
>
> Can you compile a list of namse where foo-bar doesn't become
> FooBar? Or is it just "EJB" and "JSP" that we have to worry about? We
> have a little translation routine to turn an XML XPath into a POJO XPath
> (currently o.a.g.validator.AbstractValidator#javify) so we can use JXPath,
> and I suspect it will need to be updated accordingly.
>
> Aaron
>
>
RE: [XML][Deployment]POJO design?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Mon, 8 Sep 2003, Jeremy Boynes wrote:
> Please make sure you use all-caps as per the coding convention e.g. EJBRef.
> This was something I start to fix, but had problems with CVS on Windows
> which considers EjbRef and EJBRef so be the same file :-(
Can you compile a list of namse where foo-bar doesn't become
FooBar? Or is it just "EJB" and "JSP" that we have to worry about? We
have a little translation routine to turn an XML XPath into a POJO XPath
(currently o.a.g.validator.AbstractValidator#javify) so we can use JXPath,
and I suspect it will need to be updated accordingly.
Aaron
RE: [XML][Deployment]POJO design?
Posted by Jeremy Boynes <je...@coredevelopers.net>.
The quickie first:
> There are also a few naming convention problems that need to be
> fixed (we have both EjbRef and EJBRef and some field names EJBRef instead
> of ejbRef). I'll start fixing these while we decide what to do about the
> rest of this.
>
Please make sure you use all-caps as per the coding convention e.g. EJBRef.
This was something I start to fix, but had problems with CVS on Windows
which considers EjbRef and EJBRef so be the same file :-(
--
Jeremy
Re: [XML][Deployment]POJO design?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Let me address the Describable and Displayable issue first. They
apply only to J2EE DDs (Geronimo has no additional requirements for *more*
description, though it would inherit the J2EE descriptions). I added
these strictly as a convenience, since loads of tags have descriptions and
display names and so on, and I figured why not share a common
implementation? If we're constrained for parent classes, then we should
just copy the fields and properties into all the relavant classes, and
declare an interface for them so the XML loader can treat them all the
same. But I think these two are probably safe: it can go
Object->Describable->Displayable->ejb.EjbJar->geronimo.ejb.EjbJar
The "Ejb" and "RpcBean" classes are similar -- they just group
fields and properties that would otherwise need to be copied into two or
more subclasses. They can also be replaced by interfaces, but the J2EE
ones are probably safe and the and the Geronimo ones probably need to be
replaced, so it can go:
...Displayable->ejb.Ejb->ejb.RpcBean->ejb.Session->geronimo.ejb.Session
All these superclasses were written before the idea came up to
combine the Geronimo & J2EE bean trees, but again I think it's just the
extra Geronimo superclasses that need to be eliminated (and/or replaced
with interfaces).
Finally, I think we do want POJOs for the J2EE DDs alone, and then
have the Geronimo ones extend those. The JSR-88 deployer tool is supposed
to let you edit J2EE DDs (though it's not strictly required), and I
suspect we'll want to make use of the J2EE POJOs for that. Right now we
use JDOM for read-only access, and I don't think that will work well for
read-write access, since (if you dig a little) the DDBeans may be
different for every DConfigBean implementation, but we need some standard
set of JavaBeans available to construct "editor screens".
Aaron
On Tue, 9 Sep 2003, Greg Wilkins wrote:
> I'm looking at the POJOs for the deployment descriptors and I'm a
> little confused by their design and what conventions they are meant
> to follow.
>
> The source of my confusion is that there are two inheritance
> hierarchies that are partially implemented in the POJOs
>
> One hierarchy is the standard typing of elements :
>
> ejb.Entity is-a ejb.RpcBean is-a ejb.Ejb is-a j2ee.Displayable is-a Describable
>
> The other is the vendor typing of elements :
>
> geronimo.j2ee.EjbRef is-a j2ee.EJBRef
> geronimo.web.WebApp is-a web.AbstractWebApp
>
> But as multiple inheritance is not supported in java classes, the hierarchies
> are not complete. For example:
>
> geronimo.ejb.Entity is-NOT-a ejb.Entity
> geronimo.ejb.Ejb is-NOT-a ejb.Ejb
>
> I work out if there is a pattern for when which hierarchy is used?
> And there are strange artifacts of this. eg
>
> + multiple implementations of methods like *.Ejb.getEjbLocalRef
>
> + methods like j2ee.Describable.getDescription() are not available
> on geronimo.ejb.Ejb, which is NOT a ejb.Ejb (which is a j2ee.Describable).
>
> The basic problem here is that we just can't implement both
> inheritance hierachies in java. So my question is should we try?
>
> Do we actually need concrete classes in the o.a.g.deployment.model.* packages?
> We will always be constructing o.a.g.deployment.model.geronimo.* instances
> so do we need classes like ejb.Ejb, as we will always create geronimo.ejb.Ejb?
>
>
> So I think that either
>
> 0) there is some pattern that I am missing about which hierarchy to use?
> in which case we need to document what that is.
>
> 1) we just don't bother with the o.a.g.deployment.model.* versions
>
> 2) We make the o.a.g.deployment.model.* versions interfaces so that we
> can multiply inherit them
>
>
> 1) is simpler and type safe, but does not indicate what is standard and
> what is not.
>
> I think 2) should work ok and we would end up with things like:
>
> class Entity extends Ejb
> implements o.a.g.deployment.model.ejb.Entity
> {
> ...
> }
>
> The main problem with this approach is that methods like
> getEjbRef() will return a o.a.g.deployment.model.ejb.Ejb[]
> and we will have to cast to o.a.g.deployment.model.geronimo.ejb.Ejb
> in order to get the geronimo specific methods.
>
> Alternately we could double up the methods (which we have done anyway):
>
> class Ejb extends Entity implements o.a.g.d.m.ejb.Ejb
> {
> EjbRef[] ejbRef;
>
> EjbRef[] getGeronimoEjbRef() {
> return ejbRef;
> }
>
> o.a.g.d.m.ejb.EjbRef getEjbRef() {
> return ejbRef;
> }
> ...
> }
>
> Let's call this option 2a)
>
> Or we could we could just do 1):
>
> class Ejb extends Entity
> {
> EjbRef[] ejbRef;
>
> EjbRef[] getEjbRef() {
> return ejbRef;
> }
>
> ...
> }
>
>
> I'm a bit cautious about starting to fix this as I'm unclear about
> exactly what XML tools we are intending to eventually use and what
> conventions they require of the POJOs. I'm guessing we still have no tools
> set selected, so we should be able to do anything?
>
> In which case, I propose that we/I start working towards 2).
> This can be easily extended to 2a) or 1) if we decide we want more type
> safety and less casting. I think 2a) is probably the best compromise
> between having a standards structure and vendor type safety.
>
> There are also a few naming convention problems that need to be
> fixed (we have both EjbRef and EJBRef and some field names EJBRef instead
> of ejbRef). I'll start fixing these while we decide what to do about the
> rest of this.
>
> cheers
>
>
>
>
>
>
>
>
>
>
>
>
>