J2EE DeploymentManager ( was J2EE deployment verifier)

["Weston M. Price" <we...@yahoo.com>]

Just thought I should start a new thread....

My KMail was getting dominated!

Weston

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

[Jonathan Duty <jd...@jonandkerry.com>]

I'm here.  I was looking at the current code in cvs, it doesn't look 
like they have done much with deployment.  None of the classes in there 
implement the needed interfaces.

~Jonathan

Weston M. Price wrote:

>Any of you guys around?
>
>Weston
>
>On Monday 11 August 2003 05:25 pm, Weston M. Price wrote:
>  
>
>>Just thought I should start a new thread....
>>
>>My KMail was getting dominated!
>>
>>Weston
>>    
>>

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

[Chris Opacki <ch...@yahoo.com>]

I've been out of business since last night. sorry
guys. I'll be ready to do some serious activities
tomorrow after work.

--- "Weston M. Price" <we...@yahoo.com> wrote:
> Any of you guys around?
> 
> Weston
> 
> On Monday 11 August 2003 05:25 pm, Weston M. Price
> wrote:
> > Just thought I should start a new thread....
> >
> > My KMail was getting dominated!
> >
> > Weston


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

["Weston M. Price" <we...@yahoo.com>]

Any of you guys around?

Weston

On Monday 11 August 2003 05:25 pm, Weston M. Price wrote:
> Just thought I should start a new thread....
>
> My KMail was getting dominated!
>
> Weston

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

[Jonathan Duty <jd...@jonandkerry.com>]

I noticed in the current repository that there is a deployment package 
with some classes/interfaces in there.  Anyone know what those are for?

modules/core/src/java/org/apache/geronimo/deployment
DeployerMBean.java
DeploymentController.java
DeploymentControllerMBean.java
DeploymentException.java
DeploymentInfo.java
DeploymentInfoMBean.java
DeploymentPlannerMBean.java

~Jonathan

Weston M. Price wrote:

>Just thought I should start a new thread....
>
>My KMail was getting dominated!
>
>Weston
>  
>

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

[Jonathan Duty <jd...@jonandkerry.com>]

That should be maven ;)
~Jonathan

Jonathan Duty wrote:

> Lets get some momentum going by creating a module in the cvs package.  
> I'll generate the Melvin project. What do we want to call it?  Lets 
> get some ideas.
>
> ~Jonathan
>
> Weston M. Price wrote:
>
>> Just thought I should start a new thread....
>>
>> My KMail was getting dominated!
>>
>> Weston
>>  
>>

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

[Jonathan Duty <jd...@jonandkerry.com>]

Lets get some momentum going by creating a module in the cvs package.  
I'll generate the Melvin project. What do we want to call it?  Lets get 
some ideas.

~Jonathan

Weston M. Price wrote:

>Just thought I should start a new thread....
>
>My KMail was getting dominated!
>
>Weston
>  
>

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

[Jonathan Duty <jd...@jonandkerry.com>]

Hi all,
There was another thread where someone was talking about using 
commons-modeler to have the DeploymentEngine  talk to Jmx Management 
beans.  After looking at this here is a nother picture visualizing this.

~Jonathan

Weston M. Price wrote:

>Just thought I should start a new thread....
>
>My KMail was getting dominated!
>
>Weston
>  
>

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

[Jonathan Duty <jd...@jonandkerry.com>]

Hey All,
I added some text to the Deployment Wiki.
http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/Deployment

~Jonathan


Weston M. Price wrote:

>Just thought I should start a new thread....
>
>My KMail was getting dominated!
>
>Weston
>  
>

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

["Weston M. Price" <we...@yahoo.com>]

Did you guys see that I added a Wiki page for deployment?

Weston

On Tuesday 12 August 2003 02:06 pm, Jonathan Duty wrote:
> So I read the documentation last night.   It looks like the verification
> engine will be a subset of the functionality of the J2EE product
> providor...
>
> I.E. basically does everything but call the vendor-specific mechanisms
> to the J2EE platform.  The deployment engine module would then further
> implement this package to actually interface with the J2EE platform
> mechanisms (actually deploy the thing).
>
> Once again, I've included a picture (what can I say, I'm a UML buff)
>
> ~Jonathan
>
> Weston M. Price wrote:
> >Just thought I should start a new thread....
> >
> >My KMail was getting dominated!
> >
> >Weston

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

[Jonathan Duty <jd...@jonandkerry.com>]

So I read the documentation last night.   It looks like the verification 
engine will be a subset of the functionality of the J2EE product 
providor...

I.E. basically does everything but call the vendor-specific mechanisms 
to the J2EE platform.  The deployment engine module would then further 
implement this package to actually interface with the J2EE platform 
mechanisms (actually deploy the thing).

Once again, I've included a picture (what can I say, I'm a UML buff)

~Jonathan

Weston M. Price wrote:

>Just thought I should start a new thread....
>
>My KMail was getting dominated!
>
>Weston
>  
>

RE: Broken build?

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

Without the dependencies in the top level, the classpath does not get
set up and compile fails.

--
Jeremy

> -----Original Message-----
> From: Jason Dillon [mailto:jason@coredevelopers.net] 
> Sent: Tuesday, August 12, 2003 11:54 PM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: Broken build?
> 
> 
> What is broken specifically?
> 
> --jason
> 
> 
> On Wednesday, August 13, 2003, at 02:58  AM, Jeremy Boynes wrote:
> 
> > I made a quick hack to the top level project.xml to add the
> > dependencies
> > backin. It now builds from the top level again.
> >
> > Something is wrong in the way the reactor is working, but I 
> don't know 
> > enough maven to fix it.
> >
> > --
> > Jeremy
> >
> >> -----Original Message-----
> >> From: Jeremy Boynes [mailto:jeremy@coredevelopers.net]
> >> Sent: Tuesday, August 12, 2003 12:41 PM
> >> To: geronimo-dev@incubator.apache.org
> >> Subject: RE: Broken build?
> >>
> >>
> >> It's broken
> >>
> >>> -----Original Message-----
> >>> From: Daniel Farinha [mailto:daniel@ktorn.com]
> >>> Sent: Tuesday, August 12, 2003 12:20 PM
> >>> To: geronimo-dev@incubator.apache.org
> >>> Subject: Broken build?
> >>>
> >>>
> >>> Is it just me or the build is now broken?
> >>>
> >>> Daniel Farinha
> >>>
> >>>
> >>
> >
> 
> 

Re: Broken build?

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

What is broken specifically?

--jason


On Wednesday, August 13, 2003, at 02:58  AM, Jeremy Boynes wrote:

> I made a quick hack to the top level project.xml to add the 
> dependencies
> backin. It now builds from the top level again.
>
> Something is wrong in the way the reactor is working, but I don't know
> enough maven to fix it.
>
> --
> Jeremy
>
>> -----Original Message-----
>> From: Jeremy Boynes [mailto:jeremy@coredevelopers.net]
>> Sent: Tuesday, August 12, 2003 12:41 PM
>> To: geronimo-dev@incubator.apache.org
>> Subject: RE: Broken build?
>>
>>
>> It's broken
>>
>>> -----Original Message-----
>>> From: Daniel Farinha [mailto:daniel@ktorn.com]
>>> Sent: Tuesday, August 12, 2003 12:20 PM
>>> To: geronimo-dev@incubator.apache.org
>>> Subject: Broken build?
>>>
>>>
>>> Is it just me or the build is now broken?
>>>
>>> Daniel Farinha
>>>
>>>
>>
>

RE: Broken build?

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

I made a quick hack to the top level project.xml to add the dependencies
backin. It now builds from the top level again.

Something is wrong in the way the reactor is working, but I don't know
enough maven to fix it.

--
Jeremy

> -----Original Message-----
> From: Jeremy Boynes [mailto:jeremy@coredevelopers.net]
> Sent: Tuesday, August 12, 2003 12:41 PM
> To: geronimo-dev@incubator.apache.org
> Subject: RE: Broken build?
>
>
> It's broken
>
> > -----Original Message-----
> > From: Daniel Farinha [mailto:daniel@ktorn.com]
> > Sent: Tuesday, August 12, 2003 12:20 PM
> > To: geronimo-dev@incubator.apache.org
> > Subject: Broken build?
> >
> >
> > Is it just me or the build is now broken?
> >
> > Daniel Farinha
> >
> >
>

RE: Broken build?

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

It's broken

> -----Original Message-----
> From: Daniel Farinha [mailto:daniel@ktorn.com]
> Sent: Tuesday, August 12, 2003 12:20 PM
> To: geronimo-dev@incubator.apache.org
> Subject: Broken build?
> 
> 
> Is it just me or the build is now broken?
> 
> Daniel Farinha
> 
> 

Re: Broken build?

[Bruce Snyder <fe...@frii.com>]

This one time, at band camp, Daniel Farinha said:

DF>Is it just me or the build is now broken?

Yes, it appears that the build is broken. See the maven.log file for
details on the breakage. It appears that the breakage is deep in the
parsing of some XML.

Bruce
-- 
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'

The Castor Project 
http://www.castor.org/

Apache Geronimo 
http://incubator.apache.org/projects/geronimo.html

Broken build?

[Daniel Farinha <da...@ktorn.com>]

Is it just me or the build is now broken?

Daniel Farinha

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

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

Please can we keep most of the design discussion on the list or on the wiki
so everyone can see. If you do have an IM conversation, please post a
summary back to the list/wiki.

Thanks
--
Jeremy

> -----Original Message-----
> From: Chris Opacki [mailto:chris_opacki@yahoo.com]
> Sent: Tuesday, August 12, 2003 3:41 PM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: J2EE DeploymentManager ( was J2EE deployment verifier)
>
>
> aim: soc4   im only on that one at night EST though
>
> --- Jonathan Duty <jd...@jonandkerry.com> wrote:
> > aim: dutyman3
> >
> > Weston M. Price wrote:
> >
> > >Are any of you guys on IM accounts?
> > >
> > >Weston
> > >
> > >On Monday 11 August 2003 05:25 pm, Weston M. Price
> > wrote:
> > >
> > >
> > >>Just thought I should start a new thread....
> > >>
> > >>My KMail was getting dominated!
> > >>
> > >>Weston
> > >>
> > >>
> >
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

[Chris Opacki <ch...@yahoo.com>]

aim: soc4   im only on that one at night EST though

--- Jonathan Duty <jd...@jonandkerry.com> wrote:
> aim: dutyman3
> 
> Weston M. Price wrote:
> 
> >Are any of you guys on IM accounts? 
> >
> >Weston
> >
> >On Monday 11 August 2003 05:25 pm, Weston M. Price
> wrote:
> >  
> >
> >>Just thought I should start a new thread....
> >>
> >>My KMail was getting dominated!
> >>
> >>Weston
> >>    
> >>
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

[Jonathan Duty <jd...@jonandkerry.com>]

aim: dutyman3

Weston M. Price wrote:

>Are any of you guys on IM accounts? 
>
>Weston
>
>On Monday 11 August 2003 05:25 pm, Weston M. Price wrote:
>  
>
>>Just thought I should start a new thread....
>>
>>My KMail was getting dominated!
>>
>>Weston
>>    
>>

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

[Chris Opacki <ch...@yahoo.com>]

yahoo --  thebeanologist


--- "Weston M. Price" <we...@yahoo.com> wrote:
> Are any of you guys on IM accounts? 
> 
> Weston
> 
> On Monday 11 August 2003 05:25 pm, Weston M. Price
> wrote:
> > Just thought I should start a new thread....
> >
> > My KMail was getting dominated!
> >
> > Weston


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

["Weston M. Price" <we...@yahoo.com>]

Are any of you guys on IM accounts? 

Weston

On Monday 11 August 2003 05:25 pm, Weston M. Price wrote:
> Just thought I should start a new thread....
>
> My KMail was getting dominated!
>
> Weston

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

[Chris Opacki <ch...@yahoo.com>]

Yes. I have moved my thinking in that direction.
JSR-88
stuff really doesn't need to know about the
verification process.

--- "Weston M. Price" <we...@yahoo.com> wrote:
> I agree with Srihari in that the Verification
> manager does not have to 
> implement the spec interfaces, however, the
> DeploymentManager does, this 
> would be where we would implment DDRoot, DDConfig
> etc.....in some ways the 
> DeploymentManager would just use the services of the
> VerificatinoEngine as 
> one step in the process of actual deployment. 
> 
> Is this in line with what you guys were thinking?
> 
> 
> On Wednesday 13 August 2003 01:52 pm, Jonathan Duty
> wrote:
> > When we implement this module, we could actually
> implement it to exactly
> > follow the API specs (JSR 88).  That means
> implementing the
> > DeploymentManager interface on top of it and such.
>  That way any
> > application (ant, Eclipse, etc) that is equipped
> to deploy packages
> > could interface with it.  It would just fall short
> of actually
> > communicating with MBeans and deploying the
> package.
> >
> > When this module is used internally (within the
> REAL deployment manager)
> > it could just bypass or override the
> Verification's Deployment manager.
> >
> > ~Jonathan
> >
> >
> > -----Original Message-----
> > From: Srihari S
> [mailto:sriharis@blr.pin.philips.com]
> > Sent: Wednesday, August 13, 2003 9:43 AM
> > To: geronimo-dev@incubator.apache.org;
> weston_p@yahoo.com
> > Subject: RE: J2EE DeploymentManager ( was J2EE
> deployment verifier)
> >
> > Hi All
> >   When I was going thru the deployment api spec I
> thought it would be
> > good
> > to bring up some points:
> >
> > From a preliminary reading of the spec i saw there
> are no apis
> > explicitly
> > designed to do the verification
> > of a deployable unit. From this I infer that the
> verifier can be an
> > internal
> > module which could be used
> > by the deploy tool. So we could go full steam on
> its design and
> > implementation. In this regard I am trying to
> > jot the list of checks that our verifier will have
> to do (This is
> > mentioned
> > in the j2ee specs).
> > So in a way it will be equivalent to arriving at
> requirement specs for
> > the
> > verifier.
> > With the list of dos and donts that a verifier has
> to achieve we could
> > go
> > abt with design.Also the design of
> > ant hooks can be taken care.Can we??
> >
> > Next is something abt the big picture. Certainly
> the verifer is a small
> > part
> > of the deployment process.
> > But to achieve compliance we will have to
> implement the deployment spec
> > as a
> > whole. Has anyone given
> > thought to this issue?
> >
> > regards
> > Hari
> >
> >
> >
> > -----Original Message-----
> > From: Weston M. Price [mailto:weston_p@yahoo.com]
> > Sent: Wednesday, August 13, 2003 1:33 AM
> > To: geronimo-dev@incubator.apache.org
> > Subject: Re: J2EE DeploymentManager ( was J2EE
> deployment verifier)
> >
> >
> > No, I think splitting them up would be good....
> >
> > Weston
> >
> > On Tuesday 12 August 2003 11:41 pm, Jonathan Duty
> wrote:
> > > I'm creating a maven module to add to the cvs
> project.
> > > Do we want to plan on the DeploymentManager,
> VerificationEngine, and
> > > DeploymentEngine being in one module?
> > >
> > > What do you all think?
> > >
> > > ~Jonathan
> > >
> > > Weston M. Price wrote:
> > > >Just thought I should start a new thread....
> > > >
> > > >My KMail was getting dominated!
> > > >
> > > >Weston


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: JSR-88 Deployment API

[Chris Opacki <ch...@yahoo.com>]

Yeah. We can use an absolute path or a relative path
from what I have read. I'll have to read through that
part one more time to see what is better. I'm
wondering about how the management API uses this
information or if it even does. The example of the
Session_DConfigBean in the deployment api specs makes
sense to me though. getXpaths() appears to want to
return a string array of child XPaths relative to the
DCongigBean implementation.

--- Aaron Mulder <am...@alumni.princeton.edu>
wrote:
> 	Let's start with EJB, since that's what the server
> is working 
> towards supporting at the moment.  The tags under
> "enterprise-beans" are 
> probably the place to start.
> 
> 	We should think about how we want to tie DDBeans to
> XPaths.
> 
> Aaron
> 
> On Wed, 13 Aug 2003, Chris Opacki wrote:
> > So was have some deployable objects to implement
> > including DDBeans
> > and ConfigBeans.
> > They are EAR,JAR,WAR and RAR. If I'm missing
> > any..please add them to the list.
> > 
> > 
> > Do we want to list all of the DD tags we need to
> > implement beans for first?
> > 
> > Do we want to each take a spec to find which tags
> we
> > need to implement?
> > 
> > Do we want to order them by importance?
> > 
> > Anything we want to do before we implement these
> (I
> > don't think that 
> > implementing these will require the detail as the
> rest
> > of the Deployment implementation)?
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: JSR-88 Deployment API

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

	Let's start with EJB, since that's what the server is working 
towards supporting at the moment.  The tags under "enterprise-beans" are 
probably the place to start.

	We should think about how we want to tie DDBeans to XPaths.

Aaron

On Wed, 13 Aug 2003, Chris Opacki wrote:
> So was have some deployable objects to implement
> including DDBeans
> and ConfigBeans.
> They are EAR,JAR,WAR and RAR. If I'm missing
> any..please add them to the list.
> 
> 
> Do we want to list all of the DD tags we need to
> implement beans for first?
> 
> Do we want to each take a spec to find which tags we
> need to implement?
> 
> Do we want to order them by importance?
> 
> Anything we want to do before we implement these (I
> don't think that 
> implementing these will require the detail as the rest
> of the Deployment implementation)?

RE: JSR-88 Deployment API

[Chris Opacki <ch...@yahoo.com>]

So was have some deployable objects to implement
including DDBeans
and ConfigBeans.
They are EAR,JAR,WAR and RAR. If I'm missing
any..please add them to the list.


Do we want to list all of the DD tags we need to
implement beans for first?

Do we want to each take a spec to find which tags we
need to implement?

Do we want to order them by importance?

Anything we want to do before we implement these (I
don't think that 
implementing these will require the detail as the rest
of the Deployment implementation)?


--- Aaron Mulder <am...@alumni.princeton.edu>
wrote:
> On Wed, 13 Aug 2003, Maas van den Berg wrote:
> > Hi guys,
> > 
> > I'm very interested in contributing to Geronimo,
> but haven't had much
> > time to read the list and get involved...
> > I did however manage to find some time to
> implement the jsr-88 APIs :)
> > Including some testcases for the *Type classes...
> > Please let me know how/what/when/where to handover
> this stuff for
> > commit.
> 
> 	Do you want to e-mail me what you've got and we can
> try to 
> coordinate this?
> 
> Aaron
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: JSR-88 Deployment API

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

On Wed, 13 Aug 2003, Maas van den Berg wrote:
> Hi guys,
> 
> I'm very interested in contributing to Geronimo, but haven't had much
> time to read the list and get involved...
> I did however manage to find some time to implement the jsr-88 APIs :)
> Including some testcases for the *Type classes...
> Please let me know how/what/when/where to handover this stuff for
> commit.

	Do you want to e-mail me what you've got and we can try to 
