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:22:50 GMT
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
> > >>>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
> > >>>
> 
=== message truncated ===


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

Mime
View raw message