I don't see anything obviously wrong with
your code.
My suggestion would be to code up some simple
unit tests and start there. Once you find the
problem, add a unit test to cover that scenario.
One of the more difficult problems I had to work
around was the fact that a new SAX parser would be
created to parse every new file. The XMLcatalog
had to be separately added to every one of them.
( Where are JavaScript's prototypes when you need
them? :)
I am not sure if this is what you are running into.
Good luck,
--Craeg
> I've taken a first stab at adding support for nested <xmlcatalog>
> elements within <ejbjar>, but I'm running into some problems I thought
> I'd run by the list.
>
> First glance, it appeared pretty easy. Add a few methods and insert
> the following bit of code in the execute method:
>
> if (xmlCatalog != null) {
> saxParser.getXMLReader().setEntityResolver(xmlCatalog);
> }
>
> Since saxParser gets passed into the various vendor-specific deployment
> tool classes, I thought that would do the trick. But it's not (why
> would I be writing this otherwise :-) ?). The problem is that I'm not
> familiar enough with SAX; previous hacking involved adding XMLCatalog
> support to tasks that used DOM. Also, I'm not intimately familiar with
> the inner workings of the org.apache.tools.ant.taskdefs.optional.ejb.*
> classes.
>
> So I thought I'd throw this out there and see if I'm doing something
> stupid/easily fixed. Diff included below for full disclosure.
>
> Thanks,
> Kyle
>
<snip>code fragment</snip>
