Hi!
marc fleury wrote:
> Rickard, before I dive in (let's move it to jBoss dev)
> I believe we can probably work mostly from the ejb-jar.xml (with no CMP
> stuff R>O, we can do O>R default)
> however if this file is screwed up (as I understand might be the case with
> the user now) we need that error since the EJB configuration is screwed up.
> I believe Dan OConnor mapped these cases in a previous mail (<much
> respect/>) and it seems we are running head first in his design. So in case
> ejb-jar is f*cked up we need an explicit error I can catch and say "yo! get
> your base file in order" and barf. For the jboss.xml and such we can be
> more lenient (case 2 of Dan) with the message from Jim archer (as I have
> now) so either explicit classes EJBJARSuckedUpException.java and such or
> explicit returns I can check.
>
> Can you tell me where the "exception" generation stands at right now? it
> might save me some digging (with no doco, no comments, implicit stuff and in
> the case of EJX, not even code ;-) yeah! yeah! yeah!
Well, if you remember, this was assigned to Juha. Juha, what's up?
IMHO we should have an "EJBValidator" that, upon deploy, can get the Jar
and apply all sorts of rules to test if it's ok.
Something like this (in ContainerFactory.deploy):
EJBValidator val = new EJBValidator();
val.addValidationListener(this);
val.validate(ejbJar);
// This will produce a set of ValidationEvent's. The CF should track
these, and if any harmful ones are found, then we barf
if (validationFailed) throw new DeploymentException("Invalid EJB-jar or
XML");
The events should be printed to the log, *or*, we might want to change
DeploymentException so that it can include a list of problems.
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