coordinate this?

Aaron

RE: JSR-88 Deployment API

[Chris Opacki <ch...@yahoo.com>]

Cool...are you talking about the javax.deployment.*
interfaces? Or the implementation behind the
interfaces?

--- Maas van den Berg <em...@dds.nl> wrote:
> Hi guys,
> 
> I'm very interested in contributing to Geronimo, but
> haven't had much
> time to read the list and get involved...
> I did however manage to find some time to implement
> the jsr-88 APIs :)
> Including some testcases for the *Type classes...
> Please let me know how/what/when/where to handover
> this stuff for
> commit.
> 
> Maas
> 
> On Wed, 2003-08-13 at 21:48, Aaron Mulder wrote:
> > On Wed, 13 Aug 2003, Jeremy Boynes wrote:
> > > We should assume for now that we cannot reuse
> Sun's binaries.
> > > 
> > > Can someone please confirm they are typing in
> the javax.enterprise.deploy
> > > packages and implementing the concrete classes.
> I will commit this when
> > > available.
> > 
> > 	I am working on this, and plan to have at least
> the interfaces 
> > ready today/tonight.
> > 
> > Aaron
> > 
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: JSR-88 Deployment API

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

Now imported

> -----Original Message-----
> From: Maas van den Berg [mailto:email@dds.nl]
> Sent: Wednesday, August 13, 2003 12:11 PM
> To: geronimo-dev@incubator.apache.org
> Subject: RE: JSR-88 Deployment API
>
>
> Hi,
>
> These are just the base interfaces/classes (and some unittests) of
> jsr-88 but no actual implementation.
>
> If have only used the javadoc and ran unit tests against Suns RI to
> verify constants values etc.
>
> - I have not seen the Sun (or other) sources.
> - Copyright is assignable to ASF.
>
> Maas
>
>
> On Wed, 2003-08-13 at 20:54, Jeremy Boynes wrote:
> > Please submit to this list as a patch or as a jar of the source.
> >
> > Please can you also confirm that this is a clean
> implementation, that you
> > have not seen the Sun source, and that copyright is assignable
> to ASF (just
> > being careful).
> >
> > Thanks
> > Jeremy
> >
> > > -----Original Message-----
> > > From: Maas van den Berg [mailto:email@dds.nl]
> > > Sent: Wednesday, August 13, 2003 11:47 AM
> > > To: geronimo-dev@incubator.apache.org
> > > Subject: RE: JSR-88 Deployment API
> > >
> > >
> > > Hi guys,
> > >
> > > I'm very interested in contributing to Geronimo, but haven't had much
> > > time to read the list and get involved...
> > > I did however manage to find some time to implement the jsr-88 APIs :)
> > > Including some testcases for the *Type classes...
> > > Please let me know how/what/when/where to handover this stuff for
> > > commit.
> > >
> > > Maas
> > >
> > > On Wed, 2003-08-13 at 21:48, Aaron Mulder wrote:
> > > > On Wed, 13 Aug 2003, Jeremy Boynes wrote:
> > > > > We should assume for now that we cannot reuse Sun's binaries.
> > > > >
> > > > > Can someone please confirm they are typing in the
> > > javax.enterprise.deploy
> > > > > packages and implementing the concrete classes. I will commit
> > > this when
> > > > > available.
> > > >
> > > > 	I am working on this, and plan to have at least the
> interfaces
> > > > ready today/tonight.
> > > >
> > > > Aaron
> > > >
> > >
> > >
> >
>

RE: JSR-88 Deployment API

[Chris Opacki <ch...@yahoo.com>]

Cool.

--- Maas van den Berg <em...@dds.nl> wrote:
> Hi,
> 
> These are just the base interfaces/classes (and some
> unittests) of
> jsr-88 but no actual implementation.
> 
> If have only used the javadoc and ran unit tests
> against Suns RI to
> verify constants values etc.
> 
> - I have not seen the Sun (or other) sources.
> - Copyright is assignable to ASF.
> 
> Maas
> 
> 
> On Wed, 2003-08-13 at 20:54, Jeremy Boynes wrote:
> > Please submit to this list as a patch or as a jar
> of the source.
> > 
> > Please can you also confirm that this is a clean
> implementation, that you
> > have not seen the Sun source, and that copyright
> is assignable to ASF (just
> > being careful).
> > 
> > Thanks
> > Jeremy
> > 
> > > -----Original Message-----
> > > From: Maas van den Berg [mailto:email@dds.nl]
> > > Sent: Wednesday, August 13, 2003 11:47 AM
> > > To: geronimo-dev@incubator.apache.org
> > > Subject: RE: JSR-88 Deployment API
> > >
> > >
> > > Hi guys,
> > >
> > > I'm very interested in contributing to Geronimo,
> but haven't had much
> > > time to read the list and get involved...
> > > I did however manage to find some time to
> implement the jsr-88 APIs :)
> > > Including some testcases for the *Type
> classes...
> > > Please let me know how/what/when/where to
> handover this stuff for
> > > commit.
> > >
> > > Maas
> > >
> > > On Wed, 2003-08-13 at 21:48, Aaron Mulder wrote:
> > > > On Wed, 13 Aug 2003, Jeremy Boynes wrote:
> > > > > We should assume for now that we cannot
> reuse Sun's binaries.
> > > > >
> > > > > Can someone please confirm they are typing
> in the
> > > javax.enterprise.deploy
> > > > > packages and implementing the concrete
> classes. I will commit
> > > this when
> > > > > available.
> > > >
> > > > 	I am working on this, and plan to have at
> least the interfaces
> > > > ready today/tonight.
> > > >
> > > > Aaron
> > > >
> > >
> > >
> > 
> 

> ATTACHMENT part 2 application/zip name=jsr88-src.jar



__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: JSR-88 Deployment API

[Maas van den Berg <em...@dds.nl>]

Hi,

These are just the base interfaces/classes (and some unittests) of
jsr-88 but no actual implementation.

If have only used the javadoc and ran unit tests against Suns RI to
verify constants values etc.

- I have not seen the Sun (or other) sources.
- Copyright is assignable to ASF.

Maas


On Wed, 2003-08-13 at 20:54, Jeremy Boynes wrote:
> Please submit to this list as a patch or as a jar of the source.
> 
> Please can you also confirm that this is a clean implementation, that you
> have not seen the Sun source, and that copyright is assignable to ASF (just
> being careful).
> 
> Thanks
> Jeremy
> 
> > -----Original Message-----
> > From: Maas van den Berg [mailto:email@dds.nl]
> > Sent: Wednesday, August 13, 2003 11:47 AM
> > To: geronimo-dev@incubator.apache.org
> > Subject: RE: JSR-88 Deployment API
> >
> >
> > Hi guys,
> >
> > I'm very interested in contributing to Geronimo, but haven't had much
> > time to read the list and get involved...
> > I did however manage to find some time to implement the jsr-88 APIs :)
> > Including some testcases for the *Type classes...
> > Please let me know how/what/when/where to handover this stuff for
> > commit.
> >
> > Maas
> >
> > On Wed, 2003-08-13 at 21:48, Aaron Mulder wrote:
> > > On Wed, 13 Aug 2003, Jeremy Boynes wrote:
> > > > We should assume for now that we cannot reuse Sun's binaries.
> > > >
> > > > Can someone please confirm they are typing in the
> > javax.enterprise.deploy
> > > > packages and implementing the concrete classes. I will commit
> > this when
> > > > available.
> > >
> > > 	I am working on this, and plan to have at least the interfaces
> > > ready today/tonight.
> > >
> > > Aaron
> > >
> >
> >
> 

RE: JSR-88 Deployment API

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

Please submit to this list as a patch or as a jar of the source.

Please can you also confirm that this is a clean implementation, that you
have not seen the Sun source, and that copyright is assignable to ASF (just
being careful).

Thanks
Jeremy

> -----Original Message-----
> From: Maas van den Berg [mailto:email@dds.nl]
> Sent: Wednesday, August 13, 2003 11:47 AM
> To: geronimo-dev@incubator.apache.org
> Subject: RE: JSR-88 Deployment API
>
>
> Hi guys,
>
> I'm very interested in contributing to Geronimo, but haven't had much
> time to read the list and get involved...
> I did however manage to find some time to implement the jsr-88 APIs :)
> Including some testcases for the *Type classes...
> Please let me know how/what/when/where to handover this stuff for
> commit.
>
> Maas
>
> On Wed, 2003-08-13 at 21:48, Aaron Mulder wrote:
> > On Wed, 13 Aug 2003, Jeremy Boynes wrote:
> > > We should assume for now that we cannot reuse Sun's binaries.
> > >
> > > Can someone please confirm they are typing in the
> javax.enterprise.deploy
> > > packages and implementing the concrete classes. I will commit
> this when
> > > available.
> >
> > 	I am working on this, and plan to have at least the interfaces
> > ready today/tonight.
> >
> > Aaron
> >
>
>

RE: JSR-88 Deployment API

[Maas van den Berg <em...@dds.nl>]

Hi guys,

I'm very interested in contributing to Geronimo, but haven't had much
time to read the list and get involved...
I did however manage to find some time to implement the jsr-88 APIs :)
Including some testcases for the *Type classes...
Please let me know how/what/when/where to handover this stuff for
commit.

Maas

On Wed, 2003-08-13 at 21:48, Aaron Mulder wrote:
> On Wed, 13 Aug 2003, Jeremy Boynes wrote:
> > We should assume for now that we cannot reuse Sun's binaries.
> > 
> > Can someone please confirm they are typing in the javax.enterprise.deploy
> > packages and implementing the concrete classes. I will commit this when
> > available.
> 
> 	I am working on this, and plan to have at least the interfaces 
> ready today/tonight.
> 
> Aaron
> 

RE: JSR-88 Deployment API

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

On Wed, 13 Aug 2003, Jeremy Boynes wrote:
> We should assume for now that we cannot reuse Sun's binaries.
> 
> Can someone please confirm they are typing in the javax.enterprise.deploy
> packages and implementing the concrete classes. I will commit this when
> available.

	I am working on this, and plan to have at least the interfaces 
ready today/tonight.

Aaron

RE: JSR-88 Deployment API

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

We should assume for now that we cannot reuse Sun's binaries.

Can someone please confirm they are typing in the javax.enterprise.deploy
packages and implementing the concrete classes. I will commit this when
available.

Thanks
Jeremy

> -----Original Message-----
> From: Chris Opacki [mailto:chris_opacki@yahoo.com]
> Sent: Wednesday, August 13, 2003 9:11 AM
> To: geronimo-dev@incubator.apache.org
> Subject: JSR-88 Deployment API
>
>
> A new thread for all things JSR-88.
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>

JSR-88 Deployment API

[Chris Opacki <ch...@yahoo.com>]

A new thread for all things JSR-88.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

["Weston M. Price" <we...@yahoo.com>]

Can we get everyone together so we are all on the same page? By that I mean, 
who is doing what....when, etc???

There is a lot of stuff going on right now.

Weston

On Wednesday 13 August 2003 04:02 pm, Jonathan Duty wrote:
> Do you want the DDBeans to be part of this module?
> ~Jonathan
>
> Jonathan Duty
> Software Developer - eWashtenaw
>
>
> -----Original Message-----
> From: Chris Opacki [mailto:chris_opacki@yahoo.com]
> Sent: Wednesday, August 13, 2003 11:59 AM
> To: geronimo-dev@incubator.apache.org
> Subject: RE: J2EE DeploymentManager ( was J2EE deployment verifier)
>
> I would like to start implementing the DDBeans from
> JSR-88. I will start a new thread for JSR-88.
>
> --- Srihari S <sr...@blr.pin.philips.com> wrote:
> > cool...so what are we waiting for!!!!
> > lets get started with the requirements/design of the
> > verifier..
> > any ideas on the way of working for these phases..
> >
> > -----Original Message-----
> > From: Jonathan Duty [mailto:jduty@jonandkerry.com]
> > Sent: Wednesday, August 13, 2003 8:14 PM
> > To: geronimo-dev@incubator.apache.org;
> > weston_p@yahoo.com
> > Subject: RE: J2EE DeploymentManager ( was J2EE
> > deployment verifier)
> >
> >
> > I agree.  The verification engine really doesn't
> > need to implement the
> > deployment specs.  Later when we implement the
> > DeploymentManager in
> > front of it that's when we will have to worry about
> > implementing the
> > exact interfaces.
> >
> > ~Jonathan
> >
> >
> > Jonathan Duty
> > Software Developer - eWashtenaw
> >
> >
> > -----Original Message-----
> > From: Weston M. Price [mailto:weston_p@yahoo.com]
> > Sent: Wednesday, August 13, 2003 5:48 AM
> > To: geronimo-dev@incubator.apache.org
> > Subject: Re: J2EE DeploymentManager ( was J2EE
> > deployment verifier)
> >
> > I agree with Srihari in that the Verification
> > manager does not have to
> > implement the spec interfaces, however, the
> > DeploymentManager does, this
> >
> > would be where we would implment DDRoot, DDConfig
> > etc.....in some ways
> > the
> > DeploymentManager would just use the services of the
> > VerificatinoEngine
> > as
> > one step in the process of actual deployment.
> >
> > Is this in line with what you guys were thinking?
> >
> >
> > On Wednesday 13 August 2003 01:52 pm, Jonathan Duty
> >
> > wrote:
> > > When we implement this module, we could actually
> >
> > implement it to
> > exactly
> >
> > > follow the API specs (JSR 88).  That means
> >
> > implementing the
> >
> > > DeploymentManager interface on top of it and such.
> >
> >  That way any
> >
> > > application (ant, Eclipse, etc) that is equipped
> >
> > to deploy packages
> >
> > > could interface with it.  It would just fall short
> >
> > of actually
> >
> > > communicating with MBeans and deploying the
> >
> > package.
> >
> > > When this module is used internally (within the
> >
> > REAL deployment
> > manager)
> >
> > > it could just bypass or override the
> >
> > Verification's Deployment
> > manager.
> >
> > > ~Jonathan
> > >
> > >
> > > -----Original Message-----
> > > From: Srihari S
> >
> > [mailto:sriharis@blr.pin.philips.com]
> >
> > > Sent: Wednesday, August 13, 2003 9:43 AM
> > > To: geronimo-dev@incubator.apache.org;
> >
> > weston_p@yahoo.com
> >
> > > Subject: RE: J2EE DeploymentManager ( was J2EE
> >
> > deployment verifier)
> >
> > > Hi All
> > >   When I was going thru the deployment api spec I
> >
> > thought it would be
> >
> > > good
> > > to bring up some points:
> > >
> > > From a preliminary reading of the spec i saw there
> >
> > are no apis
> >
> > > explicitly
> > > designed to do the verification
> > > of a deployable unit. From this I infer that the
> >
> > verifier can be an
> >
> > > internal
> > > module which could be used
> > > by the deploy tool. So we could go full steam on
> >
> > its design and
> >
> > > implementation. In this regard I am trying to
> > > jot the list of checks that our verifier will have
> >
> > to do (This is
> >
> > > mentioned
> > > in the j2ee specs).
> > > So in a way it will be equivalent to arriving at
> >
> > requirement specs for
> >
> > > the
> > > verifier.
> > > With the list of dos and donts that a verifier has
> >
> > to achieve we could
> >
> > > go
> > > abt with design.Also the design of
> > > ant hooks can be taken care.Can we??
> > >
> > > Next is something abt the big picture. Certainly
> >
> > the verifer is a
> > small
> >
> > > part
> > > of the deployment process.
> > > But to achieve compliance we will have to
> >
> > implement the deployment
> > spec
> >
> > > as a
> > > whole. Has anyone given
> > > thought to this issue?
> > >
> > > regards
> > > Hari
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Weston M. Price [mailto:weston_p@yahoo.com]
> > > Sent: Wednesday, August 13, 2003 1:33 AM
> > > To: geronimo-dev@incubator.apache.org
> > > Subject: Re: J2EE DeploymentManager ( was J2EE
> >
> > deployment verifier)
> >
> > > No, I think splitting them up would be good....
> > >
> > > Weston
> > >
> > > On Tuesday 12 August 2003 11:41 pm, Jonathan Duty
> >
> > wrote:
> > > > I'm creating a maven module to add to the cvs
> >
> > project.
> >
> > > > Do we want to plan on the DeploymentManager,
> >
> > VerificationEngine, and
> >
> > > > DeploymentEngine being in one module?
> > > >
> > > > What do you all think?
> > > >
> > > > ~Jonathan
> > > >
> > > > Weston M. Price wrote:
> > > > >Just thought I should start a new thread....
> > > > >
> > > > >My KMail was getting dominated!
> > > > >
> > > > >Weston
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

["Weston M. Price" <we...@yahoo.com>]

ARGGG NO THIS IS NOT TRUE!!!!!!!!!!!1

Weston

On Wednesday 13 August 2003 04:56 pm, Chris Opacki wrote:
> I haven't checked out the license yet. Are the classes
> in CVS?
>
> I have started downloading all of the related specs to
> collect all of that information.
>
> It is a requirement for the Tool side to work connect
> and not connected. I am assuming this will require
> remote access to the serverside of the API.
>
> So far it seems Jonathan D. and I are the only people
> interested in this task.
>
>
> --- Aaron Mulder <am...@alumni.princeton.edu>
>
> wrote:
> > On Wed, 13 Aug 2003, Chris Opacki wrote:
> > > I have the javax.enterprise.deployment classes
> > > downloaded from sun. Do we need anything else to
> >
> > start
> >
> > > the DDBean implementations? I'm not sure if anyone
> > > else has started on these things... Jon Duty and I
> > > (and anyone else interested) are ready to start on
> > > these things.
> >
> > 	The point is, we probably can't use the classes you
> > downloaded
> > from Sun.  Have you examined the license with care?
> > Are we allowed to
> > freely redistribute them under our own license?
> > That not typically
> > allowed.
> >
> > 	Also, before starting on the DDBeans, we need to
> > assemble the list
> > of deployment information that is actually required.
> >  Otherwise, what will
> > the DDBeans represent?  We should probably also
> > prioritize EJB, Web, J2CA,
> > and application metadata and tackle these one at a
> > time.
> >
> > 	We also need to figure out how the JSR-88 impl will
> > communicate
> > with the server, since they're typically run in
> > different JVMs, if not on
> > different machines altogether.
> >
> > Aaron
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Chris Opacki <ch...@yahoo.com>]

Sounds like a plan.. it seems someone has already
implemented all of these javabeans.

