[xmlc] Re: Re: Re: Re: Re: Issues with XMLC 2.3.2

This is a multi-part message in MIME format...

------------=_1301408735-30467-16157
Content-Type: text/plain;charset=iso-8859-1; format="flowed"
Content-Transfer-Encoding: quoted-printable

Good research.=A0 But my conclusion would be to not explicitly provide a=20
singleton instance of the document loader to the XMLCDeferredParsingFacto=
ry=20
constructor.=A0 Either pass in null (in which case, a non-singleton=20
StandardDocumentLoader is used by default) or a non-singleton instance of=
 your=20
preferred document loader.

Wouldn't that solve your issue?

Jake

On Tue, 29 Mar 2011 13:41:51 +0200
=A0Sasa Bojanic <[email protected]> wrote:
> And again :-)
>=20
> The change with new XMLC is that when searching for source URLs -=20
>findSourceURL method of DocumentLoaderImpl, now the Classloader provided=
 to=20
>the last created XMLCDeferredParsingFactory is used, while XMLC2.3-1 use=
d the=20
>Classloader which was used to load the Class provided as an argument to=20
>findSourceURL method (which was in most of the cases the same one that i=
s=20
>also loading other resources).
>=20
> That's why I would suggest (to make XMLC being able to "sit" in the sha=
red=20
>classloader) the change in XMLCDeferredParsingFactory similar to the one=
 I=20
>posted the last time:
>=20
>=A0=A0=A0=A0 public final URL getPathURLFromClasspath(String path) {
>=A0=A0=A0=A0=A0=A0=A0=A0 URL srcURL =3D fDynamicClassLoader.getResource(=
path);
>=A0=A0=A0=A0=A0=A0=A0=A0 if (srcURL=3D=3Dnull) {
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ClassLoader loader =3D=20
>Thread.currentThread().getContextClassLoader();
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if (loader!=3Dnull) {
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 srcURL =3D loader.getRe=
source(path);
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 }
>=A0=A0=A0=A0=A0=A0=A0=A0 }
>=A0=A0=A0=A0=A0=A0=A0=A0 if ((srcURL !=3D null) && getLogger().debugEnab=
led()) {
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 getLogger().logDebug(">>>Get docume=
nt '"
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0+ srcURL
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0+ "' from classpath");
>=A0=A0=A0=A0=A0=A0=A0=A0 }
>=A0=A0=A0=A0=A0=A0=A0=A0 return srcURL;
>=A0=A0=A0=A0 }
>=20
> This way, we always try to use the class loader "registered" with=20
>XMLCDeferredParsingFactory, and if resource is not found, we use current=
=20
>thread's class loader.
> That would solve the issues with XMLC "sitting" in the shared LIB, and =
in=20
>other scenarios it would behave like it is today.
>=20
> Of course, we could implement our own DocumentLoader/ResourceLoader, an=
d=20
>insure it always "gets" the proper Classloader...and change our applicat=
ion=20
>code to create XMLC Java objects by explicitly using constructor with=20
>DocumentLoader....but it seems to me a lot of unnecessary changes to the=
=20
>applications developed on top of XMLC, and used with XMLC "sitting" in s=
hared=20
>classloader.
>=20
> Am I missing something this time as well?
>=20
> Greetings,
> Sasa.
>=20
> On 29-Mar-11 12:20, Sasa Bojanic wrote:
>> Back to the classloader issue...let me try to explain...you can probab=
ly=20
>>produce the same problem when you have TWO web apps with XMLC and when =
XMLC=20
>>is loaded by Tomcat's SHARED classloader...the one of the apps will not=
 work.
>>
>> So, everything works fine when I have only ONE XMLC based application,=
 and=20
>>XMLC (+xerces and other JAR files) are in Tomcat's SHARED lib.
>>
>> However, when I have two applications, one of them is not working, can=
't=20
>>find XMLC resources within JAR files.
>>
>> I investigated a bit, and this is what happens:
>>
>> 1) App1 starts, XMLCDeferredParsingFactory for this app is created and=
 is=20
>>provided with Classloader1 (via=20
>>Thread.currentThread().getContextClassLoader()).
>> 2) App2 starts, XMLCDeferredParsingFactory for this app is created and=
 is=20
>>provided with Classloader2 (via=20
>>Thread.currentThread().getContextClassLoader()).
>> (This is the change I've introduced in Enhydra Framework to test this=20
>>scenario - to use Thread.currentThread().getContextClassLoader() instea=
d of=20
>>our MultiClassLoader)
>> 3) When I use App1 (Calculator app), the following code is being execu=
ted:
>>
>>=A0=A0=A0=A0 calculator =3D=20
>>(CalculatorHTML)comms.xmlcFactory.create(CalculatorHTML.class);
>>
>> Then I trace:
>>
>> - XMLCDeferredParsingFactory that starts to create CalculatorHTML obje=
ct=20
>>(XMLC class generated from HTML template) is the right one for App1
>> - create(Class) method from XMLCDeferredParsingFactory calls doCreate(=
Class)=20
>>and then createObject(Class) methods on the RIGHT XMLCDeferredParsingFa=
ctory=20
>>for App1 (calculator)
>> - In createObject(Class) method, reflection is used to create a new in=
stance=20
>>of CalculatorHTML object:
>>
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Constructor constructo=
r =3D=20
>>xmlcBasedClass.getConstructor(CONSTRUCTOR_ARG_TYPES);
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return (XMLObject)cons=
tructor.newInstance(fConstructorArgs);
>>
>> - The constructor argument for generated XMLC class (CalculatorHTML in=
 this=20
>>case) is a DocumentLoader (in my case a singleton instance of=20
>>StandardDocumentLoader)
>> - The=A0=A0constructor gets executed, and the method buildDocument() i=
s called
>> - buildDocument() method obtains DocumentLoader provided while constru=
cting=20
>>the object and calls getDocument() method, which calls getCacheEntry()=20
>>method, which calls findSourceUrl() method...and here I get an exceptio=
n:
>>
>> org.enhydra.xml.xmlc.XMLCRuntimeException: Source path(s)=20
>>'[calculator/presentation/Calculator.html]' not found for=20
>>calculator.presentation.CalculatorHTML
>>
>> What actually happens here is that findSourceUrl() calls ResourceLoade=
rImpl:=20
>>getResource()->getPathURLFromResourceDirOrClassPath(), and then=20
>>XMLCDeferredParsingFactory.getPathURLFromClasspath() method is called (=
The=20
>>one I first patched in=A0=A0my first post...but in the case when I used=
 our=20
>>MultiClassLoader).
>>
>> The point is this XMLCDeferredParsingFactory is the one from App2, and=
 thus=20
