geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Labeeb Syed <anhk...@yahoo.com>
Subject Re: J2EE deployment verifier
Date Mon, 11 Aug 2003 21:32:11 GMT
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