--- Aaron Mulder <am...@alumni.princeton.edu>
wrote:
> On Wed, 13 Aug 2003, Chris Opacki wrote:
> > That's exactly it! My bad for not being a bit more
> > verbose. The DConfig objects are actually
> constructed
> > from the DDBeans. Which makes me believe we want
> to be
> > using RMI if we load the DDBeans remotely. Maybe
> we
> > can try to more than one strategy to see what is
> best.
> > It does appear that there would be a 1 to 1
> > relationship between DDBean and the
> > DConfigBeans...lots of stuff...
> 
> 	Well, let me go on, then.  Let's say we're
> deploying an EJB "Foo"  
> with an EJB Reference to another EJB "Bar" (with the
> reference named
> ejb/Bar), and both are in the same EJB JAR, but
> inexplicably don't use 
> an ejb-link.
> 
> 	The tool side should provide a DDBeanRoot for
> ejb-jar.xml in the 
> EJB JAR, with DDBeans for each EJB, for the EJB
> Reference, and for other 
> tags in the ejb-jar.xml.  (I just fat-fingered that
> to jar-jar.xml and had 
> a horrible flashback, but that's a different story.)
> 
> 	When the tool wants to configure this for Geronimo,
> it gets a 
> DeploymentManager, and then says, more or less,
> "dear deployment manager, 
> I have this nice EJB JAR represented by
> [DDBeanRoot], please give me a 
> DConfigBeanRoot that represents the information your
> product needs in 
> order to configure this EJB JAR."
> 
> 	So Geronimo would prepare a DConfigBean tree that
> has, let's say,
> the root, a DConfigBean for each EJB, and a
> DConfigBean for the EJB
> reference.  The DConfigBeans matching each EJB have
> properties to set the
> JNDI name.  The DConfigBean matching the EJB
> reference has a variety of
> properties -- an option for the JNDI name to map the
> EJB ref to, as well
> as JNDI context configuration properties in case the
> bean is in a
> different server.
> 
> 	Now, since presumably the user is working on all
> this at the same
> time in the tool, let's say they resolve the EJB
> Reference from Foo to Bar
> by configuring a JNDI name for Bar and then mapping
> the reference to Bar's
> JNDI name.  But now they go back and change the EJB
> name of Bar to Alice.  
> This would invalidate the DConfigBeans, which
> presumably are holding
> something like this under the covers:
> 
> Foo -> JNDI name "myapp.Foo"
> Bar -> JNDI name "myapp.Bar"
> 
> 	So there's a mechanism for the DConfigBeans to
> "listen for 
> changes" on particular DDBeans.  Thus, when the user
> changes the EJB name 
> of "Bar" to "Alice", the "Bar" DConfigBean gets
> notified, rereads the 
> properties of the DDBean formerly known as "Bar",
> and updates its internal 
> data model to something like:
> 
> Foo -> JNDI name "myapp.Foo"
> Alice -> JNDI name "myapp.Bar"
> 
> 	And then the user can go and update the JNDI
> setting for Alice in
> the Alice DConfigBean screen.  Or, the user can now
> delete Alice
> altogether, in which case the server side had better
> delete its Alice
> DConfigBean, so the DConfigBeanRoot contains only a
> DConfigBean for Foo.
> 
> 	So that's why the tool's DDBean implementation has
> to be able to 
> fire XPathEvents for the DConfigBeans, and why
> DConfigBeans want to 
> listen for events on specific XPaths.
> 
> 	Also, all this work is going on in the JVM of the
> tool.  The tool
> is directly invoking DConfigBeans which are present
> in the tool's space.  
> If the DConfigBeans have to communicate with the
> server, that's something 
> they handle under the covers, and it's all
> irrelevant to the tool, which 
> just introspects the DConfigBeans that it's been
> given.  So the tool 
> doesn't need any RMI or anything.
> 
> 	Make sense?
> 
> Aaron
> 
> > --- Aaron Mulder <am...@alumni.princeton.edu>
> > wrote:
> > > 	Oops -- upon looking at the spec, I think I've
> been
> > > the confused
> > > one.  Let me back up and try to lay this out,
> and
> > > then you tell me if you
> > > agree.
> > > 
> > > 	The goal of the spec is for a single tool to be
> > > able to configure
> > > and deploy applications to any server.  So all
> the
> > > servers will provide a
> > > common API, and all the tools will be coded
> against
> > > that API.  However, a
> > > fixed API can't represent all the configuration
> > > information required by
> > > all app servers, so JSR-88 provides base classes
> and
> > > then mandates that
> > > the extensions to those base classes be
> JavaBeans,
> > > so they can be
> > > introspected and configured at runtime.  So the
> > > server provides some 
> > > methods like "deploy" and a set of configuration
> > > classes that can be used 
> > > by the tool to configure a specific app.  The
> tool
> > > then creates and 
> > > packages an app, creates the standard J2EE DDs
> for
> > > it, invokes the server 
> > > implementation to edit server-specific
> deployment
> > > information for it, and 
> > > then invokes the server implementation to
> actually
> > > do the deployment, etc.
> > > 
> > > 	Where I was confused is that the DDBeans
> represent
> > > the standard 
> > > J2EE deployment descriptor, as opposed to the
> > > DConfigBeans, which 
> > > represent the server-specific deployment
> > > information.  Since the tool 
> > > packaged the xAR in the first place, it is
> assumed
> > > that the tool is 
> > > responsible for the standard J2EE DDs, so the
> tool
> > > provides the DDBean 
> > > objects.  The server is responsible for the
> > > DConfigBean objects, which 
> > > make use of the information in the DDBean
> objects,
> > > in order to configure 
> > > the server-specific information.
> > > 
> > > 	So if you want to work on the DDBeans, you
> really
> > > *are* talking 
> > > about the tool implementation.  The tool needs
> to
> > > implement the DDBeans, 
> > > and also present a user interface for the
> arbitrary
> > > JavaBean DConfigBeans.  
> > > The tool side doesn't need to worry about
> > > communicating with the server 
> > > over the network -- it just grabs a
> > > DeploymentManager locally, and it's 
> > > the responsibility of the server implementation
> of
> > > DeploymentManager and 
> > > the DConfigBeans to communicate with the server
> as
> > > appropriate (and when 
> > > in connected mode, etc.).
> > > 
> > > 	Sound right to you?
> > > 
> > > Aaron 
> > > 
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

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

On Wed, 13 Aug 2003, Chris Opacki wrote:
> That's exactly it! My bad for not being a bit more
> verbose. The DConfig objects are actually constructed
> from the DDBeans. Which makes me believe we want to be
> using RMI if we load the DDBeans remotely. Maybe we
> can try to more than one strategy to see what is best.
> It does appear that there would be a 1 to 1
> relationship between DDBean and the
> DConfigBeans...lots of stuff...

	Well, let me go on, then.  Let's say we're deploying an EJB "Foo"  
with an EJB Reference to another EJB "Bar" (with the reference named
ejb/Bar), and both are in the same EJB JAR, but inexplicably don't use 
an ejb-link.

	The tool side should provide a DDBeanRoot for ejb-jar.xml in the 
EJB JAR, with DDBeans for each EJB, for the EJB Reference, and for other 
tags in the ejb-jar.xml.  (I just fat-fingered that to jar-jar.xml and had 
a horrible flashback, but that's a different story.)

	When the tool wants to configure this for Geronimo, it gets a 
DeploymentManager, and then says, more or less, "dear deployment manager, 
I have this nice EJB JAR represented by [DDBeanRoot], please give me a 
DConfigBeanRoot that represents the information your product needs in 
order to configure this EJB JAR."

	So Geronimo would prepare a DConfigBean tree that has, let's say,
the root, a DConfigBean for each EJB, and a DConfigBean for the EJB
reference.  The DConfigBeans matching each EJB have properties to set the
JNDI name.  The DConfigBean matching the EJB reference has a variety of
properties -- an option for the JNDI name to map the EJB ref to, as well
as JNDI context configuration properties in case the bean is in a
different server.

	Now, since presumably the user is working on all this at the same
time in the tool, let's say they resolve the EJB Reference from Foo to Bar
by configuring a JNDI name for Bar and then mapping the reference to Bar's
JNDI name.  But now they go back and change the EJB name of Bar to Alice.  
This would invalidate the DConfigBeans, which presumably are holding
something like this under the covers:

Foo -> JNDI name "myapp.Foo"
Bar -> JNDI name "myapp.Bar"

	So there's a mechanism for the DConfigBeans to "listen for 
changes" on particular DDBeans.  Thus, when the user changes the EJB name 
of "Bar" to "Alice", the "Bar" DConfigBean gets notified, rereads the 
properties of the DDBean formerly known as "Bar", and updates its internal 
data model to something like:

Foo -> JNDI name "myapp.Foo"
Alice -> JNDI name "myapp.Bar"

	And then the user can go and update the JNDI setting for Alice in
the Alice DConfigBean screen.  Or, the user can now delete Alice
altogether, in which case the server side had better delete its Alice
DConfigBean, so the DConfigBeanRoot contains only a DConfigBean for Foo.

	So that's why the tool's DDBean implementation has to be able to 
fire XPathEvents for the DConfigBeans, and why DConfigBeans want to 
listen for events on specific XPaths.

	Also, all this work is going on in the JVM of the tool.  The tool
is directly invoking DConfigBeans which are present in the tool's space.  
If the DConfigBeans have to communicate with the server, that's something 
they handle under the covers, and it's all irrelevant to the tool, which 
just introspects the DConfigBeans that it's been given.  So the tool 
doesn't need any RMI or anything.

	Make sense?

Aaron

> --- Aaron Mulder <am...@alumni.princeton.edu>
> wrote:
> > 	Oops -- upon looking at the spec, I think I've been
> > the confused
> > one.  Let me back up and try to lay this out, and
> > then you tell me if you
> > agree.
> > 
> > 	The goal of the spec is for a single tool to be
> > able to configure
> > and deploy applications to any server.  So all the
> > servers will provide a
> > common API, and all the tools will be coded against
> > that API.  However, a
> > fixed API can't represent all the configuration
> > information required by
> > all app servers, so JSR-88 provides base classes and
> > then mandates that
> > the extensions to those base classes be JavaBeans,
> > so they can be
> > introspected and configured at runtime.  So the
> > server provides some 
> > methods like "deploy" and a set of configuration
> > classes that can be used 
> > by the tool to configure a specific app.  The tool
> > then creates and 
> > packages an app, creates the standard J2EE DDs for
> > it, invokes the server 
> > implementation to edit server-specific deployment
> > information for it, and 
> > then invokes the server implementation to actually
> > do the deployment, etc.
> > 
> > 	Where I was confused is that the DDBeans represent
> > the standard 
> > J2EE deployment descriptor, as opposed to the
> > DConfigBeans, which 
> > represent the server-specific deployment
> > information.  Since the tool 
> > packaged the xAR in the first place, it is assumed
> > that the tool is 
> > responsible for the standard J2EE DDs, so the tool
> > provides the DDBean 
> > objects.  The server is responsible for the
> > DConfigBean objects, which 
> > make use of the information in the DDBean objects,
> > in order to configure 
> > the server-specific information.
> > 
> > 	So if you want to work on the DDBeans, you really
> > *are* talking 
> > about the tool implementation.  The tool needs to
> > implement the DDBeans, 
> > and also present a user interface for the arbitrary
> > JavaBean DConfigBeans.  
> > The tool side doesn't need to worry about
> > communicating with the server 
> > over the network -- it just grabs a
> > DeploymentManager locally, and it's 
> > the responsibility of the server implementation of
> > DeploymentManager and 
> > the DConfigBeans to communicate with the server as
> > appropriate (and when 
> > in connected mode, etc.).
> > 
> > 	Sound right to you?
> > 
> > Aaron 
> > 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
> 

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Chris Opacki <ch...@yahoo.com>]

That's exactly it! My bad for not being a bit more
verbose. The DConfig objects are actually constructed
from the DDBeans. Which makes me believe we want to be
using RMI if we load the DDBeans remotely. Maybe we
can try to more than one strategy to see what is best.
It does appear that there would be a 1 to 1
relationship between DDBean and the
DConfigBeans...lots of stuff...

--- Aaron Mulder <am...@alumni.princeton.edu>
wrote:
> On Wed, 13 Aug 2003, Chris Opacki wrote:
> > I will check on the license issue. I might have to
> > wait until later on tonight though. If anyone has
> time
> > to do it now...go for it.
> > 
> > It seems that the deployment spec actually has
> divided
> > some of API between Tool Provider and J2EE Product
> > Provider. I don't think it means "The Deploy
> Tool",
> > but the interface between the tool and the server.
> The
> > confusion in that spec is definitely where the
> tool
> > provder part of the API resides. I guess it all
> > depends on how we plan on communicating.
> 
> 	Oops -- upon looking at the spec, I think I've been
> the confused
> one.  Let me back up and try to lay this out, and
> then you tell me if you
> agree.
> 
> 	The goal of the spec is for a single tool to be
> able to configure
> and deploy applications to any server.  So all the
> servers will provide a
> common API, and all the tools will be coded against
> that API.  However, a
> fixed API can't represent all the configuration
> information required by
> all app servers, so JSR-88 provides base classes and
> then mandates that
> the extensions to those base classes be JavaBeans,
> so they can be
> introspected and configured at runtime.  So the
> server provides some 
> methods like "deploy" and a set of configuration
> classes that can be used 
> by the tool to configure a specific app.  The tool
> then creates and 
> packages an app, creates the standard J2EE DDs for
> it, invokes the server 
> implementation to edit server-specific deployment
> information for it, and 
> then invokes the server implementation to actually
> do the deployment, etc.
> 
> 	Where I was confused is that the DDBeans represent
> the standard 
> J2EE deployment descriptor, as opposed to the
> DConfigBeans, which 
> represent the server-specific deployment
> information.  Since the tool 
> packaged the xAR in the first place, it is assumed
> that the tool is 
> responsible for the standard J2EE DDs, so the tool
> provides the DDBean 
> objects.  The server is responsible for the
> DConfigBean objects, which 
> make use of the information in the DDBean objects,
> in order to configure 
> the server-specific information.
> 
> 	So if you want to work on the DDBeans, you really
> *are* talking 
> about the tool implementation.  The tool needs to
> implement the DDBeans, 
> and also present a user interface for the arbitrary
> JavaBean DConfigBeans.  
> The tool side doesn't need to worry about
> communicating with the server 
> over the network -- it just grabs a
> DeploymentManager locally, and it's 
> the responsibility of the server implementation of
> DeploymentManager and 
> the DConfigBeans to communicate with the server as
> appropriate (and when 
> in connected mode, etc.).
> 
> 	Sound right to you?
> 
> Aaron 
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

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

On Wed, 13 Aug 2003, Chris Opacki wrote:
> I will check on the license issue. I might have to
> wait until later on tonight though. If anyone has time
> to do it now...go for it.
> 
> It seems that the deployment spec actually has divided
> some of API between Tool Provider and J2EE Product
> Provider. I don't think it means "The Deploy Tool",
> but the interface between the tool and the server. The
> confusion in that spec is definitely where the tool
> provder part of the API resides. I guess it all
> depends on how we plan on communicating.

	Oops -- upon looking at the spec, I think I've been the confused
one.  Let me back up and try to lay this out, and then you tell me if you
agree.

	The goal of the spec is for a single tool to be able to configure
and deploy applications to any server.  So all the servers will provide a
common API, and all the tools will be coded against that API.  However, a
fixed API can't represent all the configuration information required by
all app servers, so JSR-88 provides base classes and then mandates that
the extensions to those base classes be JavaBeans, so they can be
introspected and configured at runtime.  So the server provides some 
methods like "deploy" and a set of configuration classes that can be used 
by the tool to configure a specific app.  The tool then creates and 
packages an app, creates the standard J2EE DDs for it, invokes the server 
implementation to edit server-specific deployment information for it, and 
then invokes the server implementation to actually do the deployment, etc.

	Where I was confused is that the DDBeans represent the standard 
J2EE deployment descriptor, as opposed to the DConfigBeans, which 
represent the server-specific deployment information.  Since the tool 
packaged the xAR in the first place, it is assumed that the tool is 
responsible for the standard J2EE DDs, so the tool provides the DDBean 
objects.  The server is responsible for the DConfigBean objects, which 
make use of the information in the DDBean objects, in order to configure 
the server-specific information.

	So if you want to work on the DDBeans, you really *are* talking 
about the tool implementation.  The tool needs to implement the DDBeans, 
and also present a user interface for the arbitrary JavaBean DConfigBeans.  
The tool side doesn't need to worry about communicating with the server 
over the network -- it just grabs a DeploymentManager locally, and it's 
the responsibility of the server implementation of DeploymentManager and 
the DConfigBeans to communicate with the server as appropriate (and when 
in connected mode, etc.).

	Sound right to you?

Aaron 

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Jonathan Duty <jd...@jonandkerry.com>]