>>is the classloader it is using.
>>
>> The dump stack to explain what I described above:
>> java.lang.Exception: Stack trace
>>=A0=A0=A0=A0=A0=A0=A0=A0 at java.lang.Thread.dumpStack(Thread.java:1206=
)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.enhydra.xml.xmlc.deferredparsing.XMLCDeferredParsingFactory.getPath=
URLFromClasspath(XMLCDeferredParsingFactory.java:736)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.enhydra.xml.xmlc.deferredparsing.ResourceLoaderImpl.getPathURLFromC=
lasspath(ResourceLoaderImpl.java:101)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.enhydra.xml.xmlc.deferredparsing.ResourceLoaderImpl.getPathURLFromR=
esourceDirOrClasspath(ResourceLoaderImpl.java:80)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.enhydra.xml.xmlc.deferredparsing.ResourceLoaderImpl.getResource(Res=
ourceLoaderImpl.java:52)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.findSourceUrl(D=
ocumentLoaderImpl.java:297)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.getCacheEntry(D=
ocumentLoaderImpl.java:174)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.getDocument(Doc=
umentLoaderImpl.java:247)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>calculator.presentation.CalculatorHTML.buildDocument(CalculatorHTML.jav=
a:112)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>calculator.presentation.CalculatorHTML.<init>(CalculatorHTML.java:92)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>calculator.presentation.CalculatorHTML.<init>(CalculatorHTML.java:104)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at sun.reflect.NativeConstructorAccessorImpl.n=
ewInstance0(Native=20
>>Method)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructor=
AccessorImpl.java:39)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCon=
structorAccessorImpl.java:27)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at java.lang.reflect.Constructor.newInstance(C=
onstructor.java:513)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.enhydra.xml.xmlc.deferredparsing.XMLCDeferredParsingFactory.createO=
bject(XMLCDeferredParsingFactory.java:163)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.enhydra.xml.xmlc.deferredparsing.XMLCDeferredParsingFactory.doCreat=
e(XMLCDeferredParsingFactory.java:188)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.enhydra.xml.xmlc.XMLCStdFactory.create(XMLCStdFactory.java:139)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>calculator.presentation.CalculatorPresentation.getState(CalculatorPrese=
ntation.java:209)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>calculator.presentation.CalculatorPresentation.run(CalculatorPresentati=
on.java:49)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>com.lutris.appserver.server.httpPresentation.HttpPresentationManager.ru=
nPresentationObj(HttpPresentationManager.java:496)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>com.lutris.appserver.server.httpPresentation.HttpPresentationManager.Ru=
n(HttpPresentationManager.java:269)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>com.lutris.appserver.server.httpPresentation.servlet.HttpPresentationSe=
rvlet.serviceDirect(HttpPresentationServlet.java:677)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>com.lutris.appserver.server.httpPresentation.servlet.HttpPresentationSe=
rvlet.service(HttpPresentationServlet.java:787)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at javax.servlet.http.HttpServlet.service(Http=
Servlet.java:717)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applic=
ationFilterChain.java:290)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFil=
terChain.java:206)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVal=
ve.java:233)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.apache.catalina.core.StandardContextValve.invoke(StandardContextVal=
ve.java:191)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav=
a:127)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.jav=
a:102)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve=
.java:109)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:=
298)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.=
java:861)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.proc=
ess(Http11AprProtocol.java:579)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>>org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1584=
)
>>=A0=A0=A0=A0=A0=A0=A0=A0 at java.lang.Thread.run(Thread.java:619)
>> SRC URL=3Dnull
>>
>>
>> The reason for this is in the constructor of XMLCDeferredParsingFactor=
y:
>>
>>=A0=A0=A0=A0 public XMLCDeferredParsingFactory(DocumentLoader docLoader=
,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Clas=
sLoader classLoader,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 XMLC=
Logger logger) {
>>=A0=A0=A0=A0=A0=A0=A0=A0 super(classLoader, logger);
>>=A0=A0=A0=A0=A0=A0=A0=A0 if (docLoader =3D=3D null) {
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 docLoader =3D new StandardDocument=
Loader();
>>=A0=A0=A0=A0=A0=A0=A0=A0 }
>>=A0=A0=A0=A0=A0=A0=A0=A0 fConstructorArgs =3D new Object[] { docLoader =
};
>>=A0=A0=A0=A0=A0=A0=A0=A0 fDocLoader =3D docLoader;
>>=A0=A0=A0=A0=A0=A0=A0=A0 fDynamicClassLoader =3D new DynamicClassLoader=
(classLoader, logger);
>>=A0=A0=A0=A0=A0=A0=A0=A0 // Initialize the document loader...
>> *=A0=A0=A0=A0=A0=A0=A0=A0fDocLoader.init(this);*
>>=A0=A0=A0=A0 }
>>
>> The SINGLETON StandardDocumentLoader is initialized with the LAST=20
>>XMLCDeferredParsingFactory, and thus always taking the LAST APPs' class=
loader=20
>>(Thread.currentThread().getContextClassLoader() of the application that=
 was=20
>>last initialized).
>>
>> And that is why the resource can't be found. The classloader of the 2n=
d app=20
>>can't find the resource of the 1st one.
>>
>> The point is that in the past our MultiClassLoader was "somehow" handl=
ing=20
>>that situations, and we were always passing this classloader (instead o=
f=20
>>Thread.currentThread().getContextClassLoader()) to every XMLC based=20
>>application, but for some reason (Tomcat bug or bug in our MultiClassLo=
ader=20
>>in the combination with the changes in XMLC) it does not work any more.
>>
>> Just wanted to report this...maybe it could also help you to see the=20
>>possible usage scenarios of XMLC (when many WEB applications are sharin=
g the=20
>>XMLC classes instead of each of them loading it separately), and the is=
sues=20
>>raised in that case.
>>
>> Greetings,
>> Sasa.
>>
>> On 29-Mar-11 08:02, Sasa Bojanic wrote:
>>> When I change the code as you suggested, the problem disappears.
>>>
>>> I assume there is nothing to report to NEKOHTML then?
>>>
>>> Thanks,
>>> Sasa.
>>>
>>> On 29-Mar-11 08:51, Jacob Kjome wrote:
>>>> I suspect nekohtml is manipulating the table in ways you didn't expe=
ct.=20
>>>> Check out
>>>> this from the 1.9.13 release note [1]...
>>>>
>>>> "automatically add TBODY around TR nested directly within TABLE"
>>>>
>>>> You say your code is...
>>>>
>>>> table.removeChild(page.getElementTemplateRow());
>>>>
>>>> But if nekohtml is adding a TBODY node around TR, then TR is not a c=
hild of=20
>>>>TABLE,
>>>> but TBODY, which could very well explain the error you are seeing.=A0=
=A0It seems=20
>>>>to me
>>>> that safer code would be...
>>>>
>>>> page.getElementTemplateRow().getParentNode().removeChild(page.getEle=
mentTemplateRow());=20
>>>>
>>>>
>>>> Can you try that and let me know if the issue goes away with nekohtm=
l=20
>>>>version
>>>> 1.9.13 or later?
>>>>
>>>>
>>>> [1] http://nekohtml.sourceforge.net/changes.html
>>>>
>>>> Jake
>>>>
>>>> On 3/29/2011 12:06 AM, Jacob Kjome wrote:
>>>>> I've narrowed down the DOMException NOT_FOUND_ERR problem to nekoht=
ml.=A0=A0When=20
>>>>>I use
>>>>> version 1.9.8, which is distributed with XMLC 2.3.1, everything wor=
ks fine,=20
>>>>>even
>>>>> with XMLC 2.3.2.=A0=A0But when I use version 1.9.14, I get the erro=
r you=20
>>>>>reported,
>>>>> even with XMLC 2.3.1.
>>>>>
>>>>> I backtracked through the versions of nekohtml to find the latest v=
ersion=20
>>>>>that
>>>>> would work.=A0=A0I discovered that version 1.9.12 works fine, but 1=
.9.13 fails.=20
>>>>> So,
>>>>> something introduced in 1.9.13 is causing the problem.=A0=A0I'll tr=
y to do some=20
>>>>>more
>>>>> digging this week to figure out what the root cause is.=A0=A0It wou=
ld be great=20
>>>>> if you
>>>>> could do the same.=A0=A0When we can pinpoint the issue, we can repo=
rt it as a=20
>>>>>bug in
>>>>> the nekohtml sourceforge project [1].
>>>>>
>>>>>
>>>>> [1] http://sourceforge.net/projects/nekohtml/
>>>>>
>>>>>
>>>>> Jake
>>>>>
>>>>> On 3/28/2011 2:28 PM, Sasa Bojanic wrote:
>>>>>> My mistake about the "general" problem...now I see that generated =
XMLC
>>>>>> Java classes have non-default constructor taking DocumentLoader ob=
ject
>>>>>> as an initialization parameter...sorry.
>>>>>>
>>>>>> I still hesitate to contact Tomcat guys since I'm not deep into ou=
r
>>>>>> MultiClassLoader code...so I don't know if there is a bug in-there=
.
>>>>>>
>>>>>> Regarding DOM problem, yes, I tried both XERCES/XML-APIS from XMLC=
2.3-1
>>>>>> and XMLC2.3-2, and the result is the same.
>>>>>>
>>>>>> "projectManagement" application and ALL other applications from th=
e ZIP
>>>>>> file:
>>>>>> https://docs.google.com/leaf?id=3D0B9ZAe6ftekYJMGVmYjdmZDMtMjY5YS0=
0MDU4LWIzNWEtYzhiMjBlMzZjYTZj&sort=3Dname&layout=3Dlist&pid=3D0B9ZAe6ftek=
YJNWQ0ZDRmNjMtN2M2MS00NDIyLWJmZmUtYWE0Y2Y4MDFiMDUw&cindex=3D18=20
>>>>>>
>>>>>>
>>>>>> are prepared for Stand-alone Tomcat deployment...
>>>>>>
>>>>>> Greetings,
>>>>>> Sasa.
>>>>>>
>>>>>> On 28-Mar-11 22:04, Jacob Kjome wrote:
>>>>>>> See comments inline below...
>>>>>>>
>>>>>>> On Mon, 28 Mar 2011 14:35:27 +0200
>>>>>>>=A0=A0 Sasa Bojanic<[email protected]>=A0=A0wrote:
>>>>>>>> Jake, first of all, thanks a lot for your effort!
>>>>>>>>
>>>>>>> No problem.=A0=A0I any changes I made are breaking applications, =
I want to
>>>>>>> make sure they get corrected, or at least explained, properly.
>>>>>>>
>>>>>>>> ...here is the followup:
>>>>>>>>
>>>>>>>> 1) I think there is a general problem in XMLC when implementing
>>>>>>>> CustomDocumentLoader/CustomResourceLoader.
>>>>>>>> Hence, the JAVA classes generated based on HTML template always =
use
>>>>>>>> StandardDocumentLoader.
>>>>>>> I'm not sure I understand how this is a "general problem" with
>>>>>>> document/resource loaders.=A0=A0Keep in mind, they are resource l=
ocation
>>>>>>> generic, i.e., they are meant to make resource loading plugable,
>>>>>>> allowing loading from contexts not possible prior to XMLC 2.3.2, =
such
>>>>>>> as the servlet context... or even a database.=A0=A0Loading from a=
 class
