geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weston M. Price" <westo...@yahoo.com>
Subject Re: J2EE deployment verifier
Date Mon, 11 Aug 2003 17:31:46 GMT
Sorry guys...I started a new thread I refered to it as 

J2EEDeploymentManager (was J2EE deployment verifier)

My KMail is getting thrashed on this thread...do you guys mind switching over?

Weston

On Monday 11 August 2003 09:32 pm, Labeeb Syed wrote:
> I just checked the past logs, I believe we are
> standardizing to J2EE v1.4 spec using JDK v1.4.2.
>
> --- Labeeb Syed <anhkheg@yahoo.com> wrote:
> > Ok, so lets get a final clearance on what we are
> > agreed upon.
> > As Weston mentioned:
> >
> > A.) Verifier will be like a client doing some
> > preliminary checks.
> > B.) Deploy tool will be like a controller
> > interfacing
> > between the verifier and deployer.
> > C.) Deployer will be an implementaion of SPI as per
> > the J2EE v1.0( or 1.1? on JDK v1.4.2?)
> >
> > I believe everyone had agreed upon JDK v1.4.2.
> >
> > - Labeeb
> >
> > --- Chris Opacki <chris_opacki@yahoo.com> wrote:
> > > i have the final 1.0 spec.
> > > haven't looked at the date. i found it in j2ee
> > > technologies... it has its own area there.
> > >
> > > --- Jonathan Duty <jduty@jonandkerry.com> wrote:
> > > > Agreed.  I think the first thing we all need to
> >
> > do
> >
> > > > (atleast those who
> > > > want to do this module) is read the sun
> >
> > deployment
> >
> > > > specs.  If we want to
> > > > create something that not only can be used for
> > > > Gerinomo, but for other
> > > > stuff we have to do it with a good understanding
> > >
> > > of
> > >
> > > > what the
> > > > specifications are.  Once you've read the specs
> > >
> > > make
> > >
> > > > sure you let others
> > > > know so they know who to go to for questions.
> > >
> > > That
> > >
> > > > will be my homework
> > > > reading tonight.
> > > >
> > > > Deployment Specs
> > > > http://jcp.org/en/jsr/detail?id=88
> > > >
> > > > Question: I noticed that the most recent docs
> >
> > are
> >
> > > > from July 2002.  Has
> > > > nothing change since then?
> > > >
> > > > ~Jonathan
> > > >
> > > > Weston M. Price wrote:
> > > > >I guess first and foremost,
> > > > >
> > > > >IMO
> > > > >
> > > > >Let's have fun with this module...man, we have
> > > >
> > > > banged around on this list all
> > > >
> > > > >day and I believe we have really worked out
> >
> > some
> >
> > > > excellent ideas. I know I
> > > >
> > > > >have gained a great deal by just being
> > > >
> > > > involved...but let's not forget, we
> > > >
> > > > >are supposed to enjoy doing this, this is
> >
> > Apache
> >
> > > > right? Verification and
> > > >
> > > > >deployment are two of the most un-sexy ideas in
> > > >
> > > > J2EE, in fact, next to Java
> > > >
> > > > >IO (prior to NIO) I can't think of anything
> >
> > more
> >
> > > > dull....well, save for maybe
> > > >
> > > > >the Boston RedSox..(sigh, ignore
> >
> > that)...However,
> >
> > > I
> > >
> > > > am pretty pumped about
> > > >
> > > > >this.....I get to develop code with smart
> > >
> > > engaging
> > >
> > > > personalities (some that
> > > >
> > > > >get up before noon) and just have a
> >
> > blast....so,
> >
> > > > let's just take it step by
> > > >
> > > > >step and see what comes up....I have already
> > >
> > > heard
> > >
> > > > about a million ideas that
> > > >
> > > > >are great....the basic module structure could
> >
> > use
> >
> > > > some comments...so let's
> > > >
> > > > >just role with it...
> > > > >
> > > > >
> > > > >Regards,
> > > > >
> > > > >Weston
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >On Monday 11 August 2003 07:33 pm,
> > > >
> > > > denes@ppgia.pucpr.br wrote:
> > > > >>Agreed. I`m not familiar with maven yet.
> > > >
> > > > Definitively needs help on that...
> > > >
> > > > >>About planning: I think that all of us agreed
> > >
> > > that
> > >
> > > > the deployment verifier
> > > >
> > > > >>will have to be a component: it will have to
> > > >
> > > > receive the ear file from
> > > >
> > > > >>somewhere and do all the tasks without any
> >
> > help
> >
> > > of
> > >
> > > > external entities. This
> > > >
> > > > >>way, it can be placed in the client GUI, in
> >
> > the
> >
> > > > server, we can create an
> > > >
> > > > >>ant task for it, and so on.
> > > > >>
> > > > >>Some thoughs about the verifier:
> > > > >>
> > > > >>1. It should have an interface for rules. This
> > > >
> > > > interface will allow each
> > > >
> > > > >>rule implemented in a distinct class (several
> > > >
> > > > rules can be implemented in
> > > >
> > > > >>the same class either). Not sure about
> > >
> > > performance
> > >
> > > > issues yet, but IMO this
> > > >
> > > > >>is the best that can be done to make sure that
> > >
> > > new
> > >
> > > > rules added/removed from
> > > >
> > > > >>specs will be promptly integrated into
> >
> > verifier.
> >
> > > > I'm thinking in Chain of
> > > >
> > > > >>Responsability to manage the rules, but each
> > >
> > > rule
> > >
> > > > will have to say about
> > > >
> > > > >>what domain it`s related (home interfaces
> >
> > rules,
> >
> > > > local interfaces rules,
> > > >
> > > > >>session rules and so on). One "class rule" can
> > >
> > > be
> > >
> > > > related to more than one
> > > >
> > > > >>domain. This will speed up the process, as the
> > > >
> > > > verifies asks only the rules
> > > >
> > > > >>related to the domain that it`s verifying at
> > > >
> > > > moment;
> > > >
> > > > >>2. It should have an interface for expressing
> > > >
> > > > rules violations, like
> > > >
> > > > >>ActionError on Struts. This interface should
> > >
> > > allow
> > >
> > > > to query about what
> > > >
> > > > >>section was violated, the message related to
> >
> > the
> >
> > > > error (with i18n for sure
> > > >
> > > > >>;) ), the offendind class and so on. This way,
> > >
> > > any
> > >
> > > > tool that want to use
> > > >
> > > > >>the validator can get the error lists and
> > > >
> > > > manipulate them as they want; IMO
> > > >
> > > > >>this is better than exceptions because we can
> > > >
> > > > generate several violations
> > > >
> > > > >>at once and is better that string messages
> > >
> > > because
> > >
> > > > gives more flexibility.
> > > >
> > > > >>3. The validator will have to read the
> > > >
> > > > application.xml and ejb-jar.xml
> > > >
> > > > >>files to do the job (specific deployment files
> > > >
> > > > like jboss.xml would be
> > > >
> > > > >>interesting but have to be integrated in a
> > >
> > > really
> > >
> > > > modular way). The point
> > > >
> > > > >>is that the server will have to read these
> >
> > file
> >
> > > as
> > >
> > > > well to startup the
> > > >
> > > > >>application. So, the reader should be placed
> >
> > in
> >
> > > a
> > >
> > > > common lib. Do anyone
> > > >
> > > > >>knows if jakarta already have this
> >
> > implemented?
> >
> > > > >>4. If we will write the XMLs readers decribed
> > > >
> > > > above, does everyone agrees
> > > >
> > > > >>in using JAXB?
> > > > >>
> > > > >>
> > > > >>Cheers,
> > > > >>Denes
> > > > >>
> > > > >>Citando Jonathan Duty <jduty@jonandkerry.com>:
> > > > >>>Great.  Lets get a maven project stub
> >
> > generated
> >
> > > > and get started.  Any
>
> === message truncated ===
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com

Mime
View raw message