Well, the verifier should be able to access the metadata even if there are
errors in it, so that it can report all of them at once. So from that point
of view returning a null at the first error is not an option (which makes
the exception solution unusable.)
So instead, we could either have the xml reader store any error states in
the object itself that can then be accessed by whomever needs that
information (so if the classload fails, just store a null Class and set an
error flag) or go with the string solution, and let the other parts of the
server figure out if the metadata is correct or not.
Either one works for me, as long as I can get data to work with even in
case of (non fatal) errors.
-- Juha
At 15:04 10.7.2000 -0400, you wrote:
> 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
>>
>>
>>
>
>
>