>>>>>>> loader is merely one option, albeit a built-in default one as it =
has
>>>>>>> been available (along with loading from configured resource
>>>>>>> directories) since the original XMLC 2.2 release.=A0=A0The custom=
 one I
>>>>>>> created for you is a minimal implementation that simply overrides=
 the
>>>>>>> way URLs are obtained from the class loader in the default resour=
ce
>>>>>>> loader implementation.
>>>>>>>
>>>>>>> In my view, this is clearly a class loader bug.=A0=A0If the class=
 loader
>>>>>>> can actually see the resource and provide a URL, then that URL ou=
ght
>>>>>>> to be a valid one.=A0=A0That Tomcat's StandardClassLoader is retu=
rning an
>>>>>>> invalid URL is absolutely a bug that should be reported to, and
>>>>>>> corrected by, the Tomcat team.=A0=A0Supplying the thread context =
class
>>>>>>> loader to the XMLCDeferredParsingFactory constructor is the obvio=
us
>>>>>>> workaround.=A0=A0But it is a workaround only made necessary by a =
class
>>>>>>> loader bug.
>>>>>>>
>>>>>>> That said, I recommend using the thread context class loader
>>>>>>> regardless of this particular class loader bug, as it provides th=
e
>>>>>>> added benefit of allowing XMLC libraries in the server lib to be =
able
>>>>>>> to see classes and resources in a child classloader (e.g, the
>>>>>>> WebappClassLoader).
>>>>>>>
>>>>>>>> Don't know if this can be somehow configured to specify the cust=
om
>>>>>>>> one? options.xmlc?
>>>>>>>>
>>>>>>> I really view this as outside the scope of XMLC configuration.=A0=
=A0That
>>>>>>> configuration is focused on template configuration, not how they =
are
>>>>>>> loaded.=A0=A0Besides, the resource loader is used to load options=
.xmlc.
>>>>>>> It's a chicken/egg problem.=A0=A0Application code has complete co=
ntrol
>>>>>>> over how the XMLCDeferredParsingFactory is instantiated, so it is
>>>>>>> application code where this should be addressed.
>>>>>>>
>>>>>>> XMLCContext, if you so choose to use it, provides for various ser=
vlet
>>>>>>> context parameters that you can configure in web.xml to specify
>>>>>>> various things, including document loaders.=A0=A0And it **ALWAYS*=
*
>>>>>>> instantiates the XMLCDeferredParsingFactory using the thread cont=
ext
>>>>>>> class loader.=A0=A0See....
>>>>>>>
>>>>>>> http://websvn.ow2.org/filedetails.php?repname=3Dxmlc&path=3D%2Ftr=
unk%2Fxmlc%2Fexamples%2Ftomcat%2Fres%2Fwebapps%2Fxmlc%2FWEB-INF%2Fweb.xml=
.in=20
>>>>>>>
>>>>>>>
>>>>>>> http://websvn.ow2.org/filedetails.php?repname=3Dxmlc&path=3D%2Ftr=
unk%2Fxmlc%2Fexamples%2Ftomcat%2Fsrc%2Fxmlc%2Fdemo%2FPreview.java=20
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> All you need to do to access it is...
>>>>>>>
>>>>>>> XMLCContext context =3D XMLCContext.getContext(servletObj);
>>>>>>> ...or...
>>>>>>> XMLCContext context =3D XMLCContext.getContext(servletContextObj)=
;
>>>>>>>
>>>>>>> ...and then...
>>>>>>> XMLCDeferredParsingFactory dpFactory =3D
>>>>>>> context.getXMLCDeferredParsingFactory();
>>>>>>>
>>>>>>>
>>>>>>> If you use this, your applications will be more configurable and =
never
>>>>>>> run into invalid URLs again.
>>>>>>>
>>>>>>>
>>>>>>>> 2) Maybe it makes sense to implement the following patch to XMLC=
's
>>>>>>>> ResourceLoaderImpl:
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0 protected URL getPathURLFromClasspath(final St=
ring candidatePath) {
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0URL url =3D
>>>>>>>> Thread.currentThread().getContextClassLoader().getResource(candi=
datePath);=20
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0if (url=3D=3Dnull) {
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 url =3D fFactory.getPathURLF=
romClasspath(candidatePath);
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0}
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return url;
>>>>>>>>=A0=A0=A0=A0=A0=A0}
>>>>>>>>
>>>>>>> Actually, it would be the thread context classloader that might b=
e
>>>>>>> null, in the case that the code is not running under a JEE server=
 that