If you look at the sequence diagrams in the JSR 88 specs, you will see
where the separation is between the tool provider (an ant interface, or
web(, the platform provider (Deployment Manager) , and the Deployer
(MBeans and stuff on J2EE server).  

I think we should concentrate on implementing the Platform Provider.
Once we have that started the others can start to be implemented.  


What do you all think?
~Jonathan

Jonathan Duty
Software Developer - eWashtenaw


-----Original Message-----
From: Chris Opacki [mailto:chris_opacki@yahoo.com] 
Sent: Wednesday, August 13, 2003 1:48 PM
To: geronimo-dev@incubator.apache.org
Subject: RE: J2EE DeploymentManager ( was J2EE deployment verifier)

I will check on the license issue. I might have to
wait until later on tonight though. If anyone has time
to do it now...go for it.

It seems that the deployment spec actually has divided
some of API between Tool Provider and J2EE Product
Provider. I don't think it means "The Deploy Tool",
but the interface between the tool and the server. The
confusion in that spec is definitely where the tool
provder part of the API resides. I guess it all
depends on how we plan on communicating.



--- Aaron Mulder <am...@alumni.princeton.edu>
wrote:
> On Wed, 13 Aug 2003, Chris Opacki wrote:
> > I haven't checked out the license yet. Are the
> classes
> > in CVS?
> 
> 	This is exactly the point -- they're not in CVS
> because we don't 
> think the license allows us to put them in CVS.  Can
> you check the license 
> and report back?
> 
> > I have started downloading all of the related
> specs to
> > collect all of that information.
> > 
> > It is a requirement for the Tool side to work
> connect
> > and not connected. I am assuming this will require
> > remote access to the serverside of the API.
> 
> 	As I said below, "we also need to figure out how
> the JSR-88 impl
> will communicate with the server, since they're
> typically run in different
> JVMs, if not on different machines altogether."  But
> you shouldn't refer 
> to this as "the tool side".  The tool side is
> completely unrelated to what 
> we're discussing here.  The tool side is responsible
> for presenting the 
> user interface.  The server side is responsible for
> telling the tool side 
> what configuration options are available, as well as
> doing the real work 
> (deploying, etc.), and the server side is what needs
> to run remotely in 
> connected or disconnected mode.  Though it could be
> split so part of it 
> runs remotely and part always runs on the app
> server, or something like 
> that, if we didn't just want to make network calls
> to JMX or whatever the 
> server infrastructure ends up being.
> 
> Aaron
> 
> > So far it seems Jonathan D. and I are the only
> people
> > interested in this task.
> > 
> > 
> > --- Aaron Mulder <am...@alumni.princeton.edu>
> > wrote:
> > > On Wed, 13 Aug 2003, Chris Opacki wrote:
> > > > I have the javax.enterprise.deployment classes
> > > > downloaded from sun. Do we need anything else
> to
> > > start
> > > > the DDBean implementations? I'm not sure if
> anyone
> > > > else has started on these things... Jon Duty
> and I
> > > > (and anyone else interested) are ready to
> start on
> > > > these things.
> > > 
> > > 	The point is, we probably can't use the classes
> you
> > > downloaded
> > > from Sun.  Have you examined the license with
> care? 
> > > Are we allowed to
> > > freely redistribute them under our own license? 
> > > That not typically
> > > allowed.
> > > 
> > > 	Also, before starting on the DDBeans, we need
> to
> > > assemble the list 
> > > of deployment information that is actually
> required.
> > >  Otherwise, what will 
> > > the DDBeans represent?  We should probably also
> > > prioritize EJB, Web, J2CA, 
> > > and application metadata and tackle these one at
> a
> > > time.
> > > 
> > > 	We also need to figure out how the JSR-88 impl
> will
> > > communicate 
> > > with the server, since they're typically run in
> > > different JVMs, if not on 
> > > different machines altogether.
> > > 
> > > Aaron
> > > 
> > 
> > 
> > __________________________________
> > 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: J2EE DeploymentManager ( was J2EE deployment verifier)

[Chris Opacki <ch...@yahoo.com>]

I will check on the license issue. I might have to
wait until later on tonight though. If anyone has time
to do it now...go for it.

It seems that the deployment spec actually has divided
some of API between Tool Provider and J2EE Product
Provider. I don't think it means "The Deploy Tool",
but the interface between the tool and the server. The
confusion in that spec is definitely where the tool
provder part of the API resides. I guess it all
depends on how we plan on communicating.



--- Aaron Mulder <am...@alumni.princeton.edu>
wrote:
> On Wed, 13 Aug 2003, Chris Opacki wrote:
> > I haven't checked out the license yet. Are the
> classes
> > in CVS?
> 
> 	This is exactly the point -- they're not in CVS
> because we don't 
> think the license allows us to put them in CVS.  Can
> you check the license 
> and report back?
> 
> > I have started downloading all of the related
> specs to
> > collect all of that information.
> > 
> > It is a requirement for the Tool side to work
> connect
> > and not connected. I am assuming this will require
> > remote access to the serverside of the API.
> 
> 	As I said below, "we also need to figure out how
> the JSR-88 impl
> will communicate with the server, since they're
> typically run in different
> JVMs, if not on different machines altogether."  But
> you shouldn't refer 
> to this as "the tool side".  The tool side is
> completely unrelated to what 
> we're discussing here.  The tool side is responsible
> for presenting the 
> user interface.  The server side is responsible for
> telling the tool side 
> what configuration options are available, as well as
> doing the real work 
> (deploying, etc.), and the server side is what needs
> to run remotely in 
> connected or disconnected mode.  Though it could be
> split so part of it 
> runs remotely and part always runs on the app
> server, or something like 
> that, if we didn't just want to make network calls
> to JMX or whatever the 
> server infrastructure ends up being.
> 
> Aaron
> 
> > So far it seems Jonathan D. and I are the only
> people
> > interested in this task.
> > 
> > 
> > --- Aaron Mulder <am...@alumni.princeton.edu>
> > wrote:
> > > On Wed, 13 Aug 2003, Chris Opacki wrote:
> > > > I have the javax.enterprise.deployment classes
> > > > downloaded from sun. Do we need anything else
> to
> > > start
> > > > the DDBean implementations? I'm not sure if
> anyone
> > > > else has started on these things... Jon Duty
> and I
> > > > (and anyone else interested) are ready to
> start on
> > > > these things.
> > > 
> > > 	The point is, we probably can't use the classes
> you
> > > downloaded
> > > from Sun.  Have you examined the license with
> care? 
> > > Are we allowed to
> > > freely redistribute them under our own license? 
> > > That not typically
> > > allowed.
> > > 
> > > 	Also, before starting on the DDBeans, we need
> to
> > > assemble the list 
> > > of deployment information that is actually
> required.
> > >  Otherwise, what will 
> > > the DDBeans represent?  We should probably also
> > > prioritize EJB, Web, J2CA, 
> > > and application metadata and tackle these one at
> a
> > > time.
> > > 
> > > 	We also need to figure out how the JSR-88 impl
> will
> > > communicate 
> > > with the server, since they're typically run in
> > > different JVMs, if not on 
> > > different machines altogether.
> > > 
> > > Aaron
> > > 
> > 
> > 
> > __________________________________
> > 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: J2EE DeploymentManager ( was J2EE deployment verifier)

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

On Wed, 13 Aug 2003, Chris Opacki wrote:
> I haven't checked out the license yet. Are the classes
> in CVS?

	This is exactly the point -- they're not in CVS because we don't 
think the license allows us to put them in CVS.  Can you check the license 
and report back?

> I have started downloading all of the related specs to
> collect all of that information.
> 
> It is a requirement for the Tool side to work connect
> and not connected. I am assuming this will require
> remote access to the serverside of the API.

	As I said below, "we also need to figure out how the JSR-88 impl
will communicate with the server, since they're typically run in different
JVMs, if not on different machines altogether."  But you shouldn't refer 
to this as "the tool side".  The tool side is completely unrelated to what 
we're discussing here.  The tool side is responsible for presenting the 
user interface.  The server side is responsible for telling the tool side 
what configuration options are available, as well as doing the real work 
(deploying, etc.), and the server side is what needs to run remotely in 
connected or disconnected mode.  Though it could be split so part of it 
runs remotely and part always runs on the app server, or something like 
that, if we didn't just want to make network calls to JMX or whatever the 
server infrastructure ends up being.

Aaron

> So far it seems Jonathan D. and I are the only people
> interested in this task.
> 
> 
> --- Aaron Mulder <am...@alumni.princeton.edu>
> wrote:
> > On Wed, 13 Aug 2003, Chris Opacki wrote:
> > > I have the javax.enterprise.deployment classes
> > > downloaded from sun. Do we need anything else to
> > start
> > > the DDBean implementations? I'm not sure if anyone
> > > else has started on these things... Jon Duty and I
> > > (and anyone else interested) are ready to start on
> > > these things.
> > 
> > 	The point is, we probably can't use the classes you
> > downloaded
> > from Sun.  Have you examined the license with care? 
> > Are we allowed to
> > freely redistribute them under our own license? 
> > That not typically
> > allowed.
> > 
> > 	Also, before starting on the DDBeans, we need to
> > assemble the list 
> > of deployment information that is actually required.
> >  Otherwise, what will 
> > the DDBeans represent?  We should probably also
> > prioritize EJB, Web, J2CA, 
> > and application metadata and tackle these one at a
> > time.
> > 
> > 	We also need to figure out how the JSR-88 impl will
> > communicate 
> > with the server, since they're typically run in
> > different JVMs, if not on 
> > different machines altogether.
> > 
> > Aaron
> > 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
> 

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Tim Urberg <ti...@yahoo.com>]

With my very simple understanding of a DDBean and JSR-88, yes. :)  I'm still
trying to adjust my mental image of what I've done and seen in the past (or for
OpenEJB) for a deployment tool to the way it needs to be done to properly
implement the spec.

David Blevins and I talked about this a little last night and hopefully the
experence of solving certian problems of deployment by my own means will help
me get a better understanding of JSR-88.

--- Aaron Mulder <am...@alumni.princeton.edu> wrote:
> On Wed, 13 Aug 2003, Tim Urberg wrote:
> > I am willing to help with this.  Are we talking about a command line
> > deploy tool or a web interface or both?  I've worked on an OpenEJB
> > specific version of a web interface deploy tool.
> 
> 	Okay, Tim, I think *you* really *are* talking about the tool side
> -- the part that examines a set of DDBeans and presents a user interface.  
> Is that right?  That's the part that would be web-based or command-line 
> based.
> 
> Aaron
> 

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

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

On Wed, 13 Aug 2003, Tim Urberg wrote:
> I am willing to help with this.  Are we talking about a command line
> deploy tool or a web interface or both?  I've worked on an OpenEJB
> specific version of a web interface deploy tool.

	Okay, Tim, I think *you* really *are* talking about the tool side
-- the part that examines a set of DDBeans and presents a user interface.  
Is that right?  That's the part that would be web-based or command-line 
based.

Aaron

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Chris Opacki <ch...@yahoo.com>]

The actual implementation of the Deployment API. 

--- Tim Urberg <ti...@yahoo.com> wrote:
> I am willing to help with this.  Are we talking
> about a command line deploy
> tool or a web interface or both?  I've worked on an
> OpenEJB specific version of
> a web interface deploy tool.
> 
> --- Chris Opacki <ch...@yahoo.com> wrote:
> > I haven't checked out the license yet. Are the
> classes
> > in CVS?
> > 
> > I have started downloading all of the related
> specs to
> > collect all of that information.
> > 
> > It is a requirement for the Tool side to work
> connect
> > and not connected. I am assuming this will require
> > remote access to the serverside of the API.
> > 
> > So far it seems Jonathan D. and I are the only
> people
> > interested in this task.


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Tim Urberg <ti...@yahoo.com>]

I am willing to help with this.  Are we talking about a command line deploy
tool or a web interface or both?  I've worked on an OpenEJB specific version of
a web interface deploy tool.

--- Chris Opacki <ch...@yahoo.com> wrote:
> I haven't checked out the license yet. Are the classes
> in CVS?
> 
> I have started downloading all of the related specs to
> collect all of that information.
> 
> It is a requirement for the Tool side to work connect
> and not connected. I am assuming this will require
> remote access to the serverside of the API.
> 
> So far it seems Jonathan D. and I are the only people
> interested in this task.

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Chris Opacki <ch...@yahoo.com>]

I haven't checked out the license yet. Are the classes
in CVS?

I have started downloading all of the related specs to
collect all of that information.

It is a requirement for the Tool side to work connect
and not connected. I am assuming this will require
remote access to the serverside of the API.

So far it seems Jonathan D. and I are the only people
interested in this task.


--- Aaron Mulder <am...@alumni.princeton.edu>
wrote:
> On Wed, 13 Aug 2003, Chris Opacki wrote:
> > I have the javax.enterprise.deployment classes
> > downloaded from sun. Do we need anything else to
> start
> > the DDBean implementations? I'm not sure if anyone
> > else has started on these things... Jon Duty and I
> > (and anyone else interested) are ready to start on
> > these things.
> 
> 	The point is, we probably can't use the classes you
> downloaded
> from Sun.  Have you examined the license with care? 
> Are we allowed to
> freely redistribute them under our own license? 
> That not typically
> allowed.
> 
> 	Also, before starting on the DDBeans, we need to
> assemble the list 
> of deployment information that is actually required.
>  Otherwise, what will 
> the DDBeans represent?  We should probably also
> prioritize EJB, Web, J2CA, 
> and application metadata and tackle these one at a
> time.
> 
> 	We also need to figure out how the JSR-88 impl will
> communicate 
> with the server, since they're typically run in
> different JVMs, if not on 
> different machines altogether.
> 
> Aaron
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

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

On Wed, 13 Aug 2003, Chris Opacki wrote:
> I have the javax.enterprise.deployment classes
> downloaded from sun. Do we need anything else to start
> the DDBean implementations? I'm not sure if anyone
> else has started on these things... Jon Duty and I
> (and anyone else interested) are ready to start on
> these things.

	The point is, we probably can't use the classes you downloaded
from Sun.  Have you examined the license with care?  Are we allowed to
freely redistribute them under our own license?  That not typically
allowed.

	Also, before starting on the DDBeans, we need to assemble the list 
of deployment information that is actually required.  Otherwise, what will 
the DDBeans represent?  We should probably also prioritize EJB, Web, J2CA, 
and application metadata and tackle these one at a time.

	We also need to figure out how the JSR-88 impl will communicate 
with the server, since they're typically run in different JVMs, if not on 
different machines altogether.

Aaron

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Chris Opacki <ch...@yahoo.com>]

I have the javax.enterprise.deployment classes
downloaded from sun. Do we need anything else to start
the DDBean implementations? I'm not sure if anyone
else has started on these things... Jon Duty and I
(and anyone else interested) are ready to start on
these things.

