I was thinking. After developing this module, we will all be very
versed in the J2EE Deployment Specs. Our team could have 3 phases:
1) research and development of Verification Module
2) development of Deployment module
3) Development of Deployment Manager
Any thoughts?
~Jonathan
[EMAIL PROTECTED] wrote:
I agree with Weston on the modules separation:
I`m realy focused on module three. So I would like to work more closely on
that. Wish to help on others modules too, but I`m already working on the
verifier... I will have something more tangeable really soon, assuming that the
architecture that I described earlier is ok. Which is best to show the
interfaces: commented source code or a gif with the class diagram, or both?
I`m not familiar with apache`s development process, but I`m assuming that I
will submit the interfaces for approval, do the changes that shows necessary
and then proceed to implement something to prove that works. Is that correct?
Thanks
Denes
Citando "Weston M. Price" <[EMAIL PROTECTED]>:
Well, is someone going to assume a "lead" position on this? I am not sure how
the structure is going to work. Basically I am thinking in these terms:
Module One: common
Source that is applicable to both the deployment module and the
verification
service (JVXS) Included here would be all appropriate interfaces to be
compliant with J2EE specifications. The DeploymentManager would be included
in this module as well.
Module Two:
Deployment
Module Three:
Verification
I think we can start another module under CVS.....I don't have committing
rights on Geronimo....
I am new to Maven so I am kind of fuddling my way around all this stuff. If
we
can't check into Geronimo, does someone have space for code, docs, scripts,
models etc? I do, but my pipes in are somewhat slow (sigh...satellite no
less....never live in the woods dudes)....
Weston
On Monday 11 August 2003 06:43 pm, Jonathan Duty wrote:
Great. Lets get a maven project stub generated and get started. Any
ideas for planning?
~Jonathan
Weston M. Price wrote:
Right on dude....
You nailed it....especially in terms of the relationship between the
controller and the two...well at this point we will call them
services....The "manager" cooridinates the interaction between the
two...I am of the personal mind that the verification service should
have
no knowledge (at least in terms of hard references, we will share code)
of the deployment service. This would allow the modules to be
distinct....this would naturally dictate a common set of classes shared
between us which could possibly be it's own module, perhaps the objects
implementing the javax interfaces.
Weston
On Monday 11 August 2003 04:48 pm, Jonathan Duty wrote:
Since I'm weird and think better in pictures, I tried to draw what you
were describing. Do I have the correct Idea of your vision?
The image is attached. Hope this helps others out also.
~Jonathan
Weston M. Price wrote:
I have thought of it in terms of a deployment manager (as Chris
alluded
to earlier this morning). The manager would be responsible for
coordinating the interaction between the verification engine and the
deployment engine....sort of a controller, that way the two can be
loosely coupled relying on an external agent to provide an higher
level
of service, in this case the complete deployment of a J2EE archive.
Weston
On Monday 11 August 2003 04:05 pm, Labeeb Syed wrote:
In this scenario, the verifier will have to interface
with the deployer. I would definitely like to
implement the SPI for the deployer.
Q: Should the deployer be responsible for ensuring
bean consistency, e.g., entity bean cmr mapping vs
databases and relational mappings, or any such other
technical issues (realms checking, etc.)?
Chris, if this is what we'd work on, I'd like to come
up with a list potential technical problems we could
encounter to ensure just integrity of the DD file.
Labeeb Syed
--- Chris Opacki <[EMAIL PROTECTED]> wrote:
That is exactly what i was thinking. This is the
object model that has been defined in the deployment
spec... under Tool Provider Interfaces. There are
also
some other classes, exceptions and interfaces that
both modules might use.
--- "Weston M. Price" <[EMAIL PROTECTED]> wrote:
But I do agree that the two teams must work
closely
together....Chris made an
excellent point in indetifying that there are
certain basic facilities that
we can use together....I think if we can agree on
a
common object model for
archive formats (EAR, WAR, SAR) then we could
probably develop our own
streams, attributes, behavior.....
Weston
On Monday 11 August 2003 03:18 pm, Chris Opacki
wrote:
Ditto on all of that! Quite honestly...the
deployer
shouldn't run...period...until the verifier has
run...its a good idea that the deployableobject
are
build from within a controller that sends them
to
the
verifier for verification and then to the
deployer.
Something along that lines at a high level. we
can
reuse both engines for CLI and the GUI.
--- Jonathan Duty <[EMAIL PROTECTED]> wrote:
+1 You've convinced me. That would be a bad
a$$
tool to have as a
developer.
Plus, the deployment team could use it if they
want
to verify the
archive schema before they start deploying it.
Count me in!
~Jonathan
Jonathan Duty
Software Developer - eWashtenaw
-----Original Message-----
From: Weston M. Price
[mailto:[EMAIL PROTECTED]]
Sent: Monday, August 11, 2003 6:41 AM
To: [EMAIL PROTECTED]
Subject: Re: J2EE deployment verifier
I agree completely. I think what we are
talking
about are two modules
that are
close cousins. The verification manager is
again,
the "front-line" of
defense
for the deployment manager. I would assume the
deployment manager would
deal
with critical errors such as
LinkageConstraints,
incorrect classfile
versions
etc. while the verfication manager will handle
actual semantic
fallibities in
the deployment descriptors based upon the
existing
specifications.
The reason I mentioned a seperate
verification
module was that I
would
developers (hell, I know I would) like an
engine
that given a deployment
platform could validate their archive before
ever
trying to drop it in
the
chute. This would save a lot of time largely
due
to
the fact that XML
descriptors are not typed and you don't know
if
they
are "correct" at
compile
time. I suppose the biggest win in all of this
in my
opion would be to
provide hooks for an ANT task that would
verify
the
archive during
compile
time.
Regards,
Weston
On Monday 11 August 2003 02:39 pm, Jonathan
Duty
wrote:
Why couldn't they be close friends. Could
this
verifier, even as a
separate module, be a subset of the deploy
module?
I mean we don't
want
to deploy something that the J2EE server
will
not
accept.
Maybe these 2 groups should work close
together.
~Jonathan
-----Original Message-----
From: Chris Opacki
[mailto:[EMAIL PROTECTED]]
Sent: Monday, August 11, 2003 10:23 AM
To: [EMAIL PROTECTED]
Subject: RE: J2EE deployment verifier
My bad...I was assuming the deploy tool and
the
verifier would be close friends.
;)
--- Srihari S <[EMAIL PROTECTED]>
wrote:
True
Our module is just going to check and
declare
whether or not a given unit of
deployment
is deployable on a j2ee server or not.
Nothing more..nothing less.
Building this unit will be our
mission..right
weston??
-----Original Message-----
From: Weston M. Price
[mailto:[EMAIL PROTECTED]]
Sent: Monday, August 11, 2003 3:05 PM
To: [EMAIL PROTECTED]
Subject: Re: J2EE deployment verifier
And even further, let's clarify the
verification
is
a completely different
animal than actual deployment. Am I
correct
on
this
one at least in terms of
the way we are thinking about this module?
Weston
=== message truncated ===
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
|