>>>>>>> sets it.=A0=A0That said, it's an option to consider, e.g.,....
>>>>>>>
>>>>>>>=A0=A0=A0=A0=A0=A0protected URL getPathURLFromClasspath(final Stri=
ng candidatePath) {
>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0ClassLoader loader =3D
>>>>>>> Thread.currentThread().getContextClassLoader();
>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0if (loader !=3D null) {
>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return loader..getResour=
ce(candidatePath);
>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0}
>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return fFactory.getPathURLFromClassp=
ath(candidatePath);
>>>>>>>=A0=A0=A0=A0=A0=A0}
>>>>>>>
>>>>>>> But while this might transparently resolve your issue, it takes a=
way
>>>>>>> the ability of the user to determine the class loader to use, whi=
ch
>>>>>>> they can currently specify by supplying their class loader of cho=
ice
>>>>>>> to the XMLCDeferredParsingFactory constructor.=A0=A0For this reas=
on, I
>>>>>>> hesitate to implement this option.
>>>>>>>
>>>>>>>
>>>>>>>> 3) I found the place where we can patch Enhydra's MultiClassLoad=
er
>>>>>>>> (similar way as the patch provided for XMLCDeferredParsingFactor=
y),
>>>>>>>> so that it returns the "right" resource path in the case of JAR
>>>>>>>> files, so actually from our side, there is no need for the
>>>>>>>> modification mentioned above.
>>>>>>> I take it your class loader wraps Tomcat's StandardClassLoader (w=
hen
>>>>>>> running under Tomcat, that is)?=A0=A0Maybe you should have it wra=
p the
>>>>>>> thread context class loader instead?=A0=A0That way, you avoid the
>>>>>>> StandardClassLoader's buggyness.=A0=A0In any case, there's no goo=
d reason
>>>>>>> for any class loader to return invalid URLs.=A0=A0Again, I urge y=
ou to
>>>>>>> report this issue to the Tomcat developers so this issue can be
>>>>>>> properly fixed for everyone using Tomcat's StandardClassLoader.
>>>>>>>
>>>>>>>> 4) When implementing either the modification on ResourceLoaderIm=
pl or
>>>>>>>> changing MultiClassLoader, calculator and discRack applications =
are
>>>>>>>> working normally. However, the projectManagement application is
>>>>>>>> working only "partially"...maybe it is a completely new problem
>>>>>>>> there, or this is the similar one but somehow hidden and not so
>>>>>>>> obvious to determine (just to mention that application works nor=
mally
>>>>>>>> under EXACTLY THE SAME conditions under XMLC2.3-1).
>>>>>>>> The start page of projectManagement applications is generated
>>>>>>>> smoothly, when you log in as admin/enhydra, the next page is als=
o OK.
>>>>>>>> However, when you click on the link "Employee" or "Customer", th=
e
>>>>>>>> following exception is thrown:
>>>>>>>>
>>>>>>> This is a completely distinct problem.=A0=A0This is either an iss=
ue with
>>>>>>> the LazyDOM or, possibly with Xerces itself.=A0=A0Did you try dow=
ngrading
>>>>>>> to the version of xercesImpl and xml-apis that came with XMLC-2.3=
.1?
>>>>>>> Please try that first.=A0=A0If you still get an error, let me kno=
w.=A0=A0I
>>>>>>> think there was a change to the lazydom for XMLC 2.3.2 (some bug
>>>>>>> fix).=A0=A0I can't recall exactly what it was, though.=A0=A0It's =
possible I
>>>>>>> introduced a regression.=A0=A0Only more testing will tell.
>>>>>>>
>>>>>>> BTW, is the "projectManagement" application runnable under
>>>>>>> Tomcat-Standalone or does it require Enhydra server?
>>>>>>>
>>>>>>>> org.w3c.dom.DOMException: NOT_FOUND_ERR: An attempt is made to
>>>>>>>> reference a node in a context where it does not exist.
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> org.apache.xerces.dom.ParentNode.internalRemoveChild(Unknown Sou=
rce)
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at org.apache.xerces.dom.ParentNod=
e.removeChild(Unknown Source)
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> org.enhydra.xml.lazydom.LazyElementNoNS.removeChild(LazyElementN=
oNS.java:338)=20
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> projectmanagement.presentation.employees.Administering.handleDef=
ault(Administering.java:80)=20
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> projectmanagement.presentation.BasePO.handleEvent(BasePO.java:28=
2)
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at projectmanagement.presentation.=
BasePO.run(BasePO.java:156)
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> com.lutris.appserver.server.httpPresentation.HttpPresentationMan=
ager.runPresentationObj(Unknown=20
>>>>>>>> Source)
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> com.lutris.appserver.server.httpPresentation.HttpPresentationMan=
ager.Run(Unknown=20
>>>>>>>> Source)
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> com.lutris.appserver.server.httpPresentation.servlet.HttpPresent=
ationServlet.serviceDirect(HttpPresentationServlet.java:697)=20
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> com.lutris.appserver.server.httpPresentation.servlet.HttpPresent=
ationServlet.service(HttpPresentationServlet.java:822)=20
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at javax.servlet.http.HttpServlet.=
service(HttpServlet.java:717)
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter=
(ApplicationFilterChain.java:290)=20
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(Applica=
tionFilterChain.java:206)=20
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWra=
pperValve.java:233)=20
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> org.apache.catalina.core.StandardContextValve.invoke(StandardCon=
textValve.java:191)=20
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostVa=
lve.java:127)=20
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportVa=
lve.java:102)=20
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngi=
neValve.java:109)=20
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapte=
r.java:298)=20
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> org.apache.coyote.http11.Http11AprProcessor.process(Http11AprPro=
cessor.java:861)=20
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandl=
er.process(Http11AprProtocol.java:579)=20
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>>>> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.ja=
va:1584)=20
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at java.lang.Thread.run(Thread.jav=
a:662)
>>>>>>>>
>>>>>>>>
>>>>>>>> (I just modified a little bit original sources to print the stac=
k
>>>>>>>> trace of the exception).
>>>>>>>>
>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0 table.removeChild(page.getElementTemplat=
eRow());
>>>>>>>>
>>>>>>>> The strange is that such exception does not happen when accessin=
g
>>>>>>>> Project/Pay Rate/Worksheet links, and the code for this pages is
>>>>>>>> similar...removal of table template row happens.
>>>>>>>>
>>>>>>>> Can you give me some leads here?
>>>>>>>>
>>>>>>> See above for answers.
>>>>>>>
>>>>>>>> Greetings,
>>>>>>>> Sasa.
>>>>>>>>
>>>>>>>
>>>>>>> Jake
>>>>>>>
>>>>>>>> On 28-Mar-11 07:11, Jacob Kjome wrote:
>>>>>>>>> I tried out your calculator.war example and was able to replica=
te
>>>>>>>>> the problem.
>>>>>>>>> I've also tracked down the cause.=A0=A0It turns out that while =
XMLC
>>>>>>>>> 2.3.1 and 2.3.2
>>>>>>>>> still do essentially the same thing, there's a nuance in how so=
urce
>>>>>>>>> file URLs are
>>>>>>>>> created.=A0=A0In XMLC 2.3.1, the classloader used to obtain the=
 URL is
>>>>>>>>> the same one
>>>>>>>>> that loaded the XMLC class file.=A0=A0In XMLC 2.3.2, it's the o=
ne
>>>>>>>>> provided to the
>>>>>>>>> XMLCDeferredParsingFactory constructor.
>>>>>>>>>
>>>>>>>>> Now, in the Tomcat demo application, this turns out to be the s=
ame
>>>>>>>>> classloader, as
>>>>>>>>> XMLCContext provides
>>>>>>>>> "Thread.currentThread().getContextClassLoader()" to the
>>>>>>>>> XMLCDeferredParsingFactory constructor and, of course, this end=
s up
>>>>>>>>> being the
>>>>>>>>> WebappClassLoader as it's a thread from the current application=
 that
>>>>>>>>> is loading
>>>>>>>>> all the classes and the server sets this as the thread context =
class
>>>>>>>>> loader for us.
>>>>>>>>>
>>>>>>>>> As it turns out, when URLs are created from the WebappClassLoad=
er,
>>>>>>>>> loader.toString(), or loader.toExternalForm(), produces a valid=
 JAR
>>>>>>>>> URL, such as...
>>>>>>>>>
>>>>>>>>> jar:file:/E:/Java/Apache/apache-tomcat-7.0.11/webapps/calculato=
r/WEB-INF/lib/calculator.jar!/calculator/presentation/Calculator.html=20
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> However, in the calculator application, the classloader provide=
d to the
>>>>>>>>> XMLCDeferredParsingFactory constructor is actually the parent
>>>>>>>>> classloder of the
>>>>>>>>> WebappClassLoader and, under Tomcat Standalone, an instance of
>>>>>>>>> "org.apache.catalina.loader.StandardClassLoader".
>>>>>>>>>
>>>>>>>>> As it turns out, when URLs are created from the StandardClassLo=
ader,
>>>>>>>>> loader.toString(), or loader.toExternalForm(), produces an inva=
lid
>>>>>>>>> JAR URL, such as...
>>>>>>>>>
>>>>>>>>> file:/E:/Java/Apache/apache-tomcat-7.0.11/webapps/calculator/WE=
B-INF/lib/calculator.jarcalculator/presentation/Calculator.html=20
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This subtle change in behavior was unforeseen and you are the f=
irst
>>>>>>>>> to report it.
>>>>>>>>>=A0=A0=A0=A0 I never encountered it in my testing because, as me=
ntioned
>>>>>>>>> previously, I always
>>>>>>>>> use the thread context class loader.=A0=A0Personally, I think i=
t's a bug
>>>>>>>>> in Tomcat, as
>>>>>>>>> it shouldn't matter what kind of class loader it is.=A0=A0All c=
lass
>>>>>>>>> loaders ought to
>>>>>>>>> be able to generate valid jar URLs.=A0=A0I encourage you to rep=
ort this
>>>>>>>>> to the Tomcat
>>>>>>>>> development team!
>>>>>>>>>
>>>>>>>>> At this point, there's no going back to the way XMLC 2.3.1 load=
ed
>>>>>>>>> URLs because of
>>>>>>>>> significant design changes.=A0=A0The point at which URLs are no=
w loaded
>>>>>>>>> provides no
>>>>>>>>> access to the XMLC class file and, therefore, no way to obtain =
the
>>>>>>>>> classloader
>>>>>>>>> that loaded the XMLC class file... that is, unless XMLC always =
uses
>>>>>>>>> the thread
>>>>>>>>> context classloader to load resources (more on that below).=A0=A0=
Anyway,
>>>>>>>>> here are the
>>>>>>>>> obvious fixes in my order of preference...
>>>>>>>>>
>>>>>>>>> 1.=A0=A0Always pass "Thread.currentThread().getContextClassLoad=
er()" to the
>>>>>>>>> XMLCDeferredParsingFactory constructor.=A0=A0This resolves all =
issues,
>>>>>>>>> end of story.
>>>>>>>>>
>>>>>>>>> 2.=A0=A0If #1 is not possible/desirable, then you can implement=
 your own