--- Aaron Mulder <am...@alumni.princeton.edu>
wrote:
> 	IMHO the verifier and DDBeans should definitely be
> separate.  
> Presumably there will be some in-memory
> representation of the deployment
> information for EARs, EARs, JARs, etc. as well as a
> ClassLoader or some
> such where the actual classes are available.  I
> think the verifier and
> DDBeans would both want to operate based on these. 
> If the JSR-88 server
> impl wants to verify, it can populate the object
> tree and then run the
> verified on it, and if the server wants to verify it
> will likely already 
> have the object tree and can just run the verifier.
> 
> 	In any case, it also strikes me as better design to
> separate these 
> two bits of functionality ("configure J2EE metadata"
> and "validate  
> the contents of an EAR") instead of unnecessarily
> tying them together.
> 
> 	Finally, I'll be happy to contribute the
> javax.enterprise.deployment classes, but per the
> above I don't think this
> is necessary for starting on the verifier.
> 
> Aaron
> 
> On Wed, 13 Aug 2003, Chris Opacki wrote:
> > It doesn't matter that much to me. I think we can
> get
> > by with them separately. What does everyone else
> > think?
> > 
> > --- Jonathan Duty <jd...@jonandkerry.com> wrote:
> > > Do you want the DDBeans to be part of this
> module?
> > > ~Jonathan
> > > 
> > > Jonathan Duty
> > > Software Developer - eWashtenaw
> > > 
> > > 
> > > -----Original Message-----
> > > From: Chris Opacki
> [mailto:chris_opacki@yahoo.com] 
> > > Sent: Wednesday, August 13, 2003 11:59 AM
> > > To: geronimo-dev@incubator.apache.org
> > > Subject: RE: J2EE DeploymentManager ( was J2EE
> > > deployment verifier)
> > > 
> > > I would like to start implementing the DDBeans
> from
> > > JSR-88. I will start a new thread for JSR-88.
> > > 
> > > 
> > > 
> > > --- Srihari S <sr...@blr.pin.philips.com>
> wrote:
> > > > cool...so what are we waiting for!!!!
> > > > lets get started with the requirements/design
> of
> > > the
> > > > verifier..
> > > > any ideas on the way of working for these
> phases..
> > > > 
> > > > -----Original Message-----
> > > > From: Jonathan Duty
> [mailto:jduty@jonandkerry.com]
> > > > Sent: Wednesday, August 13, 2003 8:14 PM
> > > > To: geronimo-dev@incubator.apache.org;
> > > > weston_p@yahoo.com
> > > > Subject: RE: J2EE DeploymentManager ( was J2EE
> > > > deployment verifier)
> > > > 
> > > > 
> > > > I agree.  The verification engine really
> doesn't
> > > > need to implement the
> > > > deployment specs.  Later when we implement the
> > > > DeploymentManager in
> > > > front of it that's when we will have to worry
> > > about
> > > > implementing the
> > > > exact interfaces.  
> > > > 
> > > > ~Jonathan
> > > > 
> > > > 
> > > > Jonathan Duty
> > > > Software Developer - eWashtenaw
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Weston M. Price
> [mailto:weston_p@yahoo.com] 
> > > > Sent: Wednesday, August 13, 2003 5:48 AM
> > > > To: geronimo-dev@incubator.apache.org
> > > > Subject: Re: J2EE DeploymentManager ( was J2EE
> > > > deployment verifier)
> > > > 
> > > > I agree with Srihari in that the Verification
> > > > manager does not have to 
> > > > implement the spec interfaces, however, the
> > > > DeploymentManager does, this
> > > > 
> > > > would be where we would implment DDRoot,
> DDConfig
> > > > etc.....in some ways
> > > > the 
> > > > DeploymentManager would just use the services
> of
> > > the
> > > > VerificatinoEngine
> > > > as 
> > > > one step in the process of actual deployment. 
> > > > 
> > > > Is this in line with what you guys were
> thinking?
> > > > 
> > > > 
> > > > On Wednesday 13 August 2003 01:52 pm, Jonathan
> > > Duty
> > > > wrote:
> > > > > When we implement this module, we could
> actually
> > > > implement it to
> > > > exactly
> > > > > follow the API specs (JSR 88).  That means
> > > > implementing the
> > > > > DeploymentManager interface on top of it and
> > > such.
> > > >  That way any
> > > > > application (ant, Eclipse, etc) that is
> equipped
> > > > to deploy packages
> > > > > could interface with it.  It would just fall
> > > short
> > > > of actually
> > > > > communicating with MBeans and deploying the
> > > > package.
> > > > >
> > > > > When this module is used internally (within
> the
> > > > REAL deployment
> > > > manager)
> > > > > it could just bypass or override the
> > > > Verification's Deployment
> > > > manager.
> > > > >
> > > > > ~Jonathan
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Srihari S
> > > > [mailto:sriharis@blr.pin.philips.com]
> > > > > Sent: Wednesday, August 13, 2003 9:43 AM
> > > > > To: geronimo-dev@incubator.apache.org;
> > > > weston_p@yahoo.com
> > > > > Subject: RE: J2EE DeploymentManager ( was
> J2EE
> > > > deployment verifier)
> > > > >
> > > > > Hi All
> > > > >   When I was going thru the deployment api
> spec
> > > I
> > > > thought it would be
> > > > > good
> > > > > to bring up some points:
> > > > >
> > > > > From a preliminary reading of the spec i saw
> > > there
> > > > are no apis
> > > > > explicitly
> > > > > designed to do the verification
> > > > > of a deployable unit. From this I infer that
> the
> > > > verifier can be an
> > > > > internal
> > > > > module which could be used
> > > > > by the deploy tool. So we could go full
> steam on
> > > > its design and
> > > > > implementation. In this regard I am trying
> to
> > > > > jot the list of checks that our verifier
> will
> > > have
> > > > to do (This is
> > > > > mentioned
> > > > > in the j2ee specs).
> > > > > So in a way it will be equivalent to
> arriving at
> > > > requirement specs for
> > > > > the
> > > > > verifier.
> > > > > With the list of dos and donts that a
> verifier
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

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

	IMHO the verifier and DDBeans should definitely be separate.  
Presumably there will be some in-memory representation of the deployment
information for EARs, EARs, JARs, etc. as well as a ClassLoader or some
such where the actual classes are available.  I think the verifier and
DDBeans would both want to operate based on these.  If the JSR-88 server
impl wants to verify, it can populate the object tree and then run the
verified on it, and if the server wants to verify it will likely already 
have the object tree and can just run the verifier.

	In any case, it also strikes me as better design to separate these 
two bits of functionality ("configure J2EE metadata" and "validate  
the contents of an EAR") instead of unnecessarily tying them together.

	Finally, I'll be happy to contribute the
javax.enterprise.deployment classes, but per the above I don't think this
is necessary for starting on the verifier.

Aaron

On Wed, 13 Aug 2003, Chris Opacki wrote:
> It doesn't matter that much to me. I think we can get
> by with them separately. What does everyone else
> think?
> 
> --- Jonathan Duty <jd...@jonandkerry.com> wrote:
> > Do you want the DDBeans to be part of this module?
> > ~Jonathan
> > 
> > Jonathan Duty
> > Software Developer - eWashtenaw
> > 
> > 
> > -----Original Message-----
> > From: Chris Opacki [mailto:chris_opacki@yahoo.com] 
> > Sent: Wednesday, August 13, 2003 11:59 AM
> > To: geronimo-dev@incubator.apache.org
> > Subject: RE: J2EE DeploymentManager ( was J2EE
> > deployment verifier)
> > 
> > I would like to start implementing the DDBeans from
> > JSR-88. I will start a new thread for JSR-88.
> > 
> > 
> > 
> > --- Srihari S <sr...@blr.pin.philips.com> wrote:
> > > cool...so what are we waiting for!!!!
> > > lets get started with the requirements/design of
> > the
> > > verifier..
> > > any ideas on the way of working for these phases..
> > > 
> > > -----Original Message-----
> > > From: Jonathan Duty [mailto:jduty@jonandkerry.com]
> > > Sent: Wednesday, August 13, 2003 8:14 PM
> > > To: geronimo-dev@incubator.apache.org;
> > > weston_p@yahoo.com
> > > Subject: RE: J2EE DeploymentManager ( was J2EE
> > > deployment verifier)
> > > 
> > > 
> > > I agree.  The verification engine really doesn't
> > > need to implement the
> > > deployment specs.  Later when we implement the
> > > DeploymentManager in
> > > front of it that's when we will have to worry
> > about
> > > implementing the
> > > exact interfaces.  
> > > 
> > > ~Jonathan
> > > 
> > > 
> > > Jonathan Duty
> > > Software Developer - eWashtenaw
> > > 
> > > 
> > > -----Original Message-----
> > > From: Weston M. Price [mailto:weston_p@yahoo.com] 
> > > Sent: Wednesday, August 13, 2003 5:48 AM
> > > To: geronimo-dev@incubator.apache.org
> > > Subject: Re: J2EE DeploymentManager ( was J2EE
> > > deployment verifier)
> > > 
> > > I agree with Srihari in that the Verification
> > > manager does not have to 
> > > implement the spec interfaces, however, the
> > > DeploymentManager does, this
> > > 
> > > would be where we would implment DDRoot, DDConfig
> > > etc.....in some ways
> > > the 
> > > DeploymentManager would just use the services of
> > the
> > > VerificatinoEngine
> > > as 
> > > one step in the process of actual deployment. 
> > > 
> > > Is this in line with what you guys were thinking?
> > > 
> > > 
> > > On Wednesday 13 August 2003 01:52 pm, Jonathan
> > Duty
> > > wrote:
> > > > When we implement this module, we could actually
> > > implement it to
> > > exactly
> > > > follow the API specs (JSR 88).  That means
> > > implementing the
> > > > DeploymentManager interface on top of it and
> > such.
> > >  That way any
> > > > application (ant, Eclipse, etc) that is equipped
> > > to deploy packages
> > > > could interface with it.  It would just fall
> > short
> > > of actually
> > > > communicating with MBeans and deploying the
> > > package.
> > > >
> > > > When this module is used internally (within the
> > > REAL deployment
> > > manager)
> > > > it could just bypass or override the
> > > Verification's Deployment
> > > manager.
> > > >
> > > > ~Jonathan
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Srihari S
> > > [mailto:sriharis@blr.pin.philips.com]
> > > > Sent: Wednesday, August 13, 2003 9:43 AM
> > > > To: geronimo-dev@incubator.apache.org;
> > > weston_p@yahoo.com
> > > > Subject: RE: J2EE DeploymentManager ( was J2EE
> > > deployment verifier)
> > > >
> > > > Hi All
> > > >   When I was going thru the deployment api spec
> > I
> > > thought it would be
> > > > good
> > > > to bring up some points:
> > > >
> > > > From a preliminary reading of the spec i saw
> > there
> > > are no apis
> > > > explicitly
> > > > designed to do the verification
> > > > of a deployable unit. From this I infer that the
> > > verifier can be an
> > > > internal
> > > > module which could be used
> > > > by the deploy tool. So we could go full steam on
> > > its design and
> > > > implementation. In this regard I am trying to
> > > > jot the list of checks that our verifier will
> > have
> > > to do (This is
> > > > mentioned
> > > > in the j2ee specs).
> > > > So in a way it will be equivalent to arriving at
> > > requirement specs for
> > > > the
> > > > verifier.
> > > > With the list of dos and donts that a verifier
> > has
> > > to achieve we could
> > > > go
> > > > abt with design.Also the design of
> > > > ant hooks can be taken care.Can we??
> > > >
> > > > Next is something abt the big picture. Certainly
> > > the verifer is a
> > > small
> > > > part
> > > > of the deployment process.
> > > > But to achieve compliance we will have to
> > > implement the deployment
> > > spec
> > > > as a
> > > > whole. Has anyone given
> > > > thought to this issue?
> > > >
> > > > regards
> > > > Hari
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Weston M. Price
> > [mailto:weston_p@yahoo.com]
> > > > Sent: Wednesday, August 13, 2003 1:33 AM
> > > > To: geronimo-dev@incubator.apache.org
> > > > Subject: Re: J2EE DeploymentManager ( was J2EE
> > > deployment verifier)
> > > >
> > > >
> > > > No, I think splitting them up would be good....
> > > >
> > > > Weston
> > > >
> > > > On Tuesday 12 August 2003 11:41 pm, Jonathan
> > Duty
> > > wrote:
> > > > > I'm creating a maven module to add to the cvs
> > > project.
> > > > > Do we want to plan on the DeploymentManager,
> > > VerificationEngine, and
> > > > > DeploymentEngine being in one module?
> > > > >
> > > > > What do you all think?
> > > > >
> > > > > ~Jonathan
> > > > >
> > > > > Weston M. Price wrote:
> > > > > >Just thought I should start a new thread....
> > > > > >
> > > > > >My KMail was getting dominated!
> > > > > >
> > > > > >Weston
> > > 
> > > 
> > 
> > 
> > 
> === message truncated ===
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
> 

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

["Weston M. Price" <we...@yahoo.com>]

I second this!

Weston

On Wednesday 13 August 2003 04:49 pm, Labeeb Syed wrote:
> The primary issue I am concerned with is J2EE
> compliance. The Deploy component should be able to
> delegate certain methods to the Verifier component
> without a change in its own behavior. If we worry
> about the deployment manager later, it will be a lot
> more troublesome and cause some major confusion in
> terms of behaviour and responsibilty of the various
> methods. Do you guys think we can get by and address
> such issues later on?
> Secondly, there seems there will be an inherent
> overlapping of responsibilities within the components.
> I have run into such issues before and would like to
> avoid it altogether if possible. Sometimes you end up
> re-coding and re-designing the whole component. Also
> in the future someone else might be going through the
> code, it may make it more difficult to enhance, test
> or debug the components. If we strictly adhere to the
> spec, it will ensure better maintainability and
> longevity. This my opinion in regards to the two
> components.
>
> --- Chris Opacki <ch...@yahoo.com> wrote:
> > It doesn't matter that much to me. I think we can
> > get
> > by with them separately. What does everyone else
> > think?
> >
> > --- Jonathan Duty <jd...@jonandkerry.com> wrote:
> > > Do you want the DDBeans to be part of this module?
> > > ~Jonathan
> > >
> > > Jonathan Duty
> > > Software Developer - eWashtenaw
> > >
> > >
> > > -----Original Message-----
> > > From: Chris Opacki [mailto:chris_opacki@yahoo.com]
> > >
> > > Sent: Wednesday, August 13, 2003 11:59 AM
> > > To: geronimo-dev@incubator.apache.org
> > > Subject: RE: J2EE DeploymentManager ( was J2EE
> > > deployment verifier)
> > >
> > > I would like to start implementing the DDBeans
> >
> > from
> >
> > > JSR-88. I will start a new thread for JSR-88.
> > >
> > >
> > >
> > > --- Srihari S <sr...@blr.pin.philips.com>
> >
> > wrote:
> > > > cool...so what are we waiting for!!!!
> > > > lets get started with the requirements/design of
> > >
> > > the
> > >
> > > > verifier..
> > > > any ideas on the way of working for these
> >
> > phases..
> >
> > > > -----Original Message-----
> > > > From: Jonathan Duty
> >
> > [mailto:jduty@jonandkerry.com]
> >
> > > > Sent: Wednesday, August 13, 2003 8:14 PM
> > > > To: geronimo-dev@incubator.apache.org;
> > > > weston_p@yahoo.com
> > > > Subject: RE: J2EE DeploymentManager ( was J2EE
> > > > deployment verifier)
> > > >
> > > >
> > > > I agree.  The verification engine really doesn't
> > > > need to implement the
> > > > deployment specs.  Later when we implement the
> > > > DeploymentManager in
> > > > front of it that's when we will have to worry
> > >
> > > about
> > >
> > > > implementing the
> > > > exact interfaces.
> > > >
> > > > ~Jonathan
> > > >
> > > >
> > > > Jonathan Duty
> > > > Software Developer - eWashtenaw
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Weston M. Price
> >
> > [mailto:weston_p@yahoo.com]
> >
> > > > Sent: Wednesday, August 13, 2003 5:48 AM
> > > > To: geronimo-dev@incubator.apache.org
> > > > Subject: Re: J2EE DeploymentManager ( was J2EE
> > > > deployment verifier)
> > > >
> > > > I agree with Srihari in that the Verification
> > > > manager does not have to
> > > > implement the spec interfaces, however, the
> > > > DeploymentManager does, this
> > > >
> > > > would be where we would implment DDRoot,
> >
> > DDConfig
> >
> > > > etc.....in some ways
> > > > the
> > > > DeploymentManager would just use the services of
> > >
> > > the
> > >
> > > > VerificatinoEngine
> > > > as
> > > > one step in the process of actual deployment.
> > > >
> > > > Is this in line with what you guys were
> >
> > thinking?
> >
> > > > On Wednesday 13 August 2003 01:52 pm, Jonathan
> > >
> > > Duty
> > >
> > > > wrote:
> > > > > When we implement this module, we could
> >
> > actually
> >
> > > > implement it to
> > > > exactly
> > > >
> > > > > follow the API specs (JSR 88).  That means
> > > >
> > > > implementing the
> > > >
> > > > > DeploymentManager interface on top of it and
> > >
> > > such.
> > >
> > > >  That way any
> > > >
> > > > > application (ant, Eclipse, etc) that is
> >
> > equipped
> >
> > > > to deploy packages
> > > >
> > > > > could interface with it.  It would just fall
> > >
> > > short
> > >
> > > > of actually
> > > >
> > > > > communicating with MBeans and deploying the
> > > >
> > > > package.
> > > >
> > > > > When this module is used internally (within
> >
> > the
> >
> > > > REAL deployment
> > > > manager)
> > > >
> > > > > it could just bypass or override the
> > > >
> > > > Verification's Deployment
> > > > manager.
> > > >
> > > > > ~Jonathan
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Srihari S
> > > >
> > > > [mailto:sriharis@blr.pin.philips.com]
> > > >
> > > > > Sent: Wednesday, August 13, 2003 9:43 AM
> > > > > To: geronimo-dev@incubator.apache.org;
> > > >
> > > > weston_p@yahoo.com
> > > >
> > > > > Subject: RE: J2EE DeploymentManager ( was J2EE
> > > >
> > > > deployment verifier)
> > > >
> > > > > Hi All
> > > > >   When I was going thru the deployment api
> >
> > spec
> >
> > > I
> > >
> > > > thought it would be
> > > >
> > > > > good
> > > > > to bring up some points:
> > > > >
> > > > > From a preliminary reading of the spec i saw
> > >
> > > there
> > >
> > > > are no apis
> > > >
> > > > > explicitly
> > > > > designed to do the verification
> > > > > of a deployable unit. From this I infer that
> >
> > the
> >
> > > > verifier can be an
> > > >
> > > > > internal
> > > > > module which could be used
> > > > > by the deploy tool. So we could go full steam
> >
> > on
> >
> > > > its design and
> > > >
> > > > > implementation. In this regard I am trying to
> > > > > jot the list of checks that our verifier will
> > >
> > > have
> > >
> > > > to do (This is
> > > >
> > > > > mentioned
> > > > > in the j2ee specs).
> > > > > So in a way it will be equivalent to arriving
> >
> > at
> >
> > > > requirement specs for
> > > >
> > > > > the
> > > > > verifier.
> > > > > With the list of dos and donts that a verifier
> > >
> > > has
> > >
> > > > to achieve we could
> > > >
> > > > > go
> > > > > abt with design.Also the design of
> > > > > ant hooks can be taken care.Can we??
> > > > >
> > > > > Next is something abt the big picture.
> >
> > Certainly
> >
> > > > the verifer is a
> > > > small
> > > >
> > > > > part
> > > > > of the deployment process.
> > > > > But to achieve compliance we will have to
> > > >
> > > > implement the deployment
> > > > spec
> > > >
> > > > > as a
> > > > > whole. Has anyone given
> > > > > thought to this issue?
> > > > >
> > > > > regards
> > > > > Hari
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Weston M. Price
> > >
> > > [mailto:weston_p@yahoo.com]
> > >
> > > > > Sent: Wednesday, August 13, 2003 1:33 AM
> > > > > To: geronimo-dev@incubator.apache.org
> > > > > Subject: Re: J2EE DeploymentManager ( was J2EE
> > > >
> > > > deployment verifier)
> > > >
> > > > > No, I think splitting them up would be
> >
> > good....
> >
> > > > > Weston
>
> === message truncated ===
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Labeeb Syed <an...@yahoo.com>]

Yes, Aaron you are correct. My concern is not with the
current spec only, but future specs too, perhaps two
iterations or even the next down (which seems to be a
trend), it may be decided to add the Deployment
Manager to the spec. This is the issue I was trying to
bring up. Either way is fine.



--- Aaron Mulder <am...@alumni.princeton.edu>
wrote:
> 	What spec are you talking about?  There is no spec
> for a verifier
> to adhere to.  The spec that a deployer could
> concievably adhere to says
> nothing about verification, or about the specific
> representation of
> server-specific information.  I'm not sure how you
> can take these two
> components and "strictly adhere to the spec" for
> both of them.  And for
> deployment, it isn't really an option to have a
> JSR-88 implementation that
> doesn't "strictly adhere to the spec" any more that
> we could have a
> non-compliant EJB container or web container.
> 
> Aaron
> 
> On Wed, 13 Aug 2003, Labeeb Syed wrote:
> > The primary issue I am concerned with is J2EE
> compliance. The Deploy
> > component should be able to delegate certain
> methods to the Verifier
> > component without a change in its own behavior. If
> we worry about the
> > deployment manager later, it will be a lot more
> troublesome and cause
> > some major confusion in terms of behaviour and
> responsibilty of the
> > various methods. Do you guys think we can get by
> and address such issues
> > later on?
> >
> > Secondly, there seems there will be an inherent
> overlapping of
> > responsibilities within the components. I have run
> into such issues
> > before and would like to avoid it altogether if
> possible. Sometimes you
> > end up re-coding and re-designing the whole
> component. Also in the
> > future someone else might be going through the
> code, it may make it more
> > difficult to enhance, test or debug the
> components. If we strictly
> > adhere to the spec, it will ensure better
> maintainability and longevity.
> > This my opinion in regards to the two components.
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

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

	What spec are you talking about?  There is no spec for a verifier
to adhere to.  The spec that a deployer could concievably adhere to says
nothing about verification, or about the specific representation of
server-specific information.  I'm not sure how you can take these two
components and "strictly adhere to the spec" for both of them.  And for
deployment, it isn't really an option to have a JSR-88 implementation that
doesn't "strictly adhere to the spec" any more that we could have a
non-compliant EJB container or web container.

Aaron

On Wed, 13 Aug 2003, Labeeb Syed wrote:
> The primary issue I am concerned with is J2EE compliance. The Deploy
> component should be able to delegate certain methods to the Verifier
> component without a change in its own behavior. If we worry about the
> deployment manager later, it will be a lot more troublesome and cause
> some major confusion in terms of behaviour and responsibilty of the
> various methods. Do you guys think we can get by and address such issues
> later on?
>
> Secondly, there seems there will be an inherent overlapping of
> responsibilities within the components. I have run into such issues
> before and would like to avoid it altogether if possible. Sometimes you
> end up re-coding and re-designing the whole component. Also in the
> future someone else might be going through the code, it may make it more
> difficult to enhance, test or debug the components. If we strictly
> adhere to the spec, it will ensure better maintainability and longevity.
> This my opinion in regards to the two components.

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Labeeb Syed <an...@yahoo.com>]

The primary issue I am concerned with is J2EE
compliance. The Deploy component should be able to 
delegate certain methods to the Verifier component
without a change in its own behavior. If we worry
about the deployment manager later, it will be a lot
more troublesome and cause some major confusion in
terms of behaviour and responsibilty of the various
methods. Do you guys think we can get by and address
such issues later on?
Secondly, there seems there will be an inherent
overlapping of responsibilities within the components.
I have run into such issues before and would like to
avoid it altogether if possible. Sometimes you end up
re-coding and re-designing the whole component. Also
in the future someone else might be going through the
code, it may make it more difficult to enhance, test
or debug the components. If we strictly adhere to the
spec, it will ensure better maintainability and
longevity. This my opinion in regards to the two
components.


