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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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, > > [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>: > > >> > > >> > > >>>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