>>>>>>>>> custom
>>>>>>>>> document/resource loader, similar to what I attached to my last
>>>>>>>>> email (see the new
>>>>>>>>> version attached to this email); the only difference being the
>>>>>>>>> method to override
>>>>>>>>> now looks like...
>>>>>>>>>
>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0protected URL getPathURLFromClasspath(fi=
nal String
>>>>>>>>> candidatePath) {
>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return
>>>>>>>>> Thread.currentThread().getContextClassLoader().getResource(cand=
idatePath);=20
>>>>>>>>>
>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0}
>>>>>>>>>
>>>>>>>>> 3.=A0=A0Change XMLC's
>>>>>>>>> XMLCDeferredParsingFactory.getPathURLFromClasspath(String)
>>>>>>>>> method to use the thread context classloader.=A0=A0While this i=
s an
>>>>>>>>> option, it's not a
>>>>>>>>> very good one because the thread context class loader may not a=
lways
>>>>>>>>> be the right
>>>>>>>>> choice.=A0=A0While it generally is the right choice 99.99999% o=
f the
>>>>>>>>> time in a JEE
>>>>>>>>> environment, XMLC is not always used in a server environment.=A0=
=A0And
>>>>>>>>> there's always
>>>>>>>>> going to be that edge case where, even in a server environment =
it's
>>>>>>>>> not desirable.
>>>>>>>>>=A0=A0=A0=A0 And, of course, that's where option #1 really shine=
s.=A0=A0You get to
>>>>>>>>> choose which
>>>>>>>>> classloader to use so XMLC doesn't have to guess.
>>>>>>>>>
>>>>>>>>> 4.=A0=A0If you can think of a better idea, let me know.=A0=A0I'=
m highly
>>>>>>>>> resistant to #3.
>>>>>>>>> I realize the change in behavior is inconvenient (and most like=
ly a
>>>>>>>>> Tomcat bug
>>>>>>>>> anyway), but it's a simple change on the user's part and can be=
 done
>>>>>>>>> as part of
>>>>>>>>> the upgrade from 2.3.1 to 2.3.2.=A0=A0Besides, the design chang=
es that
>>>>>>>>> introduced this
>>>>>>>>> [easily-worked-around] situation make XMLC far more flexible in
>>>>>>>>> regard to resource
>>>>>>>>> loading than it was before.=A0=A0I think the benefits outweigh =
the costs.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>> Jake
>>>>>>>>>
>>>>>>>>> On 3/27/2011 3:56 PM, Sasa Bojanic wrote:
>>>>>>>>>> OK, as I said, I will try to look at our classloader. But I ca=
n
>>>>>>>>>> confirm
>>>>>>>>>> that the problem that occurs with XMLC 2.3-2 does NOT occur wi=
th XMLC
>>>>>>>>>> 2.3-1 under EXACTLY the SAME conditions.
>>>>>>>>>> As a sample, this time I used the simplest "calculator" applic=
ation
>>>>>>>>>> from
>>>>>>>>>> Enhydra Demos package. This sample uses only XMLC and Enhydra
>>>>>>>>>> Framework
>>>>>>>>>> classes (no database where we use our product DODS, and then J=
OTM and
>>>>>>>>>> other JTA support libraries).
>>>>>>>>>>
>>>>>>>>>> I deployed "calculator" application under pure Tomcat 6.0-29, =
JDK
>>>>>>>>>> 1.6.0_23 x64, Win7 x64.
>>>>>>>>>> It works normally. Then I first replaced xercesImpl, xml-apis =
and
>>>>>>>>>> nekohtml JAR files with the newer versions from XMLC 2.3-2. It=
 still
>>>>>>>>>> worked normally.
>>>>>>>>>> After I finally replaced xmlc.jar (2.3-1) with xmlc-all-runtim=
e.jar,
>>>>>>>>>> removed gnu-regexp.jar and introduced jregex.jar, I get the 1s=
t
>>>>>>>>>> described problem with not being able to find the resource fro=
m the
>>>>>>>>>> JAR
>>>>>>>>>> file:
>>>>>>>>>>
>>>>>>>>>> java.io.FileNotFoundException:
>>>>>>>>>> d:\apache-tomcat-6.0.29\webapps\calculator\WEB-INF\lib\calcula=
tor.jarcalculator\presentation\CalculatorHTML.xmlc=20
>>>>>>>>>>
>>>>>>>>>> (The system cannot find the path specified)
>>>>>>>>>>
>>>>>>>>>> You can download a set of Enhydra Demo applications (version 8=
.4-1)
>>>>>>>>>> for
>>>>>>>>>> pure Tomcat from:
>>>>>>>>>>
>>>>>>>>>> https://docs.google.com/leaf?id=3D0B9ZAe6ftekYJMGVmYjdmZDMtMjY=
5YS00MDU4LWIzNWEtYzhiMjBlMzZjYTZj&sort=3Dname&layout=3Dlist&pid=3D0B9ZAe6=
ftekYJNWQ0ZDRmNjMtN2M2MS00NDIyLWJmZmUtYWE0Y2Y4MDFiMDUw&cindex=3D18=20
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> (If necessary, you can find the source code of Enhydra Demos (=
TDA),
>>>>>>>>>> Enhydra Framework (TAF), Enhydra DODS (TRO) at:
>>>>>>>>>> https://docs.google.com/leaf?id=3D0B9ZAe6ftekYJNTc0OWM2NzctNzM=
3MS00YmNjLTkyMTctZjg0ZWUxZWI2YWQw&;hl=3Den=20
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> but to reproduce the problem, downloading the 1st link is enou=
gh)
>>>>>>>>>>
>>>>>>>>>> There are many applications based on XMLC included in the ZIP =
file
>>>>>>>>>> from
>>>>>>>>>> the 1st link above, ready to be deployed on pure Tomcat.
>>>>>>>>>> As the simplest one for testing you can take "calculator.war" =
I used
>>>>>>>>>> this time.
>>>>>>>>>>
>>>>>>>>>> After I provide a "patch/workaround" for this problem of findi=
ng
>>>>>>>>>> resource in the JAR file, the problem disappears.
>>>>>>>>>>
>>>>>>>>>> When I moved all the JAR files except the application JAR file
>>>>>>>>>> (calculator.jar) to the common/shared class-loader (Tomcat's l=
ib
>>>>>>>>>> folder), this time I do NOT have the 2nd problem I described..=
.so that
>>>>>>>>>> might be my mistake during previous tests. The 2nd problem als=
o
>>>>>>>>>> does NOT
>>>>>>>>>> appear with "discRack" application either. So I assume the
>>>>>>>>>> "patch/workaround" somehow solves all the problems.
>>>>>>>>>>
>>>>>>>>>> Since the ONLY difference with the deployment of this sample
>>>>>>>>>> XMLC/Enhydra Framework/DODS applications is the version of XML=
C,
>>>>>>>>>> can you
>>>>>>>>>> please look at that samples yourself, and confirm the issue.
>>>>>>>>>>
>>>>>>>>>> Greetings,
>>>>>>>>>> Sasa.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 26-Mar-11 20:14, Jacob Kjome wrote:
>>>>>>>>>>> The thing is, XMLC doesn't create the URL object that provide=
s the
>>>>>>>>>>> path to the
>>>>>>>>>>> resource; the classloader does.=A0=A0That goes for both XMLC =
2.3.1 and
>>>>>>>>>>> 2.3.2.=A0=A0I can't
>>>>>>>>>>> explain why behavior would be different for you between the t=
wo
>>>>>>>>>>> versions?=A0=A0Of
>>>>>>>>>>> course, I can't replicate your findings in the first place, s=
o I'm at
>>>>>>>>>>> a loss.
>>>>>>>>>>>
>>>>>>>>>>> One thing that is a red flag for me is the path you provided.=
..
>>>>>>>>>>>
>>>>>>>>>>> "d:\apache-tomcat-6.0.29\webapps\discRack\WEB-INF\lib\*discRa=
ck.jardiscRack*\presentation\ErrorHTML.xmlc"=20
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That isn't even a valid URL.=A0=A0There's no "file:/" and all=
 the