--- Chris Opacki <ch...@yahoo.com> wrote:
> It doesn't matter that much to me. I think we can
> get
> by with them separately. What does everyone else
> think?
> 
> --- Jonathan Duty <jd...@jonandkerry.com> wrote:
> > Do you want the DDBeans to be part of this module?
> > ~Jonathan
> > 
> > Jonathan Duty
> > Software Developer - eWashtenaw
> > 
> > 
> > -----Original Message-----
> > From: Chris Opacki [mailto:chris_opacki@yahoo.com]
> 
> > Sent: Wednesday, August 13, 2003 11:59 AM
> > To: geronimo-dev@incubator.apache.org
> > Subject: RE: J2EE DeploymentManager ( was J2EE
> > deployment verifier)
> > 
> > I would like to start implementing the DDBeans
> from
> > JSR-88. I will start a new thread for JSR-88.
> > 
> > 
> > 
> > --- Srihari S <sr...@blr.pin.philips.com>
> wrote:
> > > cool...so what are we waiting for!!!!
> > > lets get started with the requirements/design of
> > the
> > > verifier..
> > > any ideas on the way of working for these
> phases..
> > > 
> > > -----Original Message-----
> > > From: Jonathan Duty
> [mailto:jduty@jonandkerry.com]
> > > Sent: Wednesday, August 13, 2003 8:14 PM
> > > To: geronimo-dev@incubator.apache.org;
> > > weston_p@yahoo.com
> > > Subject: RE: J2EE DeploymentManager ( was J2EE
> > > deployment verifier)
> > > 
> > > 
> > > I agree.  The verification engine really doesn't
> > > need to implement the
> > > deployment specs.  Later when we implement the
> > > DeploymentManager in
> > > front of it that's when we will have to worry
> > about
> > > implementing the
> > > exact interfaces.  
> > > 
> > > ~Jonathan
> > > 
> > > 
> > > Jonathan Duty
> > > Software Developer - eWashtenaw
> > > 
> > > 
> > > -----Original Message-----
> > > From: Weston M. Price
> [mailto:weston_p@yahoo.com] 
> > > Sent: Wednesday, August 13, 2003 5:48 AM
> > > To: geronimo-dev@incubator.apache.org
> > > Subject: Re: J2EE DeploymentManager ( was J2EE
> > > deployment verifier)
> > > 
> > > I agree with Srihari in that the Verification
> > > manager does not have to 
> > > implement the spec interfaces, however, the
> > > DeploymentManager does, this
> > > 
> > > would be where we would implment DDRoot,
> DDConfig
> > > etc.....in some ways
> > > the 
> > > DeploymentManager would just use the services of
> > the
> > > VerificatinoEngine
> > > as 
> > > one step in the process of actual deployment. 
> > > 
> > > Is this in line with what you guys were
> thinking?
> > > 
> > > 
> > > On Wednesday 13 August 2003 01:52 pm, Jonathan
> > Duty
> > > wrote:
> > > > When we implement this module, we could
> actually
> > > implement it to
> > > exactly
> > > > follow the API specs (JSR 88).  That means
> > > implementing the
> > > > DeploymentManager interface on top of it and
> > such.
> > >  That way any
> > > > application (ant, Eclipse, etc) that is
> equipped
> > > to deploy packages
> > > > could interface with it.  It would just fall
> > short
> > > of actually
> > > > communicating with MBeans and deploying the
> > > package.
> > > >
> > > > When this module is used internally (within
> the
> > > REAL deployment
> > > manager)
> > > > it could just bypass or override the
> > > Verification's Deployment
> > > manager.
> > > >
> > > > ~Jonathan
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Srihari S
> > > [mailto:sriharis@blr.pin.philips.com]
> > > > Sent: Wednesday, August 13, 2003 9:43 AM
> > > > To: geronimo-dev@incubator.apache.org;
> > > weston_p@yahoo.com
> > > > Subject: RE: J2EE DeploymentManager ( was J2EE
> > > deployment verifier)
> > > >
> > > > Hi All
> > > >   When I was going thru the deployment api
> spec
> > I
> > > thought it would be
> > > > good
> > > > to bring up some points:
> > > >
> > > > From a preliminary reading of the spec i saw
> > there
> > > are no apis
> > > > explicitly
> > > > designed to do the verification
> > > > of a deployable unit. From this I infer that
> the
> > > verifier can be an
> > > > internal
> > > > module which could be used
> > > > by the deploy tool. So we could go full steam
> on
> > > its design and
> > > > implementation. In this regard I am trying to
> > > > jot the list of checks that our verifier will
> > have
> > > to do (This is
> > > > mentioned
> > > > in the j2ee specs).
> > > > So in a way it will be equivalent to arriving
> at
> > > requirement specs for
> > > > the
> > > > verifier.
> > > > With the list of dos and donts that a verifier
> > has
> > > to achieve we could
> > > > go
> > > > abt with design.Also the design of
> > > > ant hooks can be taken care.Can we??
> > > >
> > > > Next is something abt the big picture.
> Certainly
> > > the verifer is a
> > > small
> > > > part
> > > > of the deployment process.
> > > > But to achieve compliance we will have to
> > > implement the deployment
> > > spec
> > > > as a
> > > > whole. Has anyone given
> > > > thought to this issue?
> > > >
> > > > regards
> > > > Hari
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Weston M. Price
> > [mailto:weston_p@yahoo.com]
> > > > Sent: Wednesday, August 13, 2003 1:33 AM
> > > > To: geronimo-dev@incubator.apache.org
> > > > Subject: Re: J2EE DeploymentManager ( was J2EE
> > > deployment verifier)
> > > >
> > > >
> > > > No, I think splitting them up would be
> good....
> > > >
> > > > Weston
> > > >
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Chris Opacki <ch...@yahoo.com>]

It doesn't matter that much to me. I think we can get
by with them separately. What does everyone else
think?

--- Jonathan Duty <jd...@jonandkerry.com> wrote:
> Do you want the DDBeans to be part of this module?
> ~Jonathan
> 
> Jonathan Duty
> Software Developer - eWashtenaw
> 
> 
> -----Original Message-----
> From: Chris Opacki [mailto:chris_opacki@yahoo.com] 
> Sent: Wednesday, August 13, 2003 11:59 AM
> To: geronimo-dev@incubator.apache.org
> Subject: RE: J2EE DeploymentManager ( was J2EE
> deployment verifier)
> 
> I would like to start implementing the DDBeans from
> JSR-88. I will start a new thread for JSR-88.
> 
> 
> 
> --- Srihari S <sr...@blr.pin.philips.com> wrote:
> > cool...so what are we waiting for!!!!
> > lets get started with the requirements/design of
> the
> > verifier..
> > any ideas on the way of working for these phases..
> > 
> > -----Original Message-----
> > From: Jonathan Duty [mailto:jduty@jonandkerry.com]
> > Sent: Wednesday, August 13, 2003 8:14 PM
> > To: geronimo-dev@incubator.apache.org;
> > weston_p@yahoo.com
> > Subject: RE: J2EE DeploymentManager ( was J2EE
> > deployment verifier)
> > 
> > 
> > I agree.  The verification engine really doesn't
> > need to implement the
> > deployment specs.  Later when we implement the
> > DeploymentManager in
> > front of it that's when we will have to worry
> about
> > implementing the
> > exact interfaces.  
> > 
> > ~Jonathan
> > 
> > 
> > Jonathan Duty
> > Software Developer - eWashtenaw
> > 
> > 
> > -----Original Message-----
> > From: Weston M. Price [mailto:weston_p@yahoo.com] 
> > Sent: Wednesday, August 13, 2003 5:48 AM
> > To: geronimo-dev@incubator.apache.org
> > Subject: Re: J2EE DeploymentManager ( was J2EE
> > deployment verifier)
> > 
> > I agree with Srihari in that the Verification
> > manager does not have to 
> > implement the spec interfaces, however, the
> > DeploymentManager does, this
> > 
> > would be where we would implment DDRoot, DDConfig
> > etc.....in some ways
> > the 
> > DeploymentManager would just use the services of
> the
> > VerificatinoEngine
> > as 
> > one step in the process of actual deployment. 
> > 
> > Is this in line with what you guys were thinking?
> > 
> > 
> > On Wednesday 13 August 2003 01:52 pm, Jonathan
> Duty
> > wrote:
> > > When we implement this module, we could actually
> > implement it to
> > exactly
> > > follow the API specs (JSR 88).  That means
> > implementing the
> > > DeploymentManager interface on top of it and
> such.
> >  That way any
> > > application (ant, Eclipse, etc) that is equipped
> > to deploy packages
> > > could interface with it.  It would just fall
> short
> > of actually
> > > communicating with MBeans and deploying the
> > package.
> > >
> > > When this module is used internally (within the
> > REAL deployment
> > manager)
> > > it could just bypass or override the
> > Verification's Deployment
> > manager.
> > >
> > > ~Jonathan
> > >
> > >
> > > -----Original Message-----
> > > From: Srihari S
> > [mailto:sriharis@blr.pin.philips.com]
> > > Sent: Wednesday, August 13, 2003 9:43 AM
> > > To: geronimo-dev@incubator.apache.org;
> > weston_p@yahoo.com
> > > Subject: RE: J2EE DeploymentManager ( was J2EE
> > deployment verifier)
> > >
> > > Hi All
> > >   When I was going thru the deployment api spec
> I
> > thought it would be
> > > good
> > > to bring up some points:
> > >
> > > From a preliminary reading of the spec i saw
> there
> > are no apis
> > > explicitly
> > > designed to do the verification
> > > of a deployable unit. From this I infer that the
> > verifier can be an
> > > internal
> > > module which could be used
> > > by the deploy tool. So we could go full steam on
> > its design and
> > > implementation. In this regard I am trying to
> > > jot the list of checks that our verifier will
> have
> > to do (This is
> > > mentioned
> > > in the j2ee specs).
> > > So in a way it will be equivalent to arriving at
> > requirement specs for
> > > the
> > > verifier.
> > > With the list of dos and donts that a verifier
> has
> > to achieve we could
> > > go
> > > abt with design.Also the design of
> > > ant hooks can be taken care.Can we??
> > >
> > > Next is something abt the big picture. Certainly
> > the verifer is a
> > small
> > > part
> > > of the deployment process.
> > > But to achieve compliance we will have to
> > implement the deployment
> > spec
> > > as a
> > > whole. Has anyone given
> > > thought to this issue?
> > >
> > > regards
> > > Hari
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Weston M. Price
> [mailto:weston_p@yahoo.com]
> > > Sent: Wednesday, August 13, 2003 1:33 AM
> > > To: geronimo-dev@incubator.apache.org
> > > Subject: Re: J2EE DeploymentManager ( was J2EE
> > deployment verifier)
> > >
> > >
> > > No, I think splitting them up would be good....
> > >
> > > Weston
> > >
> > > On Tuesday 12 August 2003 11:41 pm, Jonathan
> Duty
> > wrote:
> > > > I'm creating a maven module to add to the cvs
> > project.
> > > > Do we want to plan on the DeploymentManager,
> > VerificationEngine, and
> > > > DeploymentEngine being in one module?
> > > >
> > > > What do you all think?
> > > >
> > > > ~Jonathan
> > > >
> > > > Weston M. Price wrote:
> > > > >Just thought I should start a new thread....
> > > > >
> > > > >My KMail was getting dominated!
> > > > >
> > > > >Weston
> > 
> > 
> 
> 
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Jonathan Duty <jd...@jonandkerry.com>]

Do you want the DDBeans to be part of this module?
~Jonathan

Jonathan Duty
Software Developer - eWashtenaw


-----Original Message-----
From: Chris Opacki [mailto:chris_opacki@yahoo.com] 
Sent: Wednesday, August 13, 2003 11:59 AM
To: geronimo-dev@incubator.apache.org
Subject: RE: J2EE DeploymentManager ( was J2EE deployment verifier)

I would like to start implementing the DDBeans from
JSR-88. I will start a new thread for JSR-88.



--- Srihari S <sr...@blr.pin.philips.com> wrote:
> cool...so what are we waiting for!!!!
> lets get started with the requirements/design of the
> verifier..
> any ideas on the way of working for these phases..
> 
> -----Original Message-----
> From: Jonathan Duty [mailto:jduty@jonandkerry.com]
> Sent: Wednesday, August 13, 2003 8:14 PM
> To: geronimo-dev@incubator.apache.org;
> weston_p@yahoo.com
> Subject: RE: J2EE DeploymentManager ( was J2EE
> deployment verifier)
> 
> 
> I agree.  The verification engine really doesn't
> need to implement the
> deployment specs.  Later when we implement the
> DeploymentManager in
> front of it that's when we will have to worry about
> implementing the
> exact interfaces.  
> 
> ~Jonathan
> 
> 
> Jonathan Duty
> Software Developer - eWashtenaw
> 
> 
> -----Original Message-----
> From: Weston M. Price [mailto:weston_p@yahoo.com] 
> Sent: Wednesday, August 13, 2003 5:48 AM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: J2EE DeploymentManager ( was J2EE
> deployment verifier)
> 
> I agree with Srihari in that the Verification
> manager does not have to 
> implement the spec interfaces, however, the
> DeploymentManager does, this
> 
> would be where we would implment DDRoot, DDConfig
> etc.....in some ways
> the 
> DeploymentManager would just use the services of the
> VerificatinoEngine
> as 
> one step in the process of actual deployment. 
> 
> Is this in line with what you guys were thinking?
> 
> 
> On Wednesday 13 August 2003 01:52 pm, Jonathan Duty
> wrote:
> > When we implement this module, we could actually
> implement it to
> exactly
> > follow the API specs (JSR 88).  That means
> implementing the
> > DeploymentManager interface on top of it and such.
>  That way any
> > application (ant, Eclipse, etc) that is equipped
> to deploy packages
> > could interface with it.  It would just fall short
> of actually
> > communicating with MBeans and deploying the
> package.
> >
> > When this module is used internally (within the
> REAL deployment
> manager)
> > it could just bypass or override the
> Verification's Deployment
> manager.
> >
> > ~Jonathan
> >
> >
> > -----Original Message-----
> > From: Srihari S
> [mailto:sriharis@blr.pin.philips.com]
> > Sent: Wednesday, August 13, 2003 9:43 AM
> > To: geronimo-dev@incubator.apache.org;
> weston_p@yahoo.com
> > Subject: RE: J2EE DeploymentManager ( was J2EE
> deployment verifier)
> >
> > Hi All
> >   When I was going thru the deployment api spec I
> thought it would be
> > good
> > to bring up some points:
> >
> > From a preliminary reading of the spec i saw there
> are no apis
> > explicitly
> > designed to do the verification
> > of a deployable unit. From this I infer that the
> verifier can be an
> > internal
> > module which could be used
> > by the deploy tool. So we could go full steam on
> its design and
> > implementation. In this regard I am trying to
> > jot the list of checks that our verifier will have
> to do (This is
> > mentioned
> > in the j2ee specs).
> > So in a way it will be equivalent to arriving at
> requirement specs for
> > the
> > verifier.
> > With the list of dos and donts that a verifier has
> to achieve we could
> > go
> > abt with design.Also the design of
> > ant hooks can be taken care.Can we??
> >
> > Next is something abt the big picture. Certainly
> the verifer is a
> small
> > part
> > of the deployment process.
> > But to achieve compliance we will have to
> implement the deployment
> spec
> > as a
> > whole. Has anyone given
> > thought to this issue?
> >
> > regards
> > Hari
> >
> >
> >
> > -----Original Message-----
> > From: Weston M. Price [mailto:weston_p@yahoo.com]
> > Sent: Wednesday, August 13, 2003 1:33 AM
> > To: geronimo-dev@incubator.apache.org
> > Subject: Re: J2EE DeploymentManager ( was J2EE
> deployment verifier)
> >
> >
> > No, I think splitting them up would be good....
> >
> > Weston
> >
> > On Tuesday 12 August 2003 11:41 pm, Jonathan Duty
> wrote:
> > > I'm creating a maven module to add to the cvs
> project.
> > > Do we want to plan on the DeploymentManager,
> VerificationEngine, and
> > > DeploymentEngine being in one module?
> > >
> > > What do you all think?
> > >
> > > ~Jonathan
> > >
> > > Weston M. Price wrote:
> > > >Just thought I should start a new thread....
> > > >
> > > >My KMail was getting dominated!
> > > >
> > > >Weston
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Jonathan Duty <jd...@jonandkerry.com>]

If it is not included in the verification module, let me know.  I would
like to be a part of it.
Thanks,
~Jonathan

Jonathan Duty
Software Developer - eWashtenaw


-----Original Message-----
From: Chris Opacki [mailto:chris_opacki@yahoo.com] 
Sent: Wednesday, August 13, 2003 11:59 AM
To: geronimo-dev@incubator.apache.org
Subject: RE: J2EE DeploymentManager ( was J2EE deployment verifier)

I would like to start implementing the DDBeans from
JSR-88. I will start a new thread for JSR-88.



--- Srihari S <sr...@blr.pin.philips.com> wrote:
> cool...so what are we waiting for!!!!
> lets get started with the requirements/design of the
> verifier..
> any ideas on the way of working for these phases..
> 
> -----Original Message-----
> From: Jonathan Duty [mailto:jduty@jonandkerry.com]
> Sent: Wednesday, August 13, 2003 8:14 PM
> To: geronimo-dev@incubator.apache.org;
> weston_p@yahoo.com
> Subject: RE: J2EE DeploymentManager ( was J2EE
> deployment verifier)
> 
> 
> I agree.  The verification engine really doesn't
> need to implement the
> deployment specs.  Later when we implement the
> DeploymentManager in
> front of it that's when we will have to worry about
> implementing the
> exact interfaces.  
> 
> ~Jonathan
> 
> 
> Jonathan Duty
> Software Developer - eWashtenaw
> 
> 
> -----Original Message-----
> From: Weston M. Price [mailto:weston_p@yahoo.com] 
> Sent: Wednesday, August 13, 2003 5:48 AM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: J2EE DeploymentManager ( was J2EE
> deployment verifier)
> 
> I agree with Srihari in that the Verification
> manager does not have to 
> implement the spec interfaces, however, the
> DeploymentManager does, this
> 
> would be where we would implment DDRoot, DDConfig
> etc.....in some ways
> the 
> DeploymentManager would just use the services of the
> VerificatinoEngine
> as 
> one step in the process of actual deployment. 
> 
> Is this in line with what you guys were thinking?
> 
> 
> On Wednesday 13 August 2003 01:52 pm, Jonathan Duty
> wrote:
> > When we implement this module, we could actually
> implement it to
> exactly
> > follow the API specs (JSR 88).  That means
> implementing the
> > DeploymentManager interface on top of it and such.
>  That way any
> > application (ant, Eclipse, etc) that is equipped
> to deploy packages
> > could interface with it.  It would just fall short
> of actually
> > communicating with MBeans and deploying the
> package.
> >
> > When this module is used internally (within the
> REAL deployment
> manager)
> > it could just bypass or override the
> Verification's Deployment
> manager.
> >
> > ~Jonathan
> >
> >
> > -----Original Message-----
> > From: Srihari S
> [mailto:sriharis@blr.pin.philips.com]
> > Sent: Wednesday, August 13, 2003 9:43 AM
> > To: geronimo-dev@incubator.apache.org;
> weston_p@yahoo.com
> > Subject: RE: J2EE DeploymentManager ( was J2EE
> deployment verifier)
> >
> > Hi All
> >   When I was going thru the deployment api spec I
> thought it would be
> > good
> > to bring up some points:
> >
> > From a preliminary reading of the spec i saw there
> are no apis
> > explicitly
> > designed to do the verification
> > of a deployable unit. From this I infer that the
> verifier can be an
> > internal
> > module which could be used
> > by the deploy tool. So we could go full steam on
> its design and
> > implementation. In this regard I am trying to
> > jot the list of checks that our verifier will have
> to do (This is
> > mentioned
> > in the j2ee specs).
> > So in a way it will be equivalent to arriving at
> requirement specs for
> > the
> > verifier.
> > With the list of dos and donts that a verifier has
> to achieve we could
> > go
> > abt with design.Also the design of
> > ant hooks can be taken care.Can we??
> >
> > Next is something abt the big picture. Certainly
> the verifer is a
> small
> > part
> > of the deployment process.
> > But to achieve compliance we will have to
> implement the deployment
> spec
> > as a
> > whole. Has anyone given
> > thought to this issue?
> >
> > regards
> > Hari
> >
> >
> >
> > -----Original Message-----
> > From: Weston M. Price [mailto:weston_p@yahoo.com]
> > Sent: Wednesday, August 13, 2003 1:33 AM
> > To: geronimo-dev@incubator.apache.org
> > Subject: Re: J2EE DeploymentManager ( was J2EE
> deployment verifier)
> >
> >
> > No, I think splitting them up would be good....
> >
> > Weston
> >
> > On Tuesday 12 August 2003 11:41 pm, Jonathan Duty
> wrote:
> > > I'm creating a maven module to add to the cvs
> project.
> > > Do we want to plan on the DeploymentManager,
> VerificationEngine, and
> > > DeploymentEngine being in one module?
> > >
> > > What do you all think?
> > >
> > > ~Jonathan
> > >
> > > Weston M. Price wrote:
> > > >Just thought I should start a new thread....
> > > >
> > > >My KMail was getting dominated!
> > > >
> > > >Weston
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

