Yes I expect that whatever is parsing that tiles-defs.xml file is doing the accidental locking here. It will have an internal hard-wired list of (dtd public id) -> (dtd file name within jar) internally. When it sees your *reference* to a dtd in the xml file, it then goes and finds the actual dtd internally and uses it. And the jdk then caches the reference, therefore locking the jar.
If your input file never says "I use this dtd" then it won't bother to try to find that dtd internally inside its jar. This is only guessing, but it seems reasonable. I would think that removing the problem dtd from the jarfile would also fix it (either that, or cause a crash:-). Maybe you didn't find the right jar yet? Note that removing the dtd from the jar *might* cause the app to instead try to download the dtd from the internet..watch out for that. Cheers, Simon On Tue, 2008-07-15 at 10:24 -0600, Michael Heinen wrote: > Thanks Simon. > I read s.th. similar also but this is still really strange to me ... > > I could understand this if a DTD is referenced *inside* struts.jar. > But "http://jakarta.apache.org/struts/dtds/tiles-config_1_1.dtd"; is a > public dtd somewhere outside. > How can caching this file result in locking struts.jar? > Or do you think that some struts/tiles code holds a reference to the DTD > also? > > I removed also all dtds from struts.jar without success. > > Michael > > -----Original Message----- > From: simon [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 15. Juli 2008 17:59 > To: MyFaces Discussion > Subject: RE: unbdeploy WepApp - struts.jar locked > > > On Tue, 2008-07-15 at 09:37 -0600, Michael Heinen wrote: > > After spending many hours with this I found a solution that I do not > > understand. > > > > I removed following doctype definition from tiles-defs.xml > > > > > > > > <!DOCTYPE tiles-definitions PUBLIC > > > > "-//Apache Software Foundation//DTD Tiles Configuration > > 1.1//EN" > > > > "http://jakarta.apache.org/struts/dtds/tiles-config_1_1.dtd";> > > > > > > > > Why does this result in locking struts.jar ? > > This does make sense. > > The usual cause of this "locking" problem is some stupid code inside the > sun jdk. When URL.openAsStream (or some such method, I forget the exact > details) is used to load a resource, then the sun jdk caches a reference > to that resource in order to optimise future accesses to it. > > But that means that on Windows the file is "open" so cannot be removed. > > The fix really should be in the jdk, but it isn't going to happen. > Instead, the workaround is for all libraries to go around explicitly > disabling caching wherever this is used. And I would guess that *if* an > xml file has a local dtd declared then something is loading that via the > above method, in order to validate the dtd or to detect implicit > attributes etc. > > I think there is an issue in the JIRA somewhere to fix the problem in > myfaces code. But of course it needs to be fixed in every lib too. > > Or move to a decent operating system :-). > > Please note: above details are only from memory. Exact classes, methods, > etc can be wrong. > > Regards, > Simon > > > > >
