What would your preference be? I thought it would be useful for
the metadata to verify the classes, but it could simply store the String
name instead of the Class object if we want to move that responsibility
elsewhere. I think any exceptions coming out of the parser turn into
SAXExceptions, so we can't really use a custom exception here (unless you
can get the original exception from a SAXException - I don't have the
stuff here at work).
I assume any honest SAX exceptions should still be thrown (for
badly formatted XML, etc). But we may want to use a validating parser to
make sure we don't get bogus exceptions (i.e. NullPointerExceptions caused
by out-of-order elements, which just turn into a SAXException with the
unhelpful messages "null" or "").
Aaron
On Mon, 10 Jul 2000, Juha Lindfors wrote:
> Hey,
>
> the new metadata implementation seems to have changed the semantics of
> jBossFileManager a bit. The verifier used to use this to get to the
> application and peek through all the stuff that's in there before letting
> the deployer go at it. This included the contents of ejb-jar.xml. Now the
> XML Reader stuff attempts to load the bean classes and stuff, and if it
> fails throws a SAXException.
>
> This leaves the verifier with a difficult to parse exception message and a
> null pointer. Essentially making it unable to tell the user nicely what's
> going wrong (though admittedly a user with any idea what theyre doing
> should able to figure out their error from that stack trace, but its still
> a stack trace, not a pretty gui error message or whatever).
>
> Anyhow, how should this be dealt with. Leave this part of verifying to the
> metadata XML parser, return a more usable exception that can be refined by
> the verifier if necessary, remove the classloading part from the metadata
> and return to the old semantics where the error is hit later (by verifier,
> or if its off, the container)?
>
> How should I work around this?
>
> -- Juha
>
>
>