[Chris Opacki <ch...@yahoo.com>]

That's not a problem. Jon is interested in working on
this stuff too.

--- James Strachan <ja...@yahoo.co.uk> wrote:
> 
> On Wednesday, August 13, 2003, at 04:59  pm, Chris
> Opacki wrote:
> 
> > I would like to start implementing the DDBeans
> from
> > JSR-88. I will start a new thread for JSR-88.
> 
> Cool. Before you start - I'm not sure if we can
> reuse Sun's 
> distribution of the API due to their licence
> restrictions (we should 
> check).
> 
> Someone might have to do what Dain did for the EJB
> stuff and hand type 
> in all the java code to create the JSR 88 APIs -
> unfortunately. Once 
> its compiled we could do a quick check that the
> class files seem 
> similar to catch any typeos.
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

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

I would suggest that we check for serial ids on all of our classes... 
where appropriate that is ;-)

--jason


On Wednesday, August 13, 2003, at 11:12  PM, James Strachan wrote:

>
> On Wednesday, August 13, 2003, at 04:59  pm, Chris Opacki wrote:
>
>> I would like to start implementing the DDBeans from
>> JSR-88. I will start a new thread for JSR-88.
>
> Cool. Before you start - I'm not sure if we can reuse Sun's 
> distribution of the API due to their licence restrictions (we should 
> check).
>
> Someone might have to do what Dain did for the EJB stuff and hand type 
> in all the java code to create the JSR 88 APIs - unfortunately. Once 
> its compiled we could do a quick check that the class files seem 
> similar to catch any typeos.
>
> James
> -------
> http://radio.weblogs.com/0112098/
>

getting the J2EE Deployment API code (Re: J2EE DeploymentManager ( was J2EE deployment verifier)

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

On Wednesday, August 13, 2003, at 05:34  pm, Chris Opacki wrote:

> The deployment api is downloaded without source. I'm
> sure the source is somewhere.

I'm sure it is :)

However can we legally use it in our project? This isn't the case for 
the EJB API. We need to check if we can reuse & redistribute Sun's 
binaries or source  - typically we can't.

So our best approach today is to retype them all in from the javadoc / 
specification so that we can include the source in our CVS repository 
and build them ourselves or redistribute our binaries etc. Hopefully 
Sun will change this someday soon but right now using the Sun binaries 
would force people to have to manually download all the J2EE APIs and 
put them in the right place in their Maven repository which is a PITA.

There was talk of Maven having a special 'Sun' plugin to ask you if you 
abode by Sun's licencing terms before it auto-downloaded the jar. Dunno 
if thats ready yet.


>
> --- James Strachan <ja...@yahoo.co.uk> wrote:
>>
>> On Wednesday, August 13, 2003, at 04:59  pm, Chris
>> Opacki wrote:
>>
>>> I would like to start implementing the DDBeans
>> from
>>> JSR-88. I will start a new thread for JSR-88.
>>
>> Cool. Before you start - I'm not sure if we can
>> reuse Sun's
>> distribution of the API due to their licence
>> restrictions (we should
>> check).
>>
>> Someone might have to do what Dain did for the EJB
>> stuff and hand type
>> in all the java code to create the JSR 88 APIs -
>> unfortunately. Once
>> its compiled we could do a quick check that the
>> class files seem
>> similar to catch any typeos.
>>
>> James
>> -------
>> http://radio.weblogs.com/0112098/
>>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
>

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

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

[Chris Opacki <ch...@yahoo.com>]

The deployment api is downloaded without source. I'm
sure the source is somewhere.

--- James Strachan <ja...@yahoo.co.uk> wrote:
> 
> On Wednesday, August 13, 2003, at 04:59  pm, Chris
> Opacki wrote:
> 
> > I would like to start implementing the DDBeans
> from
> > JSR-88. I will start a new thread for JSR-88.
> 
> Cool. Before you start - I'm not sure if we can
> reuse Sun's 
> distribution of the API due to their licence
> restrictions (we should 
> check).
> 
> Someone might have to do what Dain did for the EJB
> stuff and hand type 
> in all the java code to create the JSR 88 APIs -
> unfortunately. Once 
> its compiled we could do a quick check that the
> class files seem 
> similar to catch any typeos.
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

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

On Wednesday, August 13, 2003, at 04:59  pm, Chris Opacki wrote:

> I would like to start implementing the DDBeans from
> JSR-88. I will start a new thread for JSR-88.

Cool. Before you start - I'm not sure if we can reuse Sun's 
distribution of the API due to their licence restrictions (we should 
check).

Someone might have to do what Dain did for the EJB stuff and hand type 
in all the java code to create the JSR 88 APIs - unfortunately. Once 
its compiled we could do a quick check that the class files seem 
similar to catch any typeos.

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

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Chris Opacki <ch...@yahoo.com>]

I would like to start implementing the DDBeans from
JSR-88. I will start a new thread for JSR-88.



--- Srihari S <sr...@blr.pin.philips.com> wrote:
> cool...so what are we waiting for!!!!
> lets get started with the requirements/design of the
> verifier..
> any ideas on the way of working for these phases..
> 
> -----Original Message-----
> From: Jonathan Duty [mailto:jduty@jonandkerry.com]
> Sent: Wednesday, August 13, 2003 8:14 PM
> To: geronimo-dev@incubator.apache.org;
> weston_p@yahoo.com
> Subject: RE: J2EE DeploymentManager ( was J2EE
> deployment verifier)
> 
> 
> I agree.  The verification engine really doesn't
> need to implement the
> deployment specs.  Later when we implement the
> DeploymentManager in
> front of it that's when we will have to worry about
> implementing the
> exact interfaces.  
> 
> ~Jonathan
> 
> 
> Jonathan Duty
> Software Developer - eWashtenaw
> 
> 
> -----Original Message-----
> From: Weston M. Price [mailto:weston_p@yahoo.com] 
> Sent: Wednesday, August 13, 2003 5:48 AM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: J2EE DeploymentManager ( was J2EE
> deployment verifier)
> 
> I agree with Srihari in that the Verification
> manager does not have to 
> implement the spec interfaces, however, the
> DeploymentManager does, this
> 
> would be where we would implment DDRoot, DDConfig
> etc.....in some ways
> the 
> DeploymentManager would just use the services of the
> VerificatinoEngine
> as 
> one step in the process of actual deployment. 
> 
> Is this in line with what you guys were thinking?
> 
> 
> On Wednesday 13 August 2003 01:52 pm, Jonathan Duty
> wrote:
> > When we implement this module, we could actually
> implement it to
> exactly
> > follow the API specs (JSR 88).  That means
> implementing the
> > DeploymentManager interface on top of it and such.
>  That way any
> > application (ant, Eclipse, etc) that is equipped
> to deploy packages
> > could interface with it.  It would just fall short
> of actually
> > communicating with MBeans and deploying the
> package.
> >
> > When this module is used internally (within the
> REAL deployment
> manager)
> > it could just bypass or override the
> Verification's Deployment
> manager.
> >
> > ~Jonathan
> >
> >
> > -----Original Message-----
> > From: Srihari S
> [mailto:sriharis@blr.pin.philips.com]
> > Sent: Wednesday, August 13, 2003 9:43 AM
> > To: geronimo-dev@incubator.apache.org;
> weston_p@yahoo.com
> > Subject: RE: J2EE DeploymentManager ( was J2EE
> deployment verifier)
> >
> > Hi All
> >   When I was going thru the deployment api spec I
> thought it would be
> > good
> > to bring up some points:
> >
> > From a preliminary reading of the spec i saw there
> are no apis
> > explicitly
> > designed to do the verification
> > of a deployable unit. From this I infer that the
> verifier can be an
> > internal
> > module which could be used
> > by the deploy tool. So we could go full steam on
> its design and
> > implementation. In this regard I am trying to
> > jot the list of checks that our verifier will have
> to do (This is
> > mentioned
> > in the j2ee specs).
> > So in a way it will be equivalent to arriving at
> requirement specs for
> > the
> > verifier.
> > With the list of dos and donts that a verifier has
> to achieve we could
> > go
> > abt with design.Also the design of
> > ant hooks can be taken care.Can we??
> >
> > Next is something abt the big picture. Certainly
> the verifer is a
> small
> > part
> > of the deployment process.
> > But to achieve compliance we will have to
> implement the deployment
> spec
> > as a
> > whole. Has anyone given
> > thought to this issue?
> >
> > regards
> > Hari
> >
> >
> >
> > -----Original Message-----
> > From: Weston M. Price [mailto:weston_p@yahoo.com]
> > Sent: Wednesday, August 13, 2003 1:33 AM
> > To: geronimo-dev@incubator.apache.org
> > Subject: Re: J2EE DeploymentManager ( was J2EE
> deployment verifier)
> >
> >
> > No, I think splitting them up would be good....
> >
> > Weston
> >
> > On Tuesday 12 August 2003 11:41 pm, Jonathan Duty
> wrote:
> > > I'm creating a maven module to add to the cvs
> project.
> > > Do we want to plan on the DeploymentManager,
> VerificationEngine, and
> > > DeploymentEngine being in one module?
> > >
> > > What do you all think?
> > >
> > > ~Jonathan
> > >
> > > Weston M. Price wrote:
> > > >Just thought I should start a new thread....
> > > >
> > > >My KMail was getting dominated!
> > > >
> > > >Weston
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Srihari S <sr...@blr.pin.philips.com>]

cool...so what are we waiting for!!!!
lets get started with the requirements/design of the verifier..
any ideas on the way of working for these phases..

-----Original Message-----
From: Jonathan Duty [mailto:jduty@jonandkerry.com]
Sent: Wednesday, August 13, 2003 8:14 PM
To: geronimo-dev@incubator.apache.org; weston_p@yahoo.com
Subject: RE: J2EE DeploymentManager ( was J2EE deployment verifier)


I agree.  The verification engine really doesn't need to implement the
deployment specs.  Later when we implement the DeploymentManager in
front of it that's when we will have to worry about implementing the
exact interfaces.  

~Jonathan


Jonathan Duty
Software Developer - eWashtenaw


-----Original Message-----
From: Weston M. Price [mailto:weston_p@yahoo.com] 
Sent: Wednesday, August 13, 2003 5:48 AM
To: geronimo-dev@incubator.apache.org
Subject: Re: J2EE DeploymentManager ( was J2EE deployment verifier)

I agree with Srihari in that the Verification manager does not have to 
implement the spec interfaces, however, the DeploymentManager does, this

would be where we would implment DDRoot, DDConfig etc.....in some ways
the 
DeploymentManager would just use the services of the VerificatinoEngine
as 
one step in the process of actual deployment. 

Is this in line with what you guys were thinking?


On Wednesday 13 August 2003 01:52 pm, Jonathan Duty wrote:
> When we implement this module, we could actually implement it to
exactly
> follow the API specs (JSR 88).  That means implementing the
> DeploymentManager interface on top of it and such.  That way any
> application (ant, Eclipse, etc) that is equipped to deploy packages
> could interface with it.  It would just fall short of actually
> communicating with MBeans and deploying the package.
>
> When this module is used internally (within the REAL deployment
manager)
> it could just bypass or override the Verification's Deployment
manager.
>
> ~Jonathan
>
>
> -----Original Message-----
> From: Srihari S [mailto:sriharis@blr.pin.philips.com]
> Sent: Wednesday, August 13, 2003 9:43 AM
> To: geronimo-dev@incubator.apache.org; weston_p@yahoo.com
> Subject: RE: J2EE DeploymentManager ( was J2EE deployment verifier)
>
> Hi All
>   When I was going thru the deployment api spec I thought it would be
> good
> to bring up some points:
>
> From a preliminary reading of the spec i saw there are no apis
> explicitly
> designed to do the verification
> of a deployable unit. From this I infer that the verifier can be an
> internal
> module which could be used
> by the deploy tool. So we could go full steam on its design and
> implementation. In this regard I am trying to
> jot the list of checks that our verifier will have to do (This is
> mentioned
> in the j2ee specs).
> So in a way it will be equivalent to arriving at requirement specs for
> the
> verifier.
> With the list of dos and donts that a verifier has to achieve we could
> go
> abt with design.Also the design of
> ant hooks can be taken care.Can we??
>
> Next is something abt the big picture. Certainly the verifer is a
small
> part
> of the deployment process.
> But to achieve compliance we will have to implement the deployment
spec
> as a
> whole. Has anyone given
> thought to this issue?
>
> regards
> Hari
>
>
>
> -----Original Message-----
> From: Weston M. Price [mailto:weston_p@yahoo.com]
> Sent: Wednesday, August 13, 2003 1:33 AM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: J2EE DeploymentManager ( was J2EE deployment verifier)
>
>
> No, I think splitting them up would be good....
>
> Weston
>
> On Tuesday 12 August 2003 11:41 pm, Jonathan Duty wrote:
> > I'm creating a maven module to add to the cvs project.
> > Do we want to plan on the DeploymentManager, VerificationEngine, and
> > DeploymentEngine being in one module?
> >
> > What do you all think?
> >
> > ~Jonathan
> >
> > Weston M. Price wrote:
> > >Just thought I should start a new thread....
> > >
> > >My KMail was getting dominated!
> > >
> > >Weston

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Jonathan Duty <jd...@jonandkerry.com>]

I agree.  The verification engine really doesn't need to implement the
deployment specs.  Later when we implement the DeploymentManager in
front of it that's when we will have to worry about implementing the
exact interfaces.  

~Jonathan


Jonathan Duty
Software Developer - eWashtenaw


-----Original Message-----
From: Weston M. Price [mailto:weston_p@yahoo.com] 
Sent: Wednesday, August 13, 2003 5:48 AM
To: geronimo-dev@incubator.apache.org
Subject: Re: J2EE DeploymentManager ( was J2EE deployment verifier)

I agree with Srihari in that the Verification manager does not have to 
implement the spec interfaces, however, the DeploymentManager does, this

would be where we would implment DDRoot, DDConfig etc.....in some ways
the 
DeploymentManager would just use the services of the VerificatinoEngine
as 
one step in the process of actual deployment. 

Is this in line with what you guys were thinking?


On Wednesday 13 August 2003 01:52 pm, Jonathan Duty wrote:
> When we implement this module, we could actually implement it to
exactly
> follow the API specs (JSR 88).  That means implementing the
> DeploymentManager interface on top of it and such.  That way any
> application (ant, Eclipse, etc) that is equipped to deploy packages
> could interface with it.  It would just fall short of actually
> communicating with MBeans and deploying the package.
>
> When this module is used internally (within the REAL deployment
manager)
> it could just bypass or override the Verification's Deployment
manager.
>
> ~Jonathan
>
>
> -----Original Message-----
> From: Srihari S [mailto:sriharis@blr.pin.philips.com]
> Sent: Wednesday, August 13, 2003 9:43 AM
> To: geronimo-dev@incubator.apache.org; weston_p@yahoo.com
> Subject: RE: J2EE DeploymentManager ( was J2EE deployment verifier)
>
> Hi All
>   When I was going thru the deployment api spec I thought it would be
> good
> to bring up some points:
>
> From a preliminary reading of the spec i saw there are no apis
> explicitly
> designed to do the verification
> of a deployable unit. From this I infer that the verifier can be an
> internal
> module which could be used
> by the deploy tool. So we could go full steam on its design and
> implementation. In this regard I am trying to
> jot the list of checks that our verifier will have to do (This is
> mentioned
> in the j2ee specs).
> So in a way it will be equivalent to arriving at requirement specs for
> the
> verifier.
> With the list of dos and donts that a verifier has to achieve we could
> go
> abt with design.Also the design of
> ant hooks can be taken care.Can we??
>
> Next is something abt the big picture. Certainly the verifer is a
small
> part
> of the deployment process.
> But to achieve compliance we will have to implement the deployment
spec
> as a
> whole. Has anyone given
> thought to this issue?
>
> regards
> Hari
>
>
>
> -----Original Message-----
> From: Weston M. Price [mailto:weston_p@yahoo.com]
> Sent: Wednesday, August 13, 2003 1:33 AM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: J2EE DeploymentManager ( was J2EE deployment verifier)
>
>
> No, I think splitting them up would be good....
>
> Weston
>
> On Tuesday 12 August 2003 11:41 pm, Jonathan Duty wrote:
> > I'm creating a maven module to add to the cvs project.
> > Do we want to plan on the DeploymentManager, VerificationEngine, and
> > DeploymentEngine being in one module?
> >
> > What do you all think?
> >
> > ~Jonathan
> >
> > Weston M. Price wrote:
> > >Just thought I should start a new thread....
> > >
> > >My KMail was getting dominated!
> > >
> > >Weston

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

["Weston M. Price" <we...@yahoo.com>]

I agree with Srihari in that the Verification manager does not have to 
implement the spec interfaces, however, the DeploymentManager does, this 
would be where we would implment DDRoot, DDConfig etc.....in some ways the 
DeploymentManager would just use the services of the VerificatinoEngine as 
one step in the process of actual deployment. 

Is this in line with what you guys were thinking?


