I just checked the past logs, I believe we are standardizing to J2EE v1.4 spec using JDK v1.4.2.
--- Labeeb Syed <[EMAIL PROTECTED]> 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 <[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 > === message truncated === __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
