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 <[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
