Re: [POLL]: Dropping JDK 1.3 support for Xerces-J?
+1 for dropping support for 1.3 1.5 has a better memory model but as far as I know, this is part of the JVM, rather than depending on the compiler, i.e. merely running under 1.5 will help (please correct me if I'm wrong!). Switching to 1.5 involves a lot of work initially (generics, annotations) before one can take full advantage of all its benefits. So I would be inclined to do at least one release which requires 1.4, and then look again at 1.5. On 8 July 2010 19:27, Dave Brosius wrote: > the end of life on 1.4 was fall 2008! > > +1 in going to 1.5 directly > > Michael Glavassevich wrote: > >> >>Hi Jake, >> >>"Jacob Kjome" wrote on 07/08/2010 12:58:49 PM: >> >>> I have a library I develop (XMLC [1]) that depends on JDK1.3 and also >>depends >>> on Xerces. That said, part of the reason of depending on JDK1.3 is >>> to stay in >>> line with the Xerces dependency on JDK1.3. The other reason is >>thatJDK1.3 is >>> free and clear of any built-in XML APIs, which allows me to include >>exactly >>> the JAXP library of my choice (xml-apis.jar) without worry of >>compile-time >>> binding to odd invalid APIs included in 1.4 (such as some stuff meant for >>the >>> HTML2 API that got placed in the HTML1 API DOM package namespace). But >>if >>> Xerces decides to move to a later version of Java, then I will probably >>move >>> XMLC right along with it. >>> >>> That said, I would think that if Xerces were going to bother making a >>move at >>> all it would move to JDK1.5 rather than bother with 1.4. Xerces 2.10 is >>> always there for 1.3 and 1.4 codebases, which should all be well into >>> maintenance mode meaning few, if any, library changes. >> >>It's often not a choice but a constraint of the environment the developer >>is working in, having to write a new application on top of a product stack >>which is stuck on one of these earlier JDK releases. JDK 1.4 isn't dead >>yet; still in service for some vendors, including Oracle/Sun if you're a >>business willing to pay for the support. Not aware of any vendors >>supporting JDK 1.3 anymore though. >> >>> Moving to 1.5 would >>> allow Xerces to take advantage of all the new language constructs added >>in >>> 1.5, as well as APIs added in 1.5 (e.g., StringBuilder -vs- >>StringBuffer). >> >>Right. We all talked about the benefits of moving up even higher to Java 5 >>and 6 before, but have been quite conservative about upgrading because of >>where we are in the food chain. >> >>> So, +1 for changing JDK dependency in general, but I would prefer a move >>> straight to JDK1.5+ skipping JDK1.4 support. This also seems to be >>> what a lot >>> of Apache commons libraries are doing, so it's certainly not >>unprecedented. >>> >>> [1] http://forge.ow2.org/projects/xmlc/ >>> >>> >>> Jake >>> >>> On Thu, 8 Jul 2010 11:36:07 -0400 >>> Michael Glavassevich wrote: >>> > >>> > >>> > Hi all, >>> > >>> > (including gene...@xml.apache.org on the cc list to hopefully reach a >>wider >>> > audience) >>> > >>> > We're talking again on the Xerces j-dev mailing list about dropping >>support >>> > for JDK 1.3. The reason being that current builds of the XPath 2.0 >>> > processor (Eclipse PsychoPath) used by the XML Schema 1.1 >>implementation >>> > require JDK 1.4. While we do have a one-off PsychoPath jar that was >>built >>> > with JDK 1.3 some time ago, in order to pick up recent bug fixes in >>this >>> > library we need to refresh it with the JDK 1.4 version. This would only >>> > impact the XML Schema 1.1 enabled release for now but at some point in >>the >>> > future when XML Schema 1.1 becomes stable (both spec and impl) this >>would >>> > get merged into the main line. >>> > >>> > Given the age of JDK 1.3 and that it's generally out of service my >>> > intuition is that this upgrade would probably be okay but wanted to >>check >>> > with users on their needs. Is there anyone out there still using >>Xerces-J >>> > with JDK 1.3? If you are, how long into the future will you continue to >>do >>> > so, and would you be willing to migrate to JDK 1.4 (or higher) to be >>able >>> > to use XML Schema 1.1? >>> > >>> > Thanks. >>> > >>> > Michael Glavassevich >>> > XML Parser Development >>> > IBM Toronto Lab >>> > E-mail: mrgla...@ca.ibm.com >>> > E-mail: mrgla...@apache.org >>> >>> >>> - >>> To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org >>> For additional commands, e-mail: j-users-h...@xerces.apache.org >> >>Thanks. >> >>Michael Glavassevich >>XML Parser Development >>IBM Toronto Lab >>E-mail: mrgla...@ca.ibm.com >>E-mail: mrgla...@apache.org - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: DOM thread safety issues & disapearring children
On 9 June 2011 17:51, Newman, John W wrote: > Thanks Michael. That’s the response I’ve been waiting for. This whole > situation is really unfortunate, since it’s not even my code that is missing > the required locking, and the developers of that faulting code have pretty > decent justification for refusing to add it. I’ll try to push back on them > a little more for adding an extension since this the xerces dom is really > the default. I am not the only one affected by this, anyone using the dom > package in that library without swapping the default implementation will run > into this. It’s just so rare and such a lucky situation that I’m probably > the first to notice it. > > > > There’s really nothing I can do besides some sort of wrapper or proxy > solution, a massive document pool, OR a larger re-architecting effort <- . > Maybe I can come up with something clean and quick, but without a thread > dump at the instant when this situation occurs, I can’t get it under test, > and can’t come up with the fix… > > I guess my question is, if there’s a simple answer to this, what specific > methods of your library can cause volatility? Is it just NodeList.length() > and NodeList.item(), any specific others, or ALL of them? Those two are > always the ones I’ve already ran into and have syncs around where my code is > using them, it wasn’t too hard to get some NPEs without the syncs. But > without them I never noticed corrupt documents. Even if writes are only performed by a single thread, it is still possible for a separate read-only thread to see inconsistent data. This is a consequence of the Java Memory Model, which allows threads to cache data for performance reasons. In the absence of the correct synch., the values written in one thread may never be seen by another thread, or may be seen in a different order. Both the writer and reader threads need to synchronise on the *same* lock to ensure that the updated data is published correctly. [There are some other ways of doing this, e.g. volatile variables] This visibility issue is entirely separate from the issues that can be caused by failing to lock the whole transaction. Passing mutable data between threads needs to be handled very carefully to ensure the data is safely published. [A very good book on the subject is Java Concurrency in Practice by Goetz, Peierls, Bloch and others] - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: [REVISED VOTE]: Xerces-J 2.12.0 release
On 21 April 2018 at 06:27, Mukul Gandhi wrote: > Hi all, >The 1st voting for Xerces-J 2.12.0 release was stopped, due to certain > issues that were in the release candidates (RC) that were found by the > reviewers ([5]). Those have been fixed now, and I'm initiating this new mail > for the Vote for new RC. > > I've uploaded Xerces-J 2.12.0 release candidates (the revised one) to [1] > for review. In this release candidate there are two sets of packages, the > main release built from the trunk [2] and the XML Schema 1.1 release built > from the XML Schema 1.1 development branch [3]. The change summary is > available here [4] in JIRA. 81 issues (plus issues that were mentioned, > during the review of 1st RC) were resolved. > > Test results have been looking good, so I'd like to call an official vote > now on the release. > > To start, here's my +1. > > Great work everyone. > > [1] https://dist.apache.org/repos/dist/dev/xerces/j/2.12.0/ Contains MD5 hashes; these are deprecated and should be removed. Also the revision is needed for traceability; currently it is Last Changed Rev: 26447 > [2] http://svn.apache.org/viewvc/xerces/java/tags/Xerces-J_2_12_0/ > Directory revision: 1829687 (of 1829689) > > [3] > http://svn.apache.org/viewvc/xerces/java/tags/Xerces-J_2_12_0-xml-schema-1.1/ > Directory revision: 1829688 (of 1829689) > > [4] > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10520&version=12336542 > > [5] https://markmail.org/message/54obpdyqrn6nfzgi : discussion about > previous RC, suggesting a revote. > > > > > -- > Regards, > Mukul Gandhi - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: [REVISED VOTE]: Xerces-J 2.12.0 release
On 23 April 2018 at 11:04, Mukul Gandhi wrote: > On Sun, Apr 22, 2018 at 3:19 PM, sebb wrote: > >> Contains MD5 hashes; these are deprecated and should be removed. > > > I alone can't decide on this (though I sort of agree with you). Lets see how > others react to the topic of having or not having MD5 hashes, and we can > accordingly finalize as this voting concludes. The ASF policy was updated recently, as notified to the PMC at the beginning of March: https://lists.apache.org/thread.html/d11f3dbcfe844b4d1eb06ba09c9f533bfbbc1f0a1a808185984832f6@%3Cprivate.xerces.apache.org%3E >> >> >> Also the revision is needed for traceability; currently it is >> >> Last Changed Rev: 26447 > > > If we look at this page, > https://dist.apache.org/repos/dist/dev/xerces/j/2.12.0/ it says on top, > "dist - Revision 26466: /dev/xerces/j/2.12.0" > > Are you talking about the revision number I've marked in bold emphasis? Do > you require mentioning this revision number in voting mails (along side the > link, https://dist.apache.org/repos/dist/dev/xerces/j/2.12.0/) ? Yes, it needs to be in the email so one can trace the provenance later if necessary. This is particularly true of /dist/dev/ URLs as those are generally moved / deleted after use. And indeed re-used, as here. > > > > -- > Regards, > Mukul Gandhi - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Maven release (was: [ANNOUNCEMENT]: Apache Xerces-J 2.12.0 now available)
I suggest that those who wish to see deployment of the release artifacts to Maven Central provide a script (plus docs) to do so. Note that the project uses Ant to build Xerces. Also Apache uses Nexus to stage and release Maven artefacts. Any solution should not require the project to change the way it builds currently. It should be an optional add-on. On 11 May 2018 at 21:54, Jim Manico wrote: > Maven is a pretty standard way of deploying 3rd party libraries in the Java > ecosystem. Supporting it is a no-brainer. It's fundamental for modern > development. > > - Jim > > > On 5/11/18 10:52 AM, Eric J. Schwarzenbach wrote: > > How do you figure I missed your point? I simply added to Mukul Gandhi's list > of ways of getting maven artifacts with another way (or I suppose an > elaboration of his #2). > > On 05/10/2018 05:53 PM, dbrosIus wrote: > > You missed the point. If I publish an artifact to maven when my artifact > depends on xerces, my users will come at me with pitch forks. > > Original message > From: "Eric J. Schwarzenbach" > Date: 5/10/18 5:28 PM (GMT-05:00) > To: j-users@xerces.apache.org > Subject: Re: [ANNOUNCEMENT]: Apache Xerces-J 2.12.0 now available > > > On 05/10/2018 02:39 AM, Mukul Gandhi wrote: > > Hi Dave, > > On Thu, May 10, 2018 at 11:23 AM, Dave Brosius > wrote: >> >> Yes, but if i want to publish an artifact to maven, and my artifact >> depends on xerces, are you expecting all the users of my artifact to do the >> same? And if someone else creates an artifact based on my artifact, etc, >> etc.? > > As far as I know, Maven provides following ways to fetch build > dependencies: > > 1) Get dependencies from a global Maven repository. This requires a > connection to internet. Some environments prohibit an internet connection. > Also on slow internet connections, getting tons of artifacts from the global > Maven repository during the build may be difficult. > 2) Get dependencies from a Maven repository on an Intranet server. > 3) Get dependencies from a Maven repository on the local host. > > You & people in favor of your point seems to say that 1) above is the > best/only method. But clearly, 2) is also another method. Of course, 3) > above is also yet another method for fetching Maven dependencies. > > Your company can also run its own maven repo server (such as Nexus), that > can hold both your company's internal maven artifacts and proxy to external > maven repos like maven central. Then when you need a 3rd party artifact that > is not in maven central, you can simply load it once to this repo and none > of your developers need to do anything. > > > > -- > Jim Manico > Manicode Security > https://www.manicode.com - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: Maven release (was: [ANNOUNCEMENT]: Apache Xerces-J 2.12.0 now available)
OK, so how does the Xerces project incorporate that into their release procedures? For example, exactly how would they use it to publish the latest release to Maven? S. On 15 May 2018 at 01:43, Dave Brosius wrote: > Here is an ant based project that produces a maven bundle.jar suitable for > upload to sonatype. > > https://github.com/mebigfatguy/fb-contrib/blob/spotbugs/build.xml > > > > On 05/14/2018 05:03 AM, sebb wrote: >> >> I suggest that those who wish to see deployment of the release >> artifacts to Maven Central provide a script (plus docs) to do so. >> >> Note that the project uses Ant to build Xerces. >> >> Also Apache uses Nexus to stage and release Maven artefacts. >> >> Any solution should not require the project to change the way it >> builds currently. >> It should be an optional add-on. >> >> On 11 May 2018 at 21:54, Jim Manico wrote: >>> >>> Maven is a pretty standard way of deploying 3rd party libraries in the >>> Java >>> ecosystem. Supporting it is a no-brainer. It's fundamental for modern >>> development. >>> >>> - Jim >>> >>> >>> On 5/11/18 10:52 AM, Eric J. Schwarzenbach wrote: >>> >>> How do you figure I missed your point? I simply added to Mukul Gandhi's >>> list >>> of ways of getting maven artifacts with another way (or I suppose an >>> elaboration of his #2). >>> >>> On 05/10/2018 05:53 PM, dbrosIus wrote: >>> >>> You missed the point. If I publish an artifact to maven when my artifact >>> depends on xerces, my users will come at me with pitch forks. >>> >>> Original message >>> From: "Eric J. Schwarzenbach" >>> Date: 5/10/18 5:28 PM (GMT-05:00) >>> To: j-users@xerces.apache.org >>> Subject: Re: [ANNOUNCEMENT]: Apache Xerces-J 2.12.0 now available >>> >>> >>> On 05/10/2018 02:39 AM, Mukul Gandhi wrote: >>> >>> Hi Dave, >>> >>> On Thu, May 10, 2018 at 11:23 AM, Dave Brosius >>> wrote: >>>> >>>> Yes, but if i want to publish an artifact to maven, and my artifact >>>> depends on xerces, are you expecting all the users of my artifact to do >>>> the >>>> same? And if someone else creates an artifact based on my artifact, etc, >>>> etc.? >>> >>> As far as I know, Maven provides following ways to fetch build >>> dependencies: >>> >>> 1) Get dependencies from a global Maven repository. This requires a >>> connection to internet. Some environments prohibit an internet >>> connection. >>> Also on slow internet connections, getting tons of artifacts from the >>> global >>> Maven repository during the build may be difficult. >>> 2) Get dependencies from a Maven repository on an Intranet server. >>> 3) Get dependencies from a Maven repository on the local host. >>> >>> You & people in favor of your point seems to say that 1) above is the >>> best/only method. But clearly, 2) is also another method. Of course, 3) >>> above is also yet another method for fetching Maven dependencies. >>> >>> Your company can also run its own maven repo server (such as Nexus), that >>> can hold both your company's internal maven artifacts and proxy to >>> external >>> maven repos like maven central. Then when you need a 3rd party artifact >>> that >>> is not in maven central, you can simply load it once to this repo and >>> none >>> of your developers need to do anything. >>> >>> >>> >>> -- >>> Jim Manico >>> Manicode Security >>> https://www.manicode.com >> >> - >> To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org >> For additional commands, e-mail: j-users-h...@xerces.apache.org >> >> > > > - > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org > - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: Parsing a file inside a zip file locking zip file on windows
IIRC when Windows opens files for read (or write) it locks them
against deletion.
You need to ensure that you close the file before you try to delete it.
On 16 July 2018 at 21:37, Bernd Eckenfels wrote:
> Matt,
>
> I think this is a general problem of the JarURLConnection, especially if in
> caching mode. I think if you do some of the steps to open a stream yourself
> you can influence that better. I might be able to dig up a more detailed
> example later if you still need it. (It might not be a good idea to rely on
> the static setUseCache(false) method)
>
> You only see that on Windows because the other OS allows you to delete open
> files (however the file handle will linger around on those OS, too)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
>
> Von: Matthew Harrison
> Gesendet: Montag, Juli 16, 2018 9:56 PM
> An: j-users@xerces.apache.org
> Betreff: Parsing a file inside a zip file locking zip file on windows
>
>
> I've hit a bit of an odd case, that I'm hoping someone can tell me what I'm
> doing wrong, or how to fix it.
> As part of a transform (using Saxon), we're processing files that are inside
> a zip file. To access the files we're using a 'jar' URI, however after
> accessing/parsing the file it seems to be locked, and so cannot be deleted
> until the java program terminates.
> I believe I've created a reproducing case:
>
> import java.io.File;
> import java.io.IOException;
> import java.net.URISyntaxException;
>
> import javax.xml.parsers.DocumentBuilder;
> import javax.xml.parsers.DocumentBuilderFactory;
> import javax.xml.parsers.ParserConfigurationException;
>
> import org.w3c.dom.Document;
> import org.xml.sax.SAXException;
>
> import com.google.common.io.Files;
>
> public class CleanupInvestigation {
> public static void main(String[] args)
> throws IOException, SAXException, ParserConfigurationException,
> URISyntaxException, InterruptedException {
> File input = new File("src/test/resources/books.zip");
> File inputCopy = new File("src/test/resources/booksCopy.zip");
> Files.copy(input, inputCopy);
>
> DocumentBuilder builder =
> DocumentBuilderFactory.newInstance().newDocumentBuilder();
> Document doc =
> builder.parse("jar:file:src/test/resources/booksCopy.zip!/app.xml");
>
> System.out.println(doc.getLastChild().getNodeName());
> System.out.println("File delete (booksCopy.zip): " + inputCopy.delete());
> System.out.println("complete");
> }
> }
>
>
> I'm running this using Xerces 2.12.0 running on a Windows 10 machine,
> talking with the Saxon guys its looks like it works ok on a Mac (i.e. the
> booksCopy.zip file can be deleted).
>
> If anyone has any ideas on what the issue might be that would be great.
>
> Thanks,
>
> Matt
>
-
To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org
For additional commands, e-mail: j-users-h...@xerces.apache.org