On Wednesday 13 August 2003 01:52 pm, Jonathan Duty wrote:
> When we implement this module, we could actually implement it to exactly
> follow the API specs (JSR 88).  That means implementing the
> DeploymentManager interface on top of it and such.  That way any
> application (ant, Eclipse, etc) that is equipped to deploy packages
> could interface with it.  It would just fall short of actually
> communicating with MBeans and deploying the package.
>
> When this module is used internally (within the REAL deployment manager)
> it could just bypass or override the Verification's Deployment manager.
>
> ~Jonathan
>
>
> -----Original Message-----
> From: Srihari S [mailto:sriharis@blr.pin.philips.com]
> Sent: Wednesday, August 13, 2003 9:43 AM
> To: geronimo-dev@incubator.apache.org; weston_p@yahoo.com
> Subject: RE: J2EE DeploymentManager ( was J2EE deployment verifier)
>
> Hi All
>   When I was going thru the deployment api spec I thought it would be
> good
> to bring up some points:
>
> From a preliminary reading of the spec i saw there are no apis
> explicitly
> designed to do the verification
> of a deployable unit. From this I infer that the verifier can be an
> internal
> module which could be used
> by the deploy tool. So we could go full steam on its design and
> implementation. In this regard I am trying to
> jot the list of checks that our verifier will have to do (This is
> mentioned
> in the j2ee specs).
> So in a way it will be equivalent to arriving at requirement specs for
> the
> verifier.
> With the list of dos and donts that a verifier has to achieve we could
> go
> abt with design.Also the design of
> ant hooks can be taken care.Can we??
>
> Next is something abt the big picture. Certainly the verifer is a small
> part
> of the deployment process.
> But to achieve compliance we will have to implement the deployment spec
> as a
> whole. Has anyone given
> thought to this issue?
>
> regards
> Hari
>
>
>
> -----Original Message-----
> From: Weston M. Price [mailto:weston_p@yahoo.com]
> Sent: Wednesday, August 13, 2003 1:33 AM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: J2EE DeploymentManager ( was J2EE deployment verifier)
>
>
> No, I think splitting them up would be good....
>
> Weston
>
> On Tuesday 12 August 2003 11:41 pm, Jonathan Duty wrote:
> > I'm creating a maven module to add to the cvs project.
> > Do we want to plan on the DeploymentManager, VerificationEngine, and
> > DeploymentEngine being in one module?
> >
> > What do you all think?
> >
> > ~Jonathan
> >
> > Weston M. Price wrote:
> > >Just thought I should start a new thread....
> > >
> > >My KMail was getting dominated!
> > >
> > >Weston

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Srihari S <sr...@blr.pin.philips.com>]

jonathan...i am unclear on a couple of points:

1. "When we implement this module, we could actually implement it to exactly
follow the API specs (JSR 88)"
I hope "this module" means the verification module.

2. "That means implementing the DeploymentManager interface on top of it and
such"
So if i am right you want an independent Verification module first but at
the same time we create a **pseudo??**
DeploymentManager implementation which will enable ant etc to hook onto it
immediately. Yes such a thing would ceratinly
fall short of communicating with the MBeans.
Nevertheless the advantage would be that we are on the track implementing
the deployment spec from the word go
and this small wonder of ours would have successfully made itself
indispensable to the sucessful impl of the deployment spec.

Which i guess is a win-win situation!!

I hope i understand u correctly


-----Original Message-----
From: Jonathan Duty [mailto:jduty@jonandkerry.com]
Sent: Wednesday, August 13, 2003 7:22 PM
To: geronimo-dev@incubator.apache.org
Subject: RE: J2EE DeploymentManager ( was J2EE deployment verifier)


When we implement this module, we could actually implement it to exactly
follow the API specs (JSR 88).  That means implementing the
DeploymentManager interface on top of it and such.  That way any
application (ant, Eclipse, etc) that is equipped to deploy packages
could interface with it.  It would just fall short of actually
communicating with MBeans and deploying the package.

When this module is used internally (within the REAL deployment manager)
it could just bypass or override the Verification's Deployment manager.

~Jonathan


-----Original Message-----
From: Srihari S [mailto:sriharis@blr.pin.philips.com]
Sent: Wednesday, August 13, 2003 9:43 AM
To: geronimo-dev@incubator.apache.org; weston_p@yahoo.com
Subject: RE: J2EE DeploymentManager ( was J2EE deployment verifier)

Hi All
  When I was going thru the deployment api spec I thought it would be
good
to bring up some points:

>>From a preliminary reading of the spec i saw there are no apis
explicitly
designed to do the verification
of a deployable unit. From this I infer that the verifier can be an
internal
module which could be used
by the deploy tool. So we could go full steam on its design and
implementation. In this regard I am trying to
jot the list of checks that our verifier will have to do (This is
mentioned
in the j2ee specs).
So in a way it will be equivalent to arriving at requirement specs for
the
verifier.
With the list of dos and donts that a verifier has to achieve we could
go
abt with design.Also the design of
ant hooks can be taken care.Can we??

Next is something abt the big picture. Certainly the verifer is a small
part
of the deployment process.
But to achieve compliance we will have to implement the deployment spec
as a
whole. Has anyone given
thought to this issue?

regards
Hari



-----Original Message-----
From: Weston M. Price [mailto:weston_p@yahoo.com]
Sent: Wednesday, August 13, 2003 1:33 AM
To: geronimo-dev@incubator.apache.org
Subject: Re: J2EE DeploymentManager ( was J2EE deployment verifier)


No, I think splitting them up would be good....

Weston

On Tuesday 12 August 2003 11:41 pm, Jonathan Duty wrote:
> I'm creating a maven module to add to the cvs project.
> Do we want to plan on the DeploymentManager, VerificationEngine, and
> DeploymentEngine being in one module?
>
> What do you all think?
>
> ~Jonathan
>
> Weston M. Price wrote:
> >Just thought I should start a new thread....
> >
> >My KMail was getting dominated!
> >
> >Weston

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Jonathan Duty <jd...@jonandkerry.com>]

When we implement this module, we could actually implement it to exactly
follow the API specs (JSR 88).  That means implementing the
DeploymentManager interface on top of it and such.  That way any
application (ant, Eclipse, etc) that is equipped to deploy packages
could interface with it.  It would just fall short of actually
communicating with MBeans and deploying the package.

When this module is used internally (within the REAL deployment manager)
it could just bypass or override the Verification's Deployment manager.

~Jonathan 


-----Original Message-----
From: Srihari S [mailto:sriharis@blr.pin.philips.com] 
Sent: Wednesday, August 13, 2003 9:43 AM
To: geronimo-dev@incubator.apache.org; weston_p@yahoo.com
Subject: RE: J2EE DeploymentManager ( was J2EE deployment verifier)

Hi All
  When I was going thru the deployment api spec I thought it would be
good
to bring up some points:

>>From a preliminary reading of the spec i saw there are no apis
explicitly
designed to do the verification
of a deployable unit. From this I infer that the verifier can be an
internal
module which could be used
by the deploy tool. So we could go full steam on its design and
implementation. In this regard I am trying to
jot the list of checks that our verifier will have to do (This is
mentioned
in the j2ee specs).
So in a way it will be equivalent to arriving at requirement specs for
the
verifier.
With the list of dos and donts that a verifier has to achieve we could
go
abt with design.Also the design of
ant hooks can be taken care.Can we??

Next is something abt the big picture. Certainly the verifer is a small
part
of the deployment process.
But to achieve compliance we will have to implement the deployment spec
as a
whole. Has anyone given
thought to this issue?

regards
Hari



-----Original Message-----
From: Weston M. Price [mailto:weston_p@yahoo.com]
Sent: Wednesday, August 13, 2003 1:33 AM
To: geronimo-dev@incubator.apache.org
Subject: Re: J2EE DeploymentManager ( was J2EE deployment verifier)


No, I think splitting them up would be good....

Weston

On Tuesday 12 August 2003 11:41 pm, Jonathan Duty wrote:
> I'm creating a maven module to add to the cvs project.
> Do we want to plan on the DeploymentManager, VerificationEngine, and
> DeploymentEngine being in one module?
>
> What do you all think?
>
> ~Jonathan
>
> Weston M. Price wrote:
> >Just thought I should start a new thread....
> >
> >My KMail was getting dominated!
> >
> >Weston

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Srihari S <sr...@blr.pin.philips.com>]

Hi All
  When I was going thru the deployment api spec I thought it would be good
to bring up some points:

>From a preliminary reading of the spec i saw there are no apis explicitly
designed to do the verification
of a deployable unit. From this I infer that the verifier can be an internal
module which could be used
by the deploy tool. So we could go full steam on its design and
implementation. In this regard I am trying to
jot the list of checks that our verifier will have to do (This is mentioned
in the j2ee specs).
So in a way it will be equivalent to arriving at requirement specs for the
verifier.
With the list of dos and donts that a verifier has to achieve we could go
abt with design.Also the design of
ant hooks can be taken care.Can we??

Next is something abt the big picture. Certainly the verifer is a small part
of the deployment process.
But to achieve compliance we will have to implement the deployment spec as a
whole. Has anyone given
thought to this issue?

regards
Hari



-----Original Message-----
From: Weston M. Price [mailto:weston_p@yahoo.com]
Sent: Wednesday, August 13, 2003 1:33 AM
To: geronimo-dev@incubator.apache.org
Subject: Re: J2EE DeploymentManager ( was J2EE deployment verifier)


No, I think splitting them up would be good....

Weston

On Tuesday 12 August 2003 11:41 pm, Jonathan Duty wrote:
> I'm creating a maven module to add to the cvs project.
> Do we want to plan on the DeploymentManager, VerificationEngine, and
> DeploymentEngine being in one module?
>
> What do you all think?
>
> ~Jonathan
>
> Weston M. Price wrote:
> >Just thought I should start a new thread....
> >
> >My KMail was getting dominated!
> >
> >Weston

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

["Weston M. Price" <we...@yahoo.com>]

No, I think splitting them up would be good....

Weston

On Tuesday 12 August 2003 11:41 pm, Jonathan Duty wrote:
> I'm creating a maven module to add to the cvs project.
> Do we want to plan on the DeploymentManager, VerificationEngine, and
> DeploymentEngine being in one module?
>
> What do you all think?
>
> ~Jonathan
>
> Weston M. Price wrote:
> >Just thought I should start a new thread....
> >
> >My KMail was getting dominated!
> >
> >Weston

RE: J2EE DeploymentManager ( was J2EE deployment verifier)

[Srihari S <sr...@blr.pin.philips.com>]

i agree to this...having the verification engine isolated in a different
module is better


-----Original Message-----
From: James Strachan [mailto:james_strachan@yahoo.co.uk]
Sent: Wednesday, August 13, 2003 5:04 PM
To: geronimo-dev@incubator.apache.org
Subject: Re: J2EE DeploymentManager ( was J2EE deployment verifier)



On Wednesday, August 13, 2003, at 12:41  am, Jonathan Duty wrote:
> I'm creating a maven module to add to the cvs project.
> Do we want to plan on the DeploymentManager, VerificationEngine, and
> DeploymentEngine being in one module?

I'd maybe keep deployment separate from verification. Though if in
doubt, I'd say reuse the same module - we can always refactor later.
I'd rather we start with too few modules initially than too many.

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

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

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

On Wednesday, August 13, 2003, at 12:41  am, Jonathan Duty wrote:
> I'm creating a maven module to add to the cvs project.
> Do we want to plan on the DeploymentManager, VerificationEngine, and 
> DeploymentEngine being in one module?

I'd maybe keep deployment separate from verification. Though if in 
doubt, I'd say reuse the same module - we can always refactor later. 
I'd rather we start with too few modules initially than too many.

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

Re: J2EE DeploymentManager ( was J2EE deployment verifier)

[Jonathan Duty <jd...@jonandkerry.com>]

I'm creating a maven module to add to the cvs project.
Do we want to plan on the DeploymentManager, VerificationEngine, and 
DeploymentEngine being in one module?

What do you all think?

~Jonathan


Weston M. Price wrote:

>Just thought I should start a new thread....
>
>My KMail was getting dominated!
>
>Weston
>  
>

RE: J2EE DeploymentManager

[Chris Opacki <ch...@yahoo.com>]

It does not, but there are some interfaces to be
implemented that i feel would be shared across tools.

--- Srihari S <sr...@blr.pin.philips.com> wrote:
> sure..will follow on this thread...i was getting
> bored without any of u
> guys..
> coming to the point...i am currently going thru the
> deployment spec in
> detail....it looks exhaustive
> and in the way of working that u have suggested i
> would love to be part of
> phase 1...and graduate from there:)
> 
> from ur initial understanding of the spec can u
> elaborate whether the spec
> explicitly defines any apis which comes close to the
> deployment verifier? Or will it just be an internal
> module...this
> understanding is very necessary before we start on a
> design
> 
> 
>   -----Original Message-----
>   From: Jonathan Duty [mailto:jduty@jonandkerry.com]
>   Sent: Tuesday, August 12, 2003 3:38 AM
>   To: geronimo-dev@incubator.apache.org
>   Subject: Re: J2EE DeploymentManager
> 
> 
>   Count me in on part I for now.  As things get
> moving I may move between I
> and III if we decide to use common objects between
> the two down the road.
> Should we consider these projects running in
> parallel or as different linear
> phases?
> 
>   Phases?
>   1) research and development of Verification Module
> 
>   2) development of Deployment module
> 
>   3) Development of Deployment Manager (tie
> everything together)
> 
>   4) development of Wizard (pretty gui stuff usually
> comes last)
> 
> 
>   Also, should we get a Wiki going?
> 
> 
>   ~Jonathan
> 
>   Labeeb Syed wrote:
> 
> So as per continuation:
> 
> Verifier -> Deploy Tool -> Deployer.
> J2SDK SE: v1.4.2
> J2SDK EE: v1.4
> 
> Next Step:
> We need some documentation on:
> I.) Verifier
> II.) Deploy Tool Wizard
> III.) Deployer
> 
> The team for this (so far I believe it is):
> 
> Weston P. (Part I)
> Chris O.  (Part III)
> Jonathon D. (Part ?)
> Srihari S. (Part I)
> Labeeb S. (Part III)
> 
> Please forgive me if I left someone out or made a
> mistake in which part I thought you wanted to work
> on.
> I am also assuming the team which is working on the
> part is also responsible for its documentation.
> 
> 
> 
> 
> --- "Weston M. Price" <we...@yahoo.com> wrote:
>   Just thought I should start a new thread....
> 
> My KMail was getting dominated!
> 
> Weston
> 
> 
> __________________________________
> 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: J2EE DeploymentManager

[Srihari S <sr...@blr.pin.philips.com>]

sure..will follow on this thread...i was getting bored without any of u
guys..
coming to the point...i am currently going thru the deployment spec in
detail....it looks exhaustive
and in the way of working that u have suggested i would love to be part of
phase 1...and graduate from there:)

from ur initial understanding of the spec can u elaborate whether the spec
explicitly defines any apis which comes close to the
deployment verifier? Or will it just be an internal module...this
understanding is very necessary before we start on a design


  -----Original Message-----
  From: Jonathan Duty [mailto:jduty@jonandkerry.com]
  Sent: Tuesday, August 12, 2003 3:38 AM
  To: geronimo-dev@incubator.apache.org
  Subject: Re: J2EE DeploymentManager


  Count me in on part I for now.  As things get moving I may move between I
and III if we decide to use common objects between the two down the road.
Should we consider these projects running in parallel or as different linear
phases?

  Phases?
  1) research and development of Verification Module

  2) development of Deployment module

  3) Development of Deployment Manager (tie everything together)

  4) development of Wizard (pretty gui stuff usually comes last)


  Also, should we get a Wiki going?


  ~Jonathan

  Labeeb Syed wrote:

So as per continuation:

Verifier -> Deploy Tool -> Deployer.
J2SDK SE: v1.4.2
J2SDK EE: v1.4

Next Step:
We need some documentation on:
I.) Verifier
II.) Deploy Tool Wizard
III.) Deployer

The team for this (so far I believe it is):

Weston P. (Part I)
Chris O.  (Part III)
Jonathon D. (Part ?)
Srihari S. (Part I)
Labeeb S. (Part III)

Please forgive me if I left someone out or made a
mistake in which part I thought you wanted to work on.
I am also assuming the team which is working on the
part is also responsible for its documentation.




--- "Weston M. Price" <we...@yahoo.com> wrote:
  Just thought I should start a new thread....

My KMail was getting dominated!

Weston


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: J2EE DeploymentManager

[Jonathan Duty <jd...@jonandkerry.com>]

Count me in on part I for now.  As things get moving I may move between 
I and III if we decide to use common objects between the two down the 
road.  Should we consider these projects running in parallel or as 
different linear phases?

Phases?
1) research and development of Verification Module

2) development of Deployment module

3) Development of Deployment Manager (tie everything together)

4) development of Wizard (pretty gui stuff usually comes last)


Also, should we get a Wiki going?


~Jonathan

Labeeb Syed wrote:

>So as per continuation:
>
>Verifier -> Deploy Tool -> Deployer.
>J2SDK SE: v1.4.2
>J2SDK EE: v1.4
>
>Next Step:
>We need some documentation on:
>I.) Verifier
>II.) Deploy Tool Wizard
>III.) Deployer
>
>The team for this (so far I believe it is):
>
>Weston P. (Part I)
>Chris O.  (Part III)
>Jonathon D. (Part ?)
>Srihari S. (Part I)
>Labeeb S. (Part III)
>
>Please forgive me if I left someone out or made a
>mistake in which part I thought you wanted to work on.
>I am also assuming the team which is working on the
>part is also responsible for its documentation.
>
>
>
>
>--- "Weston M. Price" <we...@yahoo.com> wrote:
>  
>
>>Just thought I should start a new thread....
>>
>>My KMail was getting dominated!
>>
>>Weston
>>    
>>
>
>
>__________________________________
>Do you Yahoo!?
>Yahoo! SiteBuilder - Free, easy-to-use web site design software
>http://sitebuilder.yahoo.com
>  
>

Re: J2EE DeploymentManager

["Weston M. Price" <we...@yahoo.com>]

I have started a page on Wiki....

The URL is 

http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/Deployment


On Monday 11 August 2003 09:58 pm, Labeeb Syed wrote:
> So as per continuation:
>
> Verifier -> Deploy Tool -> Deployer.
> J2SDK SE: v1.4.2
> J2SDK EE: v1.4
>
> Next Step:
> We need some documentation on:
> I.) Verifier
> II.) Deploy Tool Wizard
> III.) Deployer
>
> The team for this (so far I believe it is):
>
> Weston P. (Part I)
> Chris O.  (Part III)
> Jonathon D. (Part ?)
> Srihari S. (Part I)
> Labeeb S. (Part III)
>
> Please forgive me if I left someone out or made a
> mistake in which part I thought you wanted to work on.
> I am also assuming the team which is working on the
> part is also responsible for its documentation.
>
> --- "Weston M. Price" <we...@yahoo.com> wrote:
> > Just thought I should start a new thread....
> >
> > My KMail was getting dominated!
> >
> > Weston
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com

Re: J2EE DeploymentManager

[Labeeb Syed <an...@yahoo.com>]

So as per continuation:

Verifier -> Deploy Tool -> Deployer.
J2SDK SE: v1.4.2
J2SDK EE: v1.4

Next Step:
We need some documentation on:
I.) Verifier
II.) Deploy Tool Wizard
III.) Deployer

The team for this (so far I believe it is):

Weston P. (Part I)
Chris O.  (Part III)
Jonathon D. (Part ?)
Srihari S. (Part I)
Labeeb S. (Part III)

Please forgive me if I left someone out or made a
mistake in which part I thought you wanted to work on.
I am also assuming the team which is working on the
part is also responsible for its documentation.




--- "Weston M. Price" <we...@yahoo.com> wrote:
> Just thought I should start a new thread....
> 
> My KMail was getting dominated!
> 
> Weston


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com