>>>>>>>>>>> slashes are
>>>>>>>>>>> backward.=A0=A0This looks to me like a custom classloader bug=
.=A0=A0Again,
>>>>>>>>>>> XMLC doesn't
>>>>>>>>>>> generate the URL, the classloader does.
>>>>>>>>>>>
>>>>>>>>>>> When you say that "it works under 2.3.1", are you sure you te=
sted
>>>>>>>>>>> 2.3.1 with the
>>>>>>>>>>> same version of the server you are using to test 2.3.2?=A0=A0=
That is,
>>>>>>>>>>> when
>>>>>>>>>>> you tested
>>>>>>>>>>> 2.3.1, was the server an older version than what you are usin=
g with
>>>>>>>>>>> 2.3.2?=A0=A0If so,
>>>>>>>>>>> please reduce the number of extraneous variables by testing w=
ith the
>>>>>>>>>>> older server
>>>>>>>>>>> version (the one known to work) and just switching out the 2.=
3.1
>>>>>>>>>>> libraries with
>>>>>>>>>>> the 2.3.2 libraries.=A0=A0Do you get better results?
>>>>>>>>>>>
>>>>>>>>>>> If you can send me a minimal webapp (able to run under Tomcat
>>>>>>>>>>> standalone) with
>>>>>>>>>>> explicit instructions on how to replicate the problem, then I=
'll test
>>>>>>>>>>> it myself
>>>>>>>>>>> and let you know the results.
>>>>>>>>>>>
>>>>>>>>>>> BTW, here's how XMLCContext loads up the deferred parsing fac=
tory...
>>>>>>>>>>>
>>>>>>>>>>> XMLCDeferredParsingFactory newFactory
>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=3D new XMLCDeferredParsin=
gFactory(loader,
>>>>>>>>>>> Thread.currentThread().getContextClassLoader(), logger);
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> First, notice that the classloader is set up as the thread co=
ntext
>>>>>>>>>>> class loader of
>>>>>>>>>>> the application.=A0=A0This is the reason why the XMLC Tomcat =
demo
>>>>>>>>>>> works no
>>>>>>>>>>> matter
>>>>>>>>>>> where the XMLC libraries are located in relation to the jar
>>>>>>>>>>> containing
>>>>>>>>>>> the
>>>>>>>>>>> templates.=A0=A0When templates are in the parent classloader,=
 the webapp
>>>>>>>>>>> (child)
>>>>>>>>>>> classloader can always see that, so they load just fine.=A0=A0=
And when
>>>>>>>>>>> the
>>>>>>>>>>> templates
>>>>>>>>>>> are in the webapp classloader while the XMLC libraries are in=
 the
>>>>>>>>>>> parent, XMLC can
>>>>>>>>>>> see down to the child classloader because it has a reference =
to
>>>>>>>>>>> the child
>>>>>>>>>>> classloader via the thread context classloader.
>>>>>>>>>>>
>>>>>>>>>>> Clearly the "(MultiClassLoader)
>>>>>>>>>>> presentationManager.getAppClassLoader()" doesn't
>>>>>>>>>>> have a reference to the thread context classloader, otherwise=
 you
>>>>>>>>>>> would not run
>>>>>>>>>>> into the issues you have of not finding the templates in cert=
ain
>>>>>>>>>>> situations.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Second, you can customize the loading of resources by using a=
 custom
>>>>>>>>>>> DocumentLoader/ResourceLoader combo.=A0=A0See the
>>>>>>>>>>> ValidatingDocumentLoader
>>>>>>>>>>> example in
>>>>>>>>>>> the Tomcat demo....
>>>>>>>>>>>
>>>>>>>>>>> http://websvn.ow2.org/filedetails.php?repname=3Dxmlc&path=3D%=
2Ftags%2FXMLC_2_3_2%2Fxmlc%2Fexamples%2Ftomcat%2Fsrc%2Fxmlc%2Fdemo%2FVali=
datingDocumentLoader.java=20
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This one extends ServletDocumentLoaderImpl, but if you don't =
care
>>>>>>>>>>> about loading
>>>>>>>>>>> resources from the servlet context, then you can just extend
>>>>>>>>>>> DocumentLoaderImpl.
>>>>>>>>>>> Attached is a sample you can use.=A0=A0Instead of using
>>>>>>>>>>> StandardDocumentLoader.getInstance() in the following...
>>>>>>>>>>>
>>>>>>>>>>> xmlcFactory =3D new
>>>>>>>>>>> XMLCDeferredParsingFactory(StandardDocumentLoader.getInstance=
(),
>>>>>>>>>>>
>>>>>>>>>>> (MultiClassLoader)presentationManager.getAppClassLoader(),
>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 new EnhydraXMLCLogger(logChannel));
>>>>>>>>>>>
>>>>>>>>>>> ...use...
>>>>>>>>>>>
>>>>>>>>>>> xmlcFactory =3D new XMLCDeferredParsingFactory(new
>>>>>>>>>>> CustomDocumentLoader(),
>>>>>>>>>>>
>>>>>>>>>>> (MultiClassLoader)presentationManager.getAppClassLoader(),
>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 new EnhydraXMLCLogger(logChannel));
>>>>>>>>>>>
>>>>>>>>>>> ...and if you want to be able to load resources no matter whe=
re they
>>>>>>>>>>> exist in the
>>>>>>>>>>> classloader hierarchy relative to where XMLC libraries exist =
in the
>>>>>>>>>>> hierarchy use...
>>>>>>>>>>>
>>>>>>>>>>> xmlcFactory =3D new XMLCDeferredParsingFactory(new
>>>>>>>>>>> CustomDocumentLoader(),
>>>>>>>>>>>
>>>>>>>>>>> Thread.currentThread().getContextClassLoader(),
>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0new EnhydraXMLCLogger(logChannel));
>>>>>>>>>>>
>>>>>>>>>>> With the custom document/resource loader, you can change the =
behavior
>>>>>>>>>>> of resource
>>>>>>>>>>> loading without modifying the internals of XMLC at all.=A0=A0=
This feature
>>>>>>>>>>> is new to
>>>>>>>>>>> XMLC-2.3.2.=A0=A0However, remember that besides the added plu=
gability
>>>>>>>>>>> provided by
>>>>>>>>>>> XMLC-2.3.2, ultimately, XMLC 2.3.1 and 2.3.2 don't do anythin=
g
>>>>>>>>>>> different to load
>>>>>>>>>>> resources from the classloader.=A0=A0They both use
>>>>>>>>>>> classLoader.getResource("some/path/to/resoruce.html").=A0=A0I=
f that
>>>>>>>>>>> provides a URL
>>>>>>>>>>> producing an invalid path, that's a bug in the classloader, n=
ot XMLC.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Jake
>>>>>>>>>>>
>>>>>>>>>>> On 3/25/2011 9:14 AM, Sasa Bojanic wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> yes, I'm of course also using 64-bit Java.
>>>>>>>>>>>>
>>>>>>>>>>>> I will check about our MultiClassLoader, but the point is EV=
ERYTHING
>>>>>>>>>>>> WORKS PERFECTLY with XMLC 2.3-1. We don't have a problem wit=
h
>>>>>>>>>>>> resource
>>>>>>>>>>>> lookup within the JAR file, and do not have a problem with s=
cenario
>>>>>>>>>>>> where XMLC is not in the application's classloader.
>>>>>>>>>>>>
>>>>>>>>>>>> We are trying to find the reason why we can't switch to XMLC=
 2.3-2
>>>>>>>>>>>> seamlessly...and since everything works with XMLC2.3-1 we th=
ink
>>>>>>>>>>>> it is a
>>>>>>>>>>>> XMLC issue?
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Sasa.
>>>>>>>>>>>>
>>>>>>>>>>>> On 25-Mar-11 16:03, Jacob Kjome wrote:
>>>>>>>>>>>>> In this particular case, XMLC can certainly find the file (=
as
>>>>>>>>>>>>> opposed
>>>>>>>>>>>>> to the other case where it can't when XMLC libs are in the
>>>>>>>>>>>>> server lib,
>>>>>>>>>>>>> at least on your system), but the path is messed up.=A0=A0B=
ut this is
>>>>>>>>>>>>> really not XMLC's fault.=A0=A0The classloader's getResource=
() method is
>>>>>>>>>>>>> returning an invalid path.=A0=A0Other than tweaking it with=
 your
>>>>>>>>>>>>> workaround, there's nothing XMLC can (nor should) do about =
that
>>>>>>>>>>>>> (though there is a way you can work around this without mes=
sing
>>>>>>>>>>>>> with
>>>>>>>>>>>>> XMLC's core, which I will send in a separate email later
>>>>>>>>>>>>> today).=A0=A0As I
>>>>>>>>>>>>> mentioned, it works perfectly well on my system.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You have, potentially, at least 3 platform differences.=A0=A0=
The
>>>>>>>>>>>>> first is
>>>>>>>>>>>>> Win7 x64, where I've only tested on WinXP x32.=A0=A0You may=
 also be
>>>>>>>>>>>>> using
>>>>>>>>>>>>> 64 bit Java, though you'd have to verify that.=A0=A0And you=
 are running
>>>>>>>>>>>>> under Enhydra, with some "MultiClassLoader" classloader
>>>>>>>>>>>>> implementation.=A0=A0Somewhere in these differences lies a =
bug that
>>>>>>>>>>>>> is not
>>>>>>>>>>>>> the fault of XMLC.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would start first with the "MultiClasLoader" and see whet=
her
>>>>>>>>>>>>> there
>>>>>>>>>>>>> is a bug in its getResource() method that returns URL's wit=
h
>>>>>>>>>>>>> invalid
>>>>>>>>>>>>> paths when resources are looked up in jar files.=A0=A0Secon=
d, I'd
>>>>>>>>>>>>> check if
>>>>>>>>>>>>> there's a bug in the JDK you are using (maybe the 64 bit ve=
rsion
>>>>>>>>>>>>> has a
>>>>>>>>>>>>> bug where the 32 bit version I use does not?).=A0=A0Third, =
I guess
>>>>>>>>>>>>> could
>>>>>>>>>>>>> be a bug in Win7, though I would think the Java platform wo=
uld be
>>>>>>>>>>>>> responsible for working around that given the supposed "pla=
tform
>>>>>>>>>>>>> independence" and all.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Expect another email describing a workaround you can use, w=
ithout
>>>>>>>>>>>>> messing with XMLC's core, a bit later when I have access to=
 my
>>>>>>>>>>>>> development machine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jake
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, 24 Mar 2011 22:41:23 +0100
>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0Sasa Bojanic<[email protected]>=A0=A0=A0=A0=
wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> from what I can see in Enhydra code, XMLCDeferredParsingFa=
ctory is
>>>>>>>>>>>>>> obtained by calling its constructor:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0xmlcFactory =3D new
>>>>>>>>>>>>>> XMLCDeferredParsingFactory(StandardDocumentLoader.getInsta=
nce(),=20
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (MultiClassLoader) presentationManager.getAppClassLoader()=
,
>>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 new
>>>>>>>>>>>>>> EnhydraXMLCLogger(logChannel));
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> First of all let me show you an error that occurs when XML=
C is
>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>> application classloader. The error is in the attached docu=
ment...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I use Tomcat 6.0.29, Java 1.6_23, Win7 x64, and all the JA=
Rs
>>>>>>>>>>>>>> you've
>>>>>>>>>>>>>> mentioned are in this case in the application's WEB-INF\li=
b
>>>>>>>>>>>>>> folder.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you notice, the XMLC is reporting to search for:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> d:\apache-tomcat-6.0.29\webapps\discRack\WEB-INF\lib\*disc=
Rack.jardiscRack*\presentation\ErrorHTML.xmlc=20
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When I "patch" XMLC as described before, this scenario wor=
ks well.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Sasa.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 21-Mar-11 00:34, Jacob Kjome wrote:
>>>>>>>>>>>>>>> Hi Sasa,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I finally made some time to look into the issues you repo=
rted.
>>>>>>>>>>>>>>> Interestingly, I'm
>>>>>>>>>>>>>>> not able to reproduce either issue.=A0=A0I used Tomcat-6.=
0.29
>>>>>>>>>>>>>>> standalone, as that's
>>>>>>>>>>>>>>> the version you used (note that I did not try Enhydra).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To test issue #1, I jar'ed up the classes and markup file=
s and
>>>>>>>>>>>>>>> made
>>>>>>>>>>>>>>> sure to rename
>>>>>>>>>>>>>>> the resource dirs so files located there could not be fou=
nd.
>>>>>>>>>>>>>>> I also
>>>>>>>>>>>>>>> renamed the
>>>>>>>>>>>>>>> WEB-INF/xmlc directory in the demo app to ensure template=
s
>>>>>>>>>>>>>>> could not
>>>>>>>>>>>>>>> be loaded via
>>>>>>>>>>>>>>> the servlet context (allowed for by the custom
>>>>>>>>>>>>>>> ValidatingDocumentLoader.ValidatingResourceLoader class u=
sed
>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>> xmlc tomcat
>>>>>>>>>>>>>>> demo), thus could only be loaded via the classloader.=A0=A0=
I
>>>>>>>>>>>>>>> placed the
>>>>>>>>>>>>>>> templates jar
>>>>>>>>>>>>>>> in WEB-INF/lib and ran tomcat.=A0=A0First I tried loading=
 the
>>>>>>>>>>>>>>> Welcome.html page
>>>>>>>>>>>>>>> (french locale, because that's what I had selected in the=
 tomcat
>>>>>>>>>>>>>>> demo), which came
>>>>>>>>>>>>>>> up fine.=A0=A0I took a look at the log to see how the fil=
e was
>>>>>>>>>>>>>>> loaded...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> INFO:>>>Parsing DOM for $$XMLC_GENERATED$$.xmlc.demo.Welc=
ome.html
>>>>>>>>>>>>>>> from source URL
>>>>>>>>>>>>>>> jar:file:/D:/dev/XMLC_FORGE_SVN/tags/XMLC_2_3_2/xmlc/exam=
ples/tomcat/build/webapps/xmlc/WEB-INF/lib/xmlc-templates.jar!/demo/Welco=
me_fr.html=20
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ...so, clearly it is being loaded via the classloader... =
and
>>>>>>>>>>>>>>> working
>>>>>>>>>>>>>>> fine for me.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To test issue #2, I copied the following jars into
>>>>>>>>>>>>>>> ${catalina.base}/shared...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> jregex.jar
>>>>>>>>>>>>>>> nekohtml.jar
>>>>>>>>>>>>>>> resolver.jar
>>>>>>>>>>>>>>> xercesImpl.jar
>>>>>>>>>>>>>>> xml-apis.jar
>>>>>>>>>>>>>>> xmlc-all-runtime.jar
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Note that the Tomcat demo has a modified
>>>>>>>>>>>>>>> ${catalina.base}/conf/catalina.properties, which places t=
he
>>>>>>>>>>>>>>> ${catalina.base}/shared directory, as well as contained j=
ars,
>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>> common
>>>>>>>>>>>>>>> loader.=A0=A0It looks like...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> common.loader=3D${catalina.base}/shared,${catalina.base}/=
shared/*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar,${cata=
lina.home}/lib,${catalina.home}/lib/*.jar=20
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This would be no different than putting the jars in
>>>>>>>>>>>>>>> ${catalina.home}/lib, but
>>>>>>>>>>>>>>> avoids having to muck with the contents of the stock Tomc=
at
>>>>>>>>>>>>>>> installation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Anyway, I left my jar file containing the XMLC classes an=
d
>>>>>>>>>>>>>>> templates in
>>>>>>>>>>>>>>> WEB-INF/lib.=A0=A0Again I tried loading the Welcome.html =
page and,
>>>>>>>>>>>>>>> again, it came up
>>>>>>>>>>>>>>> fine.=A0=A0I looked at the log and the INFO message was t=
he same as
>>>>>>>>>>>>>>> above.=A0=A0I then
>>>>>>>>>>>>>>> moved the templates jar file to the ${catalina.base}/shar=
ed
>>>>>>>>>>>>>>> directory and tried it
>>>>>>>>>>>>>>> again.=A0=A0The page came up fine and the INFO message lo=
oked like...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> INFO:>>>Parsing DOM for $$XMLC_GENERATED$$.xmlc.demo.Welc=
ome.html
>>>>>>>>>>>>>>> from source URL
>>>>>>>>>>>>>>> jar:file:/D:/dev/XMLC_FORGE_SVN/tags/XMLC_2_3_2/xmlc/exam=
ples/tomcat/build/shared/xmlc-templates.jar!/demo/Welcome_fr.html=20
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not sure what to tell you?=A0=A0It all works fine for=
 me.=A0=A0Note
>>>>>>>>>>>>>>> that my
>>>>>>>>>>>>>>> environment consists of...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Windows XP sp3
>>>>>>>>>>>>>>> Java 1.6.0_24
>>>>>>>>>>>>>>> Tomcat-6.0.29 (standalone run from the command line)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Note that I use XMLCContext to obtain the
>>>>>>>>>>>>>>> XMLCDeferredParsingFactory.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> At this point, I can only say that it works for me.=A0=A0=
Maybe the
>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>> platform
>>>>>>>>>>>>>>> differences that are causing issues?=A0=A0What OS and ver=
sion of
>>>>>>>>>>>>>>> Java do
>>>>>>>>>>>>>>> you use?
>>>>>>>>>>>>>>> What does the original "jar:" URL look like when you run =
it
>>>>>>>>>>>>>>> (prior
>>>>>>>>>>>>>>> to having to
>>>>>>>>>>>>>>> muck with it to get it to work in your environment)?=A0=A0=
And
>>>>>>>>>>>>>>> please let
>>>>>>>>>>>>>>> me know how
>>>>>>>>>>>>>>> you obtain the XMLCDeferredParsingFactory.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jake
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 3/7/2011 1:46 PM, Sasa Bojanic wrote:
>>>>>>>>>>>>>>>> Well, it is not really a patch, but something that made =
my
>>>>>>>>>>>>>>>> use case
>>>>>>>>>>>>>>>> one
>>>>>>>>>>>>>>>> working...I agree nowdays it would be reasonable to move=
 XMLC to
>>>>>>>>>>>>>>>> JDK1.5
>>>>>>>>>>>>>>>> or even 1.6...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks a lot for the quick response!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sasa.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 07-Mar-11 17:13, Jacob Kjome wrote:
>>>>>>>>>>>>>>>>> I can look into using your patch for #1 (or something l=
ike
>>>>>>>>>>>>>>>>> it) for
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> next XML release.=A0=A0I think the primary issue here i=
s that we've
>>>>>>>>>>>>>>>>> maintained a dependency on JDK1.3, which does not have
>>>>>>>>>>>>>>>>> java.net.URI.
>>>>>>>>>>>>>>>>> I've tried to maintain this minimum dependency as long =
as
>>>>>>>>>>>>>>>>> Xerces
>>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>>> so.=A0=A0Plus it makes for easy testing because JDK1.3 =
doesn't add
>>>>>>>>>>>>>>>>> any of
>>>>>>>>>>>>>>>>> its own XML libraries.=A0=A0It's easy to dictate the ve=
rsion
>>>>>>>>>>>>>>>>> without
>>>>>>>>>>>>>>>>> getting buggy JDK1.4 XML behavior.=A0=A0But I think mos=
t of the
>>>>>>>>>>>>>>>>> world has
>>>>>>>>>>>>>>>>> moved on to JDK1.5+, so maybe XMLC should too at some p=
oint?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'll have to test #2.=A0=A0Not sure how quickly I'll be=
 able to
>>>>>>>>>>>>>>>>> get to
>>>>>>>>>>>>>>>>> this, though.=A0=A0But I'll try and spend some time thi=
s week on
>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jake
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, 07 Mar 2011 13:56:15 +0100
>>>>>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0Sasa Bojanic<[email protected]>=A0=
=A0=A0=A0 wrote:
>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm trying to upgrade our applications that use XMLC 2=
.3.1
>>>>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>>>>> newest XMLC version.
>>>>>>>>>>>>>>>>>> Our applications are deployed both under the Tomcat 6.=
0.29
>>>>>>>>>>>>>>>>>> application server and Enhydra application server (bas=
ed on
>>>>>>>>>>>>>>>>>> Tomcat
>>>>>>>>>>>>>>>>>> 6.0.29).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> There are two issues I faced:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1) when deploying under the Tomcat, XMLC JAR files are=
 placed
>>>>>>>>>>>>>>>>>> together with the application JAR files into applicati=
on's
>>>>>>>>>>>>>>>>>> WEB-INF\lib folder (so application classloader is used=
 to load
>>>>>>>>>>>>>>>>>> them).
>>>>>>>>>>>>>>>>>> In this case, XMLC can't load resources (*.html and *.=
xmlc
>>>>>>>>>>>>>>>>>> files)
>>>>>>>>>>>>>>>>>> from JAR file. When resources are not in the JAR file =
but
>>>>>>>>>>>>>>>>>> unpacked
>>>>>>>>>>>>>>>>>> into WEB-INF\classes folder everything works.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> After "patching" the method getPathURLFromClasspath() =
from
>>>>>>>>>>>>>>>>>> XMLCDeferredParsingFactory to add:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0if (srcURL !=3D=
 null&&
>>>>>>>>>>>>>>>>>> srcURL.toString().indexOf(".jar")>=3D 0) {
>>>>>>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0try {
>>>>>>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 String mdurl =3D srcURL.toString();
>>>>>>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 srcURL =3D new URL("jar:"
>>>>>>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0+ mdurl.su=
bstring(0,
>>>>>>>>>>>>>>>>>> mdurl.indexOf(".jar")) + ".jar!/"
>>>>>>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0+
>>>>>>>>>>>>>>>>>> mdurl.substring(mdurl.indexOf(".jar") + 4));
>>>>>>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0} catch (Exception ex) {
>>>>>>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 }
>>>>>>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0}
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> after the line:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0URL srcURL =3D
>>>>>>>>>>>>>>>>>> fDynamicClassLoader.getResource(path);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> it works fine.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2) when deploying under Enhydra application server or =
under
>>>>>>>>>>>>>>>>>> Tomcat,
>>>>>>>>>>>>>>>>>> but instead of putting XMLC JAR files into application=
's
>>>>>>>>>>>>>>>>>> WEB-INF\lib,
>>>>>>>>>>>>>>>>>> we put it into Tomcat's lib folder, XMLC can't find
>>>>>>>>>>>>>>>>>> resources no
>>>>>>>>>>>>>>>>>> matter if resources are inside JAR file or unpacked, a=
nd it
>>>>>>>>>>>>>>>>>> can't
>>>>>>>>>>>>>>>>>> find it even in the case I put application's JAR file =
into
>>>>>>>>>>>>>>>>>> Tomcat's
>>>>>>>>>>>>>>>>>> lib folder.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Is it a bug in XMLC? Can somebody help?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>> Sasa.
>>>>>>>>>>>>>>>>>>
>>>
>>
>=20


------------=_1301408735-30467-16157
Content-Type: text/plain; charset="UTF-8"; name="message-footer.txt"
Content-Disposition: inline; filename="message-footer.txt"
Content-Transfer-Encoding: quoted-printable


--
You receive this message as a subscriber of the [email protected] mailing list=
.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=3Dhelp
OW2 mailing lists service home page: http://www.ow2.org/wws

------------=_1301408735-30467-16157--