Re: [transaction 2.0] stripping to its very core
Oliver Zeigermann oliver at zeigermann.de writes: I am proposing to strip Commons Transaction to its very core. Deleted: - no more XA classes: We really can not an implement an XA resource with the existing implementation Hi Oliver, reducing ctx to a core is a good idea. I only would not like to see the XA stuff been dropped completely. I think it's quite important for getting ctx sold. I have a second project in maven 2 sense in mind as commons jci does: http://marc.info/?l=jakarta-commons-devm=117571327222719w=4. So we would have commons-transaction.jar and a commons-transaction-xa.jar. WDYT? Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
Rahul Akolkar rahul.akolkar at gmail.com writes: We still do: http://jakarta.apache.org/commons/releases/versioning.html Regarding deprecation: It is considered a fully compatible change. So you can actually deprecate at any point and don't need to postpone it a next release of a particular type. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
Jochen Wiedmann jochen.wiedmann at gmail.com writes: The problem is simply that votes for releases on commons drive me sick. It is not the exception, but the standard, that people demand changes (which they of course assume that the RM will do) and use a -1 to enforce their opinion. I have a different opinion in this matter. I see absolutely no problem with a compiler warning as long as I may drop in the binary to a running system: *That* is what I call binary compatible and what assume to be the contract for binary releases. Amen. Especially since the official versioning guidelines [1] consider deprecation as a fully compatible change while a point release only requires interface compatibility. What's actually the reasoning to demand a minor release because of a deprecation? Joerg [1] http://jakarta.apache.org/commons/releases/versioning.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TRANSACTIONS-16
Dennis Thrysøe dth at conscius.com writes: I am unsure how resource enlistment to the TransactionManager should work, as mentioned in a comment in jira. For now the collections enlist themselves, when created. What's the best way to go about this? I guess there must be some j2ee-mandated way of enlisting a resource? Just answering that one at the moment: http://jroller.com/page/pyrasun?entry=xa_exposed Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
Phil Steitz phil.steitz at gmail.com writes: a) no source, binary or semantic incompatibilities or deprecations introduced in a x.y.z release I really wonder what's the problem with deprecations since they don't have any influence on compatibility. I'd guess there is always a reason for deprecating something. Not doing so despite that reason is most careless IMO since you encourage users to use that commons' code despite knowing better that it is a bad choice regarding future compatibility of the user's code. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r520602 - in /jakarta/commons/proper/transaction/trunk: ./ lib/
Niall Pemberton niall.pemberton at gmail.com writes: Can't remember if I did or not - anyway I've added a download target to the ant build http://svn.apache.org/viewvc?view=revrevision=521856 Hi Niall, missed that one completely up to now. Thanks very much. I'm going to drop the jars from SVN now. Regards, Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] jci out of sandbox
Torsten Curdt tcurdt at apache.org writes: As already announced I would like to move http://jakarta.apache.org/commons/sandbox/jci/ out of the sandbox so I can then prepare a first RC. Please cast your votes for the graduation! Despite the result already posted: +1 Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] administration interface
Oliver Zeigermann oliver.zeigermann at gmail.com writes: This code is to allow calling certain manager methods simply by accessing a certain path. It lacks a flexible configuration using a mapping from suffix to method to be called, though. Hi Oliver, to be honest this way of handling it frightens me a bit. On the one hand it adds yet another concern and much code to the FileResourceManager, on the other hand this choose an unlikely resource path as virtual admin path sounds a bit hacky. Wouldn't it be better to externalize this feature? From what I see on a quick look it should be easily possible to write a VirtualAdminCommandsFileResourceManager wrapping the actual FileResourceManager and delegating all calls to it after having filtered out the admin commands only relevant for itself. Another option I'd consider would be something like JMX - though I have never used it and don't know actually if it is appropriate. Regards Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] Commons Transaction 1.2 Released
Oliver Zeigermann ozeigermann at apache.org writes: Jakarta Commons Transaction 1.2 has been released. Finally :) Oliver (on behalf of the Jakarta community) Thanks, Oliver. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] administration interface
Oliver Zeigermann oliver.zeigermann at gmail.com writes: I will modify the code in the 1.x branch ASAP. That was fast :) Would you please add the JMX approach to the 2.0 Wiki page as a cool idea? Added. Regards Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r520602 - in /jakarta/commons/proper/transaction/trunk: ./ lib/
Author: joerg Date: Tue Mar 20 14:15:48 2007 New Revision: 520602 URL: http://svn.apache.org/viewvc?view=revrev=520602 Log: replace the geronimo spec jars compiled by me at least with the now officially released ones (this is only a temporary solution as long as we don't have an Ant build fetching the jars itself) Somebody offered some time ago to help with converting the Ant build fetching the jars itself or even did it on another Jakarta Commons project. Is he or she still willing to help? ;) What's the best way to do it in Ant? Regards Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Transaction 1.2
Niall Pemberton niall.pemberton at gmail.com writes: That can be changed with the next release (1.3 or 1.2.1) when the jars can be retrieved over the standard Maven repository. +1 I'd like to see the release without any further delays. I'll address the Jar issue as fast as possible, but waiting with the release for it will cause another delay of probably a few weeks. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Towards a Commons Transaction 1.2 release
David Blevins david.blevins at visi.com writes: Anyway, I've applied your changes, built and verified each of them work with JDK 1.3, and put them all up for a vote on geronimo dev. I'm not sure what the status of your efforts are, but at the very least you'll be able to use them next time. Fine. Thank you very much, David. I haven't made any progress in the meantime as I was 5 weeks on vacation :) Here are the vote threads if you would like to vote (very encouraged): Will do this just for the archives. What's the current state? Are the jars available from a repository? Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Brainstorming for 2.0
Oliver Zeigermann oliver.zeigermann at gmail.com writes: As explaining in my previous post, I have created a new TRANSACTION2 branch to contain initial code, docs, etc. for a future 2.0 version of Commons Transaction. If you have ideas, suggestions, etc. please follow up to this post until we find a more suitable place for such a discussion. Open Questions (my suggestions in brackets): 1.) Medium for discussion (Wiki? SVN?) Why not this list? Do you expect so much discussion? 2.) Library requirement (1.5 concurrent package?) +1 In general there shouldn't be too many dependencies. Maybe a newer JCA spec later on. 3.) Minimum JDK Requirement (always the latest, i.e. 1.6) Hmm, why require more than necessary? Java 5 brings the concurrent package, but Java 6? Higher requirements always limit the number of users. 4.) Scope (all restricted as possible) Scope of what? Access scope of interfaces, classes, methods? Normally I tend to limit it as less as possible to allow easy extending and sub classing. But if changes to the API are always related with such circumstances ... Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] Towards a Commons Transaction 1.2 release
Hi everybody, I wonder if there can finally be a Commons Transaction 1.2 release. Half a year ago we already had a RC 3 [1] which did not get released at that time not due to a specific reason. There were discussions about getting the jars at build time [2]. This issue came up again [3] when talking about a release recently [4]. If somebody wants to do this step I'm fine with it, but IMHO it should not block the release. When doing the step one should also have in mind the necessity of 1.3 compiled Geronimo jars. David Blevins offered to help here [5, 6], but I don't know about any progress (cc-ing him). The code in SVN as is must be built with a JDK 1.4+ to include the JCA stuff. The target JDK 1.3 is addressed automatically by the build system. All other issues like interface compatibility [7] or license headers [8] have been addressed [9] or are obsolete with a new RC. So what is left? I gathered all those links and information as I will be off for the next 5 weeks (New Zealand :) ) and somebody else can jump on the train. I don't know how much time Oliver has. He is rather quiet lately. I'd like to see a Commons Transaction 1.2 release after coming back. Here is my +1 in advance :) Regards Jörg [1] http://marc.theaimsgroup.com/?t=11541897323r=1w=4 [2] http://marc.theaimsgroup.com/?t=11542281691r=1w=4 [3] http://marc.theaimsgroup.com/?t=11681461061r=1w=4 [4] http://marc.theaimsgroup.com/?t=11672486174r=1w=4 [5] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116838095403943w=4 [6] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116845728730516w=4 [7] http://marc.theaimsgroup.com/?t=11682925535r=1w=4 [8] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116783675420686w=4 [9] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116855776015241w=4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
splitting commons-dev mailing list (was: [all] Jira reporting)
Joerg Heinicke joerg.heinicke at gmx.de writes: ... splitting it into commons-cvs|svn|scm at jakarta.apache.org, commons-jira|issues|bugs at jakarta.apache.org and the actual dev list for discussions ... I just wanted to ping on this one [1]. There seems to be much agreement about splitting the list [2]. So is there any progress? Jörg [1] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116813323403039w=4 [2] http://marc.theaimsgroup.com/?t=11677755481r=1w=4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] svn commit: r494203 - in /jakarta/commons/proper/transaction/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/transaction/file/ResourceManager.java
Rahul Akolkar rahul.akolkar at gmail.com writes: Generally speaking, an interface-compatible change will at most change the private interface of a component, or simply add classes, methods and attributes whose use is optional to both internal and external interface clients. And this is not. In which way is it different from simply add [..] methods [..] whose use is optional to both internal and external interface clients. ?? Even simply replacing the former jar with the next version should work as the client does not know about the new methods. Only recompilation of implementations need adaptions before but that's not what I consider a use or a client. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jarfiles in svn
Craig McClanahan craigmcc at apache.org writes:
Someone had asked earlier about how Commons projects accomplished this goal
before Maven. The answer was a convention for using Ant build.xml scripts
that referenced a series of build.properties files containing definitions
for things like what commons-digester.jar should I use. The highest level
such file consulted was your ${user.home}/build.properties, so it was
reasonably easy to enforce global usage of common dependencies, as long as
all the build scripts used the same variable names.
Ah, yes. That's how it works in my company actually.
In your build script, don't hard code the build to use your particular
version of the dependency only. If I have my own version, I'm going to want
to use it universally.
The build of commons transaction still has some remnants of the above method
(build.properties.sample in root dir and property
file=${basedir}/build.properties/ in build.xml). I have not tried it and it
might need some adaptions. But I'd like to know if this is still an acceptable
way at all for Jakarta Commons before I invest any effort to fix it.
So what's the outcome of this discussion?
Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jarfiles in svn
David Blevins david.blevins at visi.com writes: Only passively reading the thread, but from some of the comments and your commit message it looks like you just need JDK 1.3 compiled versions of those specs. Yes, that's it. I'd be happy to apply your pom changes in the geronimo tree and put newly built versions up for a vote. That would be fine. But please review my pom changes. I'm not a Maven expert, but only googled for compiling for target JDK and found different approaches. Though this approach works for me there might be cases where it does not or simply better ones. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jarfiles in svn
Simon Kitching skitching at apache.org writes: When using maven, only the first run needs to download the jars ... So, no need for internet access at build time. For ant ... This can be run *once* to download the jars, but is not part of the main build task, so there is no need for internet access at build time. Even if only for the first run you need a build environment for downloading the dependencies. That's the point. (I speak from experience. In my company ...) A poor corporate internet access policy at one company is *NOT* a good justification for misusing the Apache SVN repository. 1. How can be a misuse what was (inevitably?) custom for years? I don't know how Jakarta Commons handled this before Maven. Of course SVN might not be perfect for it. But as long as infrastructure team does not even discourage from committing jars I don't see a real problem with it. And for commons transaction we talk about other magnitudes than for Cocoon (665 KB vs. 40-45 MB). 2. I don't give justifications for enacting a law or something like that. I only gave an argument which might be considered as well. Other examples might be imaginable. If it is common understanding to do it the other way, be it for unification or other reasons mentioned, I'm ok with it. Thanks for your understanding. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jarfiles in svn
David Blevins david.blevins at visi.com writes: If someone needs JDK 1.3 versions of any spec jar, I'd be happy to help. OpenJPA had a similar request recently (JDK 1.3 version of JTA 1.1) and I made sure to do the final release of that spec with JDK 1.3. What exactly do you have in mind with your help offer? Is it publicly available then, maybe with a different naming? Please find my commit at http://svn.apache.org/viewvc?view=revrevision=493595. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] svn commit: r494203 - in /jakarta/commons/proper/transaction/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/transaction/file/ResourceManager.java
Rahul Akolkar rahul.akolkar at gmail.com writes: URL: http://svn.apache.org/viewvc?view=revrev=494203 snip/ This change warrants a major release for [transaction]. Really? I don't mind if the current code is release as 2.0. But for such a minor change (though in the interface)? Please find my reasoning in https://issues.apache.org/jira/browse/TRANSACTION-11. Also I read the versioning guideline and can't see whether it really needs a major release (http://jakarta.apache.org/commons/releases/versioning.html): Generally speaking, an interface-compatible change will at most change the private interface of a component, or simply add classes, methods and attributes whose use is optional to both internal and external interface clients. Developers must perform a major release whenever the new release is not at least interface-compatible the previous release. IMHO the condition is fulfilled, so the rule does not fire. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jarfiles in svn
Craig McClanahan craigmcc at apache.org writes: Storing JAR files in your source repository (or pretty much any other scenario where you check in things that have been generated, instead of rebuilding them) has the following negative impacts: * Bypasses the normal mechanisms people use to verify that the bits they are depending on have not been corrupted (either accidentally or maliciously). A cautious downstream user will go directly to the origin for every package they depend on, and validate checksums and signatures. You are asking your downstream users to trust *you* to not have messed with these jar files. Good point. Side notes (not invalidating the point): Maven has switched off enforcing checksum match by default. Often projects would also not be buildable due to checksum mismatches in the dependencies. And: I have to trust Maven that it really checks every download. * Typically leads to a build environment where *only* the copy of the dependent jars in your repository are used. That makes life much harder for downstream users who might have several packages that need the same dependency, and need to be sure that their entire application * Creates redundant copies of shared dependencies in the build environment of your downstream users (if they use lots of packages that follow the same practice). It's one thing to make a mess of redundant copies on our own server. It's quite another thing to make a mess in your user's directory, for every user. I guess that was the major driver for Maven et al. but please let your user opt out of *only* being allowed to use the version you shipped. What do you have in mind? What's actually enforced? Does it relate to your impact 2 which is somewhat shortened? Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jarfiles in svn
Simon Kitching skitching at apache.org writes: For a start, if every project were to do this, the impact on the Apache SVN repository would be huge. Cocoon (maintenance branch 2.1) has currently 111 jars with about 40 MB in its repository (+ the one for the environment [2]), we are regularly upgrading them and it has never been seen as a problem from infrastructure team. I would instead prefer to see ant builds using get to download jars as needed. The maven repositories can be used as a convenient source for the jars, eg http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk/build.xml I posted my opinion on this recently [3]: In general I don't like the need for internet access on build time. But with Ant it's at least better than with Maven as the build environment itself does not get changed. My concerns are raised after one year mess with Maven in Cocoon trunk. Regards Jörg [1] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/lib/ [2] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/lib/ [3] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116811395603150w=4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-transaction (in module jakarta-commons) failed
Adam Jack ajack at apache.org writes: Project commons-transaction has an issue affecting its community integration. This issue affects 20 projects. The current state of this project is 'Failed', with reason 'Build Failed'. Will have a look on this. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jarfiles in svn
Martin Cooper martinc at apache.org writes: In general I don't like the need for internet access on build time. This is a red herring. One way or another, you're going to have to get the jars from the network, whether it's getting them from SVN, or having Maven or Ant retrieve them. And in all of those three cases, once you have them on your local machine, you don't need the network to build the next time. There is one big difference: With everything in the src jar or at least in the svn checkout your requirements are less sophisticated than with the build system. For src jar I only need a browser, for svn checkout I need a svn client, but for Ant and Maven I need additionally Java and the build environment itself. And this is a big difference if the machine with internet access is not your local machine. (I speak from experience. In my company I get access to the internet only via a terminal server. There is no build environment. For proposed changes in the build I need to download all dependencies by hand.) Regards Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Transaction 1.2
Niall Pemberton niall.pemberton at gmail.com writes: The ant build only seems to work for JDK 1.3 when the geronimo jars are overriden with the sun ones and doesn't work for me for JDK 1.4 Yes, it stands and fails with the correct jee jars as I wrote recently [1]. (tests fail because it can't find junit). This might have been done with an especially prepared Ant. You either have to drop both ant-junit.jar (Ant task) and junit.jar (JUnit itself) into Ant classpaths or separate both jars from it [2]. (This seems to have changed with Ant 1.7.) I guess the dist was always done with junit.jar dropped into Ant's classpath as there is no taskdef in build.xml. So it seems a waste of time having them in the repo. I can update the ant build to download the other jars (or allow them to be specified in a build.properties) if its important to have a working ant build for 1.3. In general I don't like the need for internet access on build time. But with Ant it's at least better than with Maven as the build environment itself does not get changed. Is it really the only solution? Can Geronimo offer those jars compiled with JDK 1.3 (whoever has to do this work)? Hmm, wait, Cocoon 2.1 uses them as well and also claims 1.3 compatibility. I'll have a look. Even if not I do not see it as a blocker if the build does not work with 1.3. The same was true for older releases, so there is no deterioration. It only must be runnable with 1.3 and this should be true when you have 1.3 compiled jee jars. I'm wondering how the RC was created since neither the ant or maven builds seem to currently produce what RC3 contained. No idea. But if JUnit is the only remaining problem when building with 1.4 I wrote a probable subtile difference in the environment above. If it helps I can tag and produce another RC (using the maven build). That would be fine as I don't have any experience with releasing on Apache. (I only have written a company internal build system based on Ant 1.6 2 years ago, where I just need to do dist projectname and everything happens from clean check out to tagging and finally putting it into a local repository.) Regards Jörg [1] http://marc.theaimsgroup.com/?t=11672360475r=1w=4 [2] http://ant.apache.org/manual/OptionalTasks/junit.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
Henri Yandell flamefew at gmail.com writes: The spam issue is a tricky decision. Sometimes I turn off the notifications to then do a lot of changes, other times I let the spam hit the list because moving an issue into a version is a decision. If there were a lot of them, I'd be tempted to send an email to the list saying Moving these issues into XXX and then do a bulk move with the send-email option turned off. That'd be a nice JIRA feature - bulk-email notification rather than individual notification for each issue. Another way to let it be less bugging would be a splitting of this mailing list into multiple ones. No, not project specific - I know you love the cross-pollination :) But splitting it into commons-cvs|svn|[EMAIL PROTECTED] (many projects have their own list for commit mails), commons-jira|issues|[EMAIL PROTECTED] (don't know a project having this, but would love to see this, especially because of the topic we are actually talking about) and the actual dev list for discussions. This would finally make it possible to read current heavy traffic lists like geronimo-dev and this one on mailing list archives. At the moment I often get lost in the huge amount of mails and I refrain from subscribing to both metioned lists. WDYT? Any chance for implementation? Regards Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Transaction 1.2
Joerg Heinicke joerg.heinicke at gmx.de writes: The ant build only seems to work for JDK 1.3 when the geronimo jars are overriden with the sun ones and doesn't work for me for JDK 1.4 Yes, it stands and fails with the correct jee jars as I wrote recently [1]. Works now with 1.3 compiled Geronimo jars. Created them by checking out the tagged 1.1 versions (i.e. delivered with Geronimo 1.1) and modifying the POMs. (tests fail because it can't find junit). This might have been done with an especially prepared Ant. You either have to drop both ant-junit.jar (Ant task) and junit.jar (JUnit itself) into Ant classpaths or separate both jars from it [2]. (This seems to have changed with Ant 1.7.) I guess the dist was always done with junit.jar dropped into Ant's classpath as there is no taskdef in build.xml. Using Ant 1.7 the build indeed works as is. Hmm, wait, Cocoon 2.1 uses them as well and also claims 1.3 compatibility. Cocoon had only jta in use, but missed jca. That's why I had to do all the things mentioned above. If it helps I can tag and produce another RC (using the maven build). It would be really fine if you (or Oliver when he is around) could create a new dist. This works for me with both JDK 1.3 and 1.4 when using Ant 1.7. For including all files and the XA/JTA/JCA stuff it must be distributed with JDK 1.4. The compiled stuff should be usable with JDK 1.3 though. What I tested was a dist with 1.4 and an immediate ant test with 1.3 afterwards which worked (it did not recompile the classes, only the tests). Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Transaction 1.2
Niall Pemberton niall.pemberton at gmail.com writes: Since RC3 was created (back in July 2006!) there is now the new Source Header and Copyright Notice Policy that needs to be complied with: http://www.apache.org/legal/src-headers.html Henri fixed this in the trunk for transaction a few weeks ago - but warrants a new RC IMO. Ok, that's an issue. Also Rahul raised the issue about dependency jars held in the repository - and it looked to me like you were going to change the build to download these automatically, rather than including them in the distro: http://tinyurl.com/yby9hd We wanted to get out the release as fast as possible. This issue can be postponed and addressed later IMO. I also think given the long time between cutting the RC and voting this makes the case for tagging the repository - initially I wondered where this had been built from as it didn't match any current source - until I releaized it had been done so long ago. The long time itself is not an issue, nothing has changed on the source code since the latest RC except the headers. The commits I did recently don't fix the issue (not buildable with JDK 1.3 due to 1.4 compiled dependencies), but only show the issue at a different during a build. This itself does not warrant a new RC IMO, but as the headers do so, it will be included in that RC as well. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
Martin Cooper martinc at apache.org writes: Any exact targetting for unresolved issues will lead to this issues hasn't made it into the latest release, we try to get it into the next one mails polluting the mailing lists without nearly any additional value. I think that is a good thing as it means someone is looking at that issue each release and deciding that it won't go in that release. If it keeps getting punted all the time then someone can ask if it's ever going to happen. This is exactly why we moved to something like what Hen is proposing for Struts. We had oodles of issues just sitting there with no indication of when, if ever, they were likely to be fixed, and no indication of whether anyone was committed to looking at them. Once you start versioning the issues, you get the beginnings of a roadmap rather than just a bucket of issues. Ok, that's a point. Cocoon does indeed suffer from this as well. But I guess in Cocoon changing this would just not work (or end in 300 issue version re-addressed mails per release). For the maintenance branch the development is much less targeted as it is more or less only project-driven, i.e. an issues that a committer needs on his current project gets handled rapidly. Other issues are mostly done on demand or on request. For littler projects or projects with less chaotic project management (which I like much though :)) the above might indeed be useful. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add Matt Benson as a Jakarta committer
+1 welcome! Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
Henri Yandell flamefew at gmail.com writes: The aim is to provide us with information on where projects are release-wise and where we are in terms of answering new issues. Some of our components aren't there - for example Jelly which has 77 unversioned issues and Attributes/Discovery which are ready to be retired. Some of the ones there should probably be removed for having too many unversioned issues. I wonder what's the problem with unversioned issues. It simply says in the future. Any exact targetting for unresolved issues will lead to this issues hasn't made it into the latest release, we try to get it into the next one mails polluting the mailing lists without nearly any additional value. Dennis Lundberg dennisl at apache.org writes: And any component with a high number of solved issues deserves a release, no matter what the total says, say like 40/300. If it's just the number of resolved issues, you don't need the number of unresolved issues assigned to a target release. I tend to agree with this POV. Regards Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA permissions
Henri Yandell flamefew at gmail.com writes: I would like to be added to jakarta-developers as well. Done. Thanks, Hen. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] JDK 1.3 compatibility
Hello, when playing around with commons transaction I did a test compile with JDK 1.3. I wonder if we can still claim that 1.3 is the minimum requirement. One bug in the build.xml I fixed already [1]. But you still can't compile commons transaction with JDK 1.3 as it fails for ResourceManager extending javax.transaction.Status being JDK 1.4 compiled. Even compiling it with 1.4 and just running with 1.3 will fail as long as you don't provide the jta classes compiled with 1.3 - and I wonder if that exists. I don't see a problem if it would be only the jta/jca stuff requiring 1.4, but would like to see it clearly separated in the source tree then. (side note: How do other commons projects handle this?) But with ResourceManager and javax.transaction.Status that's not possible. Regards Jörg [1] http://svn.apache.org/viewvc?view=revrevision=490420 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Transaction 1.2
Oliver Zeigermann oliver.zeigermann at gmail.com writes: To release 1.2 final based on that release candidate here is my +1 Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA permissions
On 8/28/06, Kris Nuttycombe Kris.Nuttycombe at noaa.gov wrote: Another new-committer question: Are special privileges required to change the status of issues in JIRA? There are a few outstanding issues in [pipeline] that can now be closed. This is an issue not yet covered in the new committers' guide. Henri Yandell flamefew at gmail.com writes: Yep, we need to add you to jakarta-developers. I would like to be added to jakarta-developers as well. I'm a committer of Jakarta Commons Transaction. There should be only one account of mine in Jira, otherwise it's the one with this mail address as user name. Thanks in advance, Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Major versions require package name change
Torsten Curdt tcurdt at apache.org writes: I really wonder why this should be a concern of the actual component at all. A component is an encapsulated piece of software with a well-defined interface (here API). If there are problems in the environment in using this component or looking it up (here jar hell/classpath), then this is a problem of the environment, not a concern of the component. Therefore this thing has also to be fixed in the environment. Classloader shielding is an appropriate solution. Classloader shielding does not help if your application uses libA and libB both having dependencies on libC ...but of different versions - that are incompatible. I fail see how that is environment related. It is in so far as the application has a problem by using libA and libB. libC itself has no problem, but its users. So it is not the component, but the environment. Just put the shielding on a lower (than the application) level and it works again, doesn't it? Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Major versions require package name change
Stephen Colebourne scolebourne at btopenworld.com writes: PROPOSAL: The major version number of a component, where it is greater than 1, shall be included in the package name. I really wonder why this should be a concern of the actual component at all. A component is an encapsulated piece of software with a well-defined interface (here API). If there are problems in the environment in using this component or looking it up (here jar hell/classpath), then this is a problem of the environment, not a concern of the component. Therefore this thing has also to be fixed in the environment. Classloader shielding is an appropriate solution. There is much ongoing work like OSGi to standardize this and make it easier usable. So I wonder why this is now still such a major topic though it worked ten years without it. Maybe in 2 or 3 years nobody will talk about it at all when classloader shielding is so common and easily usable. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: transaction] Commons Transaction 1.2 rc3 ready for inspection
Oliver Zeigermann oliver.zeigermann at gmail.com writes: Finally there is the third release candidate at http://people.apache.org/~ozeigermann/tx-1.2rc3/ Hi Oliver, just wondering: What happened to the release? Cheers, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Commons Transaction 1.2 rc3 ready for inspection
On 7/29/06, Oliver Zeigermann oliver.zeigermann at gmail.com wrote: Finally there is the third release candidate at http://people.apache.org/~ozeigermann/tx-1.2rc3/ From a functionality POV it works for me. Regarding JDK 1.3 ([1]): How did you solve the problem with the J2EE/Geronimo jars? Did you recompile them? Rahul Akolkar rahul.akolkar at gmail.com writes: * Why are the dependencies (the lib folder) included in both distros? I'd prefer that they aren't, is there any particular reason why [transaction] does that? The main build process uses ant which requires these libraries. snip/ I'm not in favor of distributing deps along with Commons libraries' distributions. * Its straightforward to provide an ant target to download the deps. In contrast to this I prefer to deliver the dependencies as well. There are rumours about companies that don't provide direct access to the internet from the employee's PCs, but only via a terminal server (Unfortunately, I'm working for such a company). The problem is simply that those people can't use such download tasks or Maven. If you don't deliver the dependencies they have to run after each single jar. Even for Apache Cocoon (which has a huge list of dependencies) we will provide a distribution including the dependencies. * Distribution of (potentially) 3rd party binaries (as an example, JUnit, in this case) means we have to understand their licenses (by refering to the ASF legal docs), determine reciprocity requirements as needed etc. No bang for the buck here. It has worked for years. Why shouldn't it work further on? * The source distro contains the jar -- which I wouldn't expect to be there. Yes, this is superfluous IMO as well. And as a minor nit, there are 7 odd Javadoc warnings. I recently fixed some of them: [2]. When I did this I did not find any worth to be fixed. Cheers, Jörg [1] http://thread.gmane.org/gmane.comp.jakarta.commons.devel/86451/focus=86451 [2] http://svn.apache.org/viewvc?view=revrevision=47 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Release plan?
Oliver Zeigermann oliver.zeigermann at gmail.com writes: Also what is the minimum JDK version for transaction? I used ant for the previous releases (target package). Minimum jdk is 1.2 Has anybody actually been checking this? Setting those properties has probably influence on the compiler (e.g. complain about newer language constructs (asserts, etc.) and the generated bytecode), but not on the available API I think. Despite bytecode compatibility you might end with ClassNotFoundExceptions and NoSuchMethodExceptions when using JDK 1.3+ API. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] splitting ResourceManager interface
Oliver Zeigermann oliver.zeigermann at gmail.com writes: That certainly is post 1.2, right? Maybe even some work for a 2.0 version? Yes, definitely after the current release process. We can decide whether it gets 1.3 or 2.0 or what else, when we have the code :) Hmmm. Why do you need FileResourceManagers in the fist place? Just to synchronize file access? Not quite sure here... Not that much synchronizing, but more the transactional behaviour. The FileResourceManager in my use case also takes part in global transactions. You remember my work on the XA stuff at the beginning? (OT: Sometimes ago I mentioned that this XAResource implementation might be donated to Commons Transaction. I got no go from my employer at that time. We were taken over by another company and our management did not want to decide about those things. Maybe I should put it back on the table ...) Anyway, TransactionManager wouldn't be such a good name for a new class as it has a predefinied meaning in the J2EE world I guess. Ok, naming clashes might better be avoided. But from the meaning I chose the name after comparing with the JTA TransactionManager interface as the ResourceManager's methods related to transaction handling and the JTA TransactionManager methods are quite similar. So I don't think there is a different meaning. And how many ResourceManagers exist in the world? ;) One way would be to leave the ResourceManager interface untouched and introduce your two new interfaces. FileResourceManager would implement all three interfaces. Yes, of course ... good idea ... Another idea would be to make it all better in 2.0 and do not care too much for backward compatibility. One idea might be to even use Java 5 locking. Maybe this is stuff for another thread, though... I don't want to change that much at the moment. Just splitting the concerns with care for backward compatibility. About Java 5: I have never used it yet. Don't know what it can really buy us though I read much about its nice features. But let's do one step after another ;) Cheers, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Release plan?
Niall Pemberton niall.pemberton at gmail.com writes: Has anybody actually been checking this? I just tried compiling using JDK 1.3 Thanks. So it seem that for JDK 1.3 the only real issue is in FileResourceManager. It was me who introduced it :) Fixed it ... Another thing I noticed - the build.xml sets the compile target to 1.3 - so maybe I should switch back the equivalent maven settings (I added them as 1.3 and then switched to 1.2 yesterday, following Oliver's comment). So switching back to 1.3? Oliver? I've changed the build.xml to resolve the JDK 1.3 issues there - but have left the FileResourceManager issue for someone else to deal with. You could commit this as well as easy as it was :) Cheers, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] splitting ResourceManager interface
Hello Oliver, Oliver Zeigermann oliver.zeigermann at gmail.com writes: The ResourceManager interface rather is some sort of relict from older times. No need to worry much about it except for backward compatibility. This can be the hardest thing to worry about ;) Why change things in the first place? Just because the FileResourceManager is huge? That is not a bad thing all by itself. Some classed simply get big. Compare it to the String class. It is twice as big. No, hugeness is not something I really worry about. The risk of breaking anything even by the simplest change is mostly not worth the gain. So I don't care about size but number of concerns, what's a big difference ... ok, this is nitpicking :) Actually I would like to address some different requirements with my FileResourceManager, which I can no longer fulfill by just extending the current one. Reimplementing the current ResourceManager interface would be absolute overkill as the transactional stuff is exactly the same. It's only the resource handling I need in a different way. My use case: We have some data input and output dirs for different let's call them communication partners and a common repository dir: ROOT -- cp1 -- upload | \- download |- cp2 -- upload | \- download | \- repo Up to now the data dirs and the repo dir had a common root to which I set the store dir. But now data dirs and repo dir can be completely different. I could set the store dir to / but I don't think that's really appropriate. Furthermore the FileResourceManager does a recursive delete of directories so that the data dir structure gets lost atm. With the current behaviour I would need one FileResourceManager for every sub dir. This would be acceptable if they had not such a huge overhead of lifecycle but would only be wrappers around file system access. All instances would refer to one TransactionManager then. Another possibility would be to allow the FileResourceManager to handle multiple store dirs but I'd prefer the first approach. Hope this explains it a bit ... Anyway, if you want to introduce something new, got ahead, but be aware of backward compatibility issues. The question is in which extend. Even simply stripping the transactional concern from ResourceManager interface into its own and letting the FileResourceManager implement both interfaces, can lead to incompatibilities if the methods for transactional concern are called on the ResourceManager interface and not on the FileResourceManager instance. P.S.: I think it might be the time for a 1.2 release. What do you think? See other thread ... Jörg 2006/7/13, Joerg Heinicke joerg.heinicke at gmx.de: Hello, the more I work with the FileResourceManager the more I'm convinced that the ResourceManager interface should be splitted into two interfaces: one for handling the locking and transactional stuff (proposal: TransactionManager) and one for actually handling the resources (as is: ResourceManager). One the one hand the only implementation, the FileResourceManager, simply does too much, i.e. too many concerns are handled in it. On the other hand I extend my local version of the FileResourceManager with more and more methods to emulate a file system access (methods from java.io.File actually). In theory I would need to add these methods to ResourceManager interface to be able to work with interfaces, but it would get bigger and bigger. Instead I wonder if a generic ResourceManager interface (in my new sense as described above) is appropriate at all. Probably it would be more appropriate to rename it to FileResourceManager or introduce FileResourceManager interface extending ResourceManager. The splitting of the current ResourceManager interface would allow to reuse the transaction/locking capability with different ResourceManagers (in my new sense). The splitting should be quite easy IMHO. The concerns are quite good separated in the FileResourceManager. WDYT? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Release plan?
Oliver Zeigermann oliver.zeigermann at gmail.com writes: Excatly! That's just what I was proposing in my last email! 2006/7/13, Henri Yandell flamefew at gmail.com: Is the aim to have a 1.2 release of transaction at some point? Yes, I would like to see a 1.2 release as well. There are enough fixes and enhancements that qualify for a new release. What's the actual release process (code freeze, etc.)? RELEASE-NOTES.txt talks about 1.1.1 while we now will probably name it 1.2 btw. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] splitting ResourceManager interface
Hello, the more I work with the FileResourceManager the more I'm convinced that the ResourceManager interface should be splitted into two interfaces: one for handling the locking and transactional stuff (proposal: TransactionManager) and one for actually handling the resources (as is: ResourceManager). One the one hand the only implementation, the FileResourceManager, simply does too much, i.e. too many concerns are handled in it. On the other hand I extend my local version of the FileResourceManager with more and more methods to emulate a file system access (methods from java.io.File actually). In theory I would need to add these methods to ResourceManager interface to be able to work with interfaces, but it would get bigger and bigger. Instead I wonder if a generic ResourceManager interface (in my new sense as described above) is appropriate at all. Probably it would be more appropriate to rename it to FileResourceManager or introduce FileResourceManager interface extending ResourceManager. The splitting of the current ResourceManager interface would allow to reuse the transaction/locking capability with different ResourceManagers (in my new sense). The splitting should be quite easy IMHO. The concerns are quite good separated in the FileResourceManager. WDYT? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] AbstractXAResource: prepare() with result XA_RDONLY without commit()
I came across some further problems with the transactional FileResourceManager and the XAResource implementation. Simple deletes of resources did not get applied for me. Debugging showed that no commit was triggered. The reason: deleteResource() and createResource() in FileResourceManager were assumed as being read-only (TransactionContext.readOnly not set to false). The TransactionManager got XA_RDONLY as return value of XAResource.prepare() and so did not trigger commit() or rollback(). The transaction in FileResourceManager remains in uncompleted state. I'm going to commit a fix for this problem. Second problem is the prepare() with result XA_RDONLY without commit(). I assume it is a bug in AbstractXAResource too, but maybe somebody can confirm it first. There is no clear comment about it in the spec. Only the API for XAResource says for XA_RDONLY: The transaction branch has been read-only and has been committed. That is probably why the TransactionManager did not trigger a commit() on prepare() with XA_RDONLY. WDYT? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] AbstractXAResource: prepare() with result XA_RDONLY without commit()
Oliver Zeigermann oliver.zeigermann at gmail.com writes: The reason: deleteResource() and createResource() in FileResourceManager were assumed as being read-only (TransactionContext.readOnly not set to false). Hard to believe, but this really seems to be true. A fix should be simple, right? Will you do that. I wonder why this hasn't shown before? The fix is hopefully as simple as I did it. I tested it at least using that patch and got my symptoms fixed (read below). Why it hasn't shown before? Good question. What I can imagine - at least for createResource() - is that nobody actually just uses createResource() but also writeResource(). If nobody has ever used a simple single deleteResource() as I do it does not bubble up. I would really like to add such things as test cases but I'm unfortunately really short on time at the moment. There is no clear comment about it in the spec. Only the API for XAResource says for XA_RDONLY: The transaction branch has been read-only and has been committed. That is probably why the TransactionManager did not trigger a commit() on prepare() with XA_RDONLY. Yes, I think when the result is XA_RDONLY there is no need for a commit, as there is nothing to commit. I just wonder when the transaction is ended. When are the read locks set free? The problem is that these resources were never freed. And I observed it just by some symptoms: In my work dir more and more directories got added but not freed after the end of the transaction. The transaction simply did not end. With fixing read-only status of deleteResource() and createResource() I got at least lower growth-rate of directories, but real read-only operations did still end in remaining directories. I added a quick fix checking for XA_RDONLY in AbstractXAResource.prepare() and committing in case of. It might not be really appropriate, but had no other short-term solution. And I do not really know if the immediate release of resources in FileResourceManager.prepare() in case of read-only status is more appropriate as the specific transaction management (no commit() when prepare() returns read-only) comes from JTA. OTOH why should other transaction management implementations behave differently when there are well-known basics. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] allow (easier) subclassing of FileResourceManager
Long time ago I mentioned a problem with the usage of the transaction ids as directory name [1]. This problem resulted from JOTM using colon as part of an Xid. For easier subclassing I created a patch at [2], so that all references to this directory are collected at one place (getTransactionBaseDir(Object txId)). This method could be easily overwritten in subclasses. Would be nice if anyone could apply it. Besides that I have a second problem subclassing FileResourceManager. I want to add a feature allowing to append to an existent file, by adding writeResource(Object txId, Object resourceId, boolean append). I copied the existing writeResource(Object txId, Object resourceId) into my subclass and ended at TransactionContext.readonly not being visible to my subclass. The simple solution would be to add a public setter to TransactionContext, the better solution to implement writeResource(Object txId, Object resourceId, boolean append) ;) For the implementation: If I get it correctly the file that should be written to must be copied from store dir to work dir if it does not yet exist in the work dir. Thanks Jörg [1] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=113101671215483w=4 [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=37379 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] errors in commits to FileHelper
Another strange things in commits, this time the latest 3 commits to FileHelper:
1. http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/transaction/trunk/
src/java/org/apache/commons/transaction/util/FileHelper.java
?rev=349996r1=155433r2=349996diff_format=h
Shouldn't it be
if ( ! targetFile.mkdirs()) {
-^-
2. http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/transaction/trunk/
src/java/org/apache/commons/transaction/util/FileHelper.java
?rev=349997r1=349996r2=349997diff_format=h
Fixing the above makes probably this commit obsolete. At least it would no
longer be a fix to fix, which only hides the problem in many cases, but might be
an optimization.
3. http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/transaction/trunk/
src/java/org/apache/commons/transaction/util/FileHelper.java
?rev=35r1=349997r2=35diff_format=h
Same like 1., again a missing ! I think.
WDYT?
Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Duplicated TxId generation under heavy load
Oliver Zeigermann oliver.zeigermann at gmail.com writes: To me it seems generatedUniqueTxId does exactly as advertised in Javadocs. Don't you agree? No. :) This dismisses my argument about externally generated ids, yes. But two different threads calling generateUniqueTxId() at the same time still get the same unique id as the first thread calling this method does not preserve the id. So the current implementation does not fulfill the contract mentioned in the Javadocs. You simply need something different as it seems. Unique Id generators - that's what you need - are easy to find, even in the Jakarta Commons Project :) For the externally generated ids I agree. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Duplicated TxId generation under heavy load
Cservenak Tamas cservenak at is-micro.hu writes: The generatedUniqueTxId() method in FileResourceManager uses System.currentTimeMillis() to generate txId's. On my system it causes duplicate txId generation and FRM failure. I have 4 threads accessing one FRM instance. This simple patch adds salt to it, with a little overhead to solve this problem. Unfortunately this does not help much, it only solves your problem under heavy load. But if there is already another txId equal to this one (e.g. generated externally) FRM will again fail. It can only work if inside the synchronized block the generated txId is preserved, e.g. by putting a final static object PRESERVED into the map and testing for it in the startTransaction(Object) method. This will solve almost all problems except one: 1. Thread 1: generateUniqueTxId() 2. Thread 2: startTransaction(txId) with an externally generated txId - coincidentally equal to the above generated one 3. Thread 1: startTransaction(txId) with the generated txId But is again a magnitude more unlikely. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] AbstractXAResource throws exception on TMJOIN
Oliver Zeigermann oliver.zeigermann at gmail.com writes: But even more, may understanding is that the user will never see an XAResource and will never try to get an instance of it. It simply is an interface between the transaction manager of your container and your resource manager. Ok, this might be the reason for my different views up to now. Is an XAResource always supposed to be accessed through JCA, i.e. the resource adapter is an implementation of JCA? I got the impression when having again a look on your transactional Map implementation. Unfortunately the JTA spec does not speak about this point (JCA), only mentions JDBC and JMS, which might be an analogy here. Yet another spec/API I have to look at ... and maybe the JTA spec makes more sense with this changed view. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] AbstractXAResource throws exception on TMJOIN
Hello, there seems to be some inconsistency in the implementation of AbstractXAResource regarding TMJOIN in the start() method. The first thing that is checked for in this method is getCurrentlyActiveTransactionalResource() != null and a XAException is thrown if there is a currently active transactional resource (CATR). But IMO this is wrong for TMJOIN as you want to join a transaction, so there must be a CATR. From the implementation of the start method I assume TMJOIN implementation is included, but wrong. For joining an active transaction also createTransactionResource() is called while probably getActiveTransactionalResource(Xid xid) would be correct. WDYT? Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] AbstractXAResource throws exception on TMJOIN
Oliver Zeigermann oliver.zeigermann at gmail.com writes: there seems to be some inconsistency in the implementation of AbstractXAResource regarding TMJOIN in the start() method. The first thing that is checked for in this method is getCurrentlyActiveTransactionalResource() != null and a XAException is thrown if there is a currently active transactional resource (CATR). But IMO this is wrong for TMJOIN as you want to join a transaction, so there must be a CATR. A thread can only be part of at most one transaction at a time. If it already has an active transaction, joining another is an invalid operation. Sorry, but I don't understand you here. If a thread can only have one transaction, why is it not allowed to join this active one? But re-reading the spec I came to the conclusion that the CATR != null check is not the problem. In section 3.4.4 of the spec (you know it?) there is a table about the correct XAResource to transaction association. And for both start(NOFLAGS) and start(TMJOIN) the XAResource can only switch from not associated to associated meaning that the null check is ok. But as far as I understand the spec there can be multiple instances of XAResource accessing the same resource manager (otherwise TMJOIN makes no sense, and XAResource.isSameRM(XAResource) neither). Example: Both component1 and component2 have a method requiring a transaction, and component1 calls component2. Both lookup the same XAResource from JNDI actually getting different instances of this XAResource. When component2 now accesses the XAResource it actually *joins* the transaction. This means that another aspect of AbstractXAResource is wrong: I already mentioned createTransactionResource(Xid) for TMJOIN in the last mail. IMO it must be getActiveTransactionalResource(Xid). This leads to another change to get it working as the activeContexts would be empty of course: The both maps suspendedContexts and activeContexts must be static ThreadLocal variables. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] AbstractXAResource throws exception on TMJOIN
Oliver Zeigermann oliver.zeigermann at gmail.com writes: Hmmm. I do not understand you either. :) I have certainly read the XA spec, but - of course - am not entirely sure that my implementation is free of errors. I did not know that it was you implementing it. And about the errors: that's what I want to find out. Interpreting the spec is not that easy IMO, it is really database specific and talks about connection's close method: Huh? Is it about JTA or JDBC? Where is a connection in JTA. Active and suspended contexts are of course shared by the XA resource, why should it be local to a thread then? My problem is that the contexts are specific to an XAResource *instance*. But is it not possible to have more than one instance accessing one resource manager from one thread? This is what my example with the two components was about. If you use JNDI (standard in EJB 2.x) for looking up your XAResource you get a new instance of XAResource for each lookup, so one for both components. This is why I think the contexts must be made known to the thread (hence ThreadLocal), not only to the instance. Maybe the misunderstanding is the active transaction branch which is associated to a specific thread. That's why it is a thread local. This means if there is a tx associated to a thead it will be stored there. No I think, that is clear. It is only difficult to control if you allow multiple XAResource instances per thread - which is allowed from my understanding. Hope it's getting clearer where my actual problem is. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] compatibility of ResourceManager to XAResource interface
When following the JTA 1.0.1B spec [1] while implementing my resource adapter (XAResource) around the Commons Transaction FileResourceManager I came across another issue: XAResource has a method public Xid[] recover(int flag). Following is written in the spec's section 3.4.8 Failures recovery: For each resource manager, the Transaction Manager uses the XAResource.recover method to retrieve the list of transactions that are currently in a prepared or heuristically completed state. [..] Because XAResource objects are not persistent across system failures, the Transaction Manager needs to have some way to acquire the XAResource objects that represent the resource managers which might have participated in the transactions prior to the system failure. For example, a Transaction Manager might, through the use of the JNDI lookup mechanism and cooperation from the application server, acquire an XAResource object representing each of the Resource Manager configured in the system. The Transaction Manager then invokes the XAResource.recover method to ask each resource manager to return any transactions that are currently in a prepared or heuristically completed state. It is the responsibility of the Transaction Manager to ignore transactions that do not belong to it. This means I need a way to retrieve a list of transaction IDs to be recovered, which the Commons Transaction ResourceManager interface does not provide at the moment. Its recover() method does not provide it. Would it be possible to change the method though this changes the interface? Jörg [1] http://java.sun.com/products/jta/index.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] XAResource wrapper for commons transaction
Oliver Zeigermann oliver.zeigermann at gmail.com writes: 1. Commons transaction is not prepared for JNDI. Honestly, I have no idea what this is all about. Could you explain? Hello Oliver, to be honest I do neither know that much about it. My impression was that most of the JTA transaction manager use JNDI for binding and looking up the resources. And this is mostly coupled with RMI. Now when I tried to bind my XAFileResource or the commons transaction FileResourceManager to my JNDI context (= RMI) I got the exception that one of those interfaces must be implemented. I already worked with IBM's DB2XADataSource and the more common StandardXADataSource of ObjectWeb's XAPool both implementing javax.naming.Referenceable [1]. Now there is the question if this is really an issue of FileResourceManager or just of my wrapper. So it might be something for your AbstractXAResource too. From what I understand this Reference/Referenceable stuff seems to be some factory mechanism, but I hoped to get some more information here. Regards, Jörg [1] http://java.sun.com/j2se/1.4.2/docs/api/javax/naming/Referenceable.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] XAResource wrapper for commons transaction
Hello, I now implement the XAResource wrapper for commons transaction and came across two issues: 1. Commons transaction is not prepared for JNDI. This is probably not a must, but most of the containers seem to work with JNDI. When trying it that way I get the following exception: java.lang.IllegalArgumentException: RegistryContext: object to bind must be Remote, Reference, or Referenceable at com.sun.jndi.rmi.registry.RegistryContext.encodeObject (RegistryContext.java:403) at com.sun.jndi.rmi.registry.RegistryContext.rebind(RegistryContext.java:131) at javax.naming.InitialContext.rebind(InitialContext.java:367) ... at com.rauser_ag.transaction.file.XAFileResourceTestCase.setUp (XAFileResourceTestCase.java:65) Any opinion about this? 2. Using the transaction id for the name of the temporary directory is not very reliable: 2005-11-03 12:11:47,293 FileResourceManager ERROR - Saving status information to 'build/tmp/bb14:38:40:0177cdf01a0acfa3a8...a42401:0177cdf01a0acfa3a8f38...00 /transaction.log' failed! Could not create file java.io.FileNotFoundException: build\tmp\bb14:38:40:0177cdf01a0acfa3a8...a42401: 0177cdf01a0acfa3a8f38...00\transaction.log (Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at org.apache.commons.transaction.file.FileResourceManager $TransactionContext.saveState(FileResourceManager.java:1447) at org.apache.commons.transaction.file.FileResourceManager $TransactionContext.init(FileResourceManager.java:1342) at org.apache.commons.transaction.file.FileResourceManager.startTransaction (FileResourceManager.java:515) at com.rauser_ag.transaction.file.XAFileTransactionalResource.begin (XAFileTransactionalResource.java:28) at org.apache.commons.transaction.util.xa.AbstractXAResource.start (AbstractXAResource.java:186) at org.objectweb.jotm.TransactionImpl.enlistResource(TransactionImpl.java:432) at com.rauser_ag.transaction.file.XAFileResourceTestCase.testCreateCommit (XAFileResourceTestCase.java:93) In this case it is the Xid I have no influence on. But even without XA stuff you can run into this issue as you allow an arbitrary Object as id. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] transactional file access
Hello, I saw that commons transaction provides an implementation of transactional file access and an abstract implementation of javax.transaction.xa.XAResource. Now I wonder why these two are not combined and the transactional file access implementation does not exist as a XAResource. Is it so difficult, such a huge step forward? Or was there just nobody missing it? I might have some need for it ... Thanks, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] transactional file access
Oliver Zeigermann oliver.zeigermann at gmail.com writes: I do not think it should be too difficult, but what would be the real benefit? The XA resource would store files locally only and a real 2 phase commit does not work with the transactional file system. I guess it is less a question of correct working than of integration. We have the need to run database updates, to execute Corba services and to modify the filesystem in transactions. From what I get (it's my first real contact with transactions not limited to databases) most of the TransactionManagers are based on Sun's JTA which is again based on the XA specification. So wrapping an existent transactional file access within a XAResource would be the simplest way to go, wouldn't it? Anyway, if you have a decent running implementation of that and want to donate it to the commons transaction project, I'd be my pleasure to add it. Not yet :) Jörg 2005/10/28, Joerg Heinicke joerg.heinicke at gmx.de: I saw that commons transaction provides an implementation of transactional file access and an abstract implementation of javax.transaction.xa.XAResource. Now I wonder why these two are not combined and the transactional file access implementation does not exist as a XAResource. Is it so difficult, such a huge step forward? Or was there just nobody missing it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bug 36261] - [jci] no class could be loaded after a compilation error occured
Any suggestion how to handle that otherwise? Continueing this topic in the other thread 'Handling compilation errors': http://marc.theaimsgroup.com/?t=11245564832r=1w=4 Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] Handling compilation errors
Torsten Curdt tcurdt at apache.org writes: (BTW, this use case shows a different lifecycle for the handler and is another signal for removing lifecycle specific stuff from the handler interface.) Well, to me it's a clear example why a lifecycle would make sense! Of course, but it is a different lifecycle (reset on retrieving the errors) than for the simple error counter I sent in the patch (reset on beginning a compilation) or the loggers (no reset at all). If you don't want to ignore the different lifecycles (by mapping them to one, don't know if it is really possible) you have to address them all. And there are more conceivable than the mentioned ones. (copied from other thread: http://marc.theaimsgroup.com/?l=jakarta-commons-devm=112475150924518w=4) One of the problems I see here is that the compilers *does* need information like an error count. Removing it from the interface does sound clean in the first place ...but it clearly violates the KISS principle. At the moment it is just the CompilingListener as far as I see. And it does not even need a count, a boolean switch error occured would be sufficient. The use case of Don also does not need a count, it just needs a container (probably a list) for the compilation errors. Let's come to cleanliness vs. KISS. Where does the removal of the counting stuff violate KISS? The CompilingListener is the one to be informed about occured errors. So why should it not be the one to reset the error counter when it is no longer interested in the older errors, but wants to start next compilation cycle? And why should it not register a CompilationProblemHandler that does exactly that job? But if the CompilingListener registers the CPH and handles its lifecycle there is no need to add the lifecycle methods to the interface. So KISS is more about holding the interface clean and simple. For the integration into web frameworks: Do you need the CompilingClassLoader? Isn't the Compiler sufficient? At least for XSP in Cocoon the reload is handled by Cocoon. Which is actually bad bad bad! We had major problems with that. The lastmodified check is a big performance bottleneck. If you go for a synchronous check you would have to check it on every request. We worked around that by caching it for a certain amount of time. Beforehand XSP pages did just not scale. An asynchronous approach will help with the SoC and scaleability. ...implementation that with XSP turned out to be no piece of cake and noone ended up doing it. IIRC there was a discussion with Berin long long(!) time ago. Probably before my time ;-) Ok, I see your point. But XSP actually works still synchron, doesn't it? Do you want to switch it? Or are your integration efforts more about the general CompilingClassLoader and javaflow stuff? Regards, Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] Handling compilation errors
Torsten Curdt tcurdt at apache.org writes: I think we are facing two questions: 1. Keep the ProblemHandler across compilations (and add a lifecycle) or re-create the object Hmm, this also depends :) For the error counter there is no problem to create one on every compilation cycle. But for the external ones passed as parameter you might want to use always the same. But probably this can be hidden in a ProblemHandlerFactory with a method getProblemHandler(). This would also externalize the lifecycle handling - which is what I would like to see ;) 2. Is there really a usecase where you don't need the compilation result in a ProblemHandler? I don't know if I understand the question correctly, but a ProblemHandler not handling problems makes no sense. But a ProblemHandler might not store the result of the complete compilation cycle, but handle the problems immediately like the loggers. The CompilingListener is the one to be informed about occured errors. So why should it not be the one to reset the error counter when it is no longer interested in the older errors, but wants to start next compilation cycle? Exactly! (Did you switch sides? ;) Not that I was aware of :) The CL would call reset/clear on the handler. My reasoning here was if the CL instantiates its handler it also knows the type of it and can handle its specific lifecycle. ErrorCounter counter = new ErrorCounter(); // implements CPH interface ... counter.reset(); compile(.., counter); Another idea would be to keep the compilation result inside the CompilingListener and just delegate problems to the external ProblemHandler. Not sure if I like that though. Me too. Probably before my time Ok, I see your point. But XSP actually works still synchron, doesn't it? Yes ..as I said - we worked around that restriction by caching the access. Ok, and in the rest of Cocoon? Isn't lastmodified used nearly everywhere? Or is just the consequence: the compilation process. Do you want to switch it? Or are your integration efforts more about the general CompilingClassLoader and javaflow stuff? Well, it came to mind ...but I don't think I would do it. I am not using XSP anymore. Most people consider it more or less legacy now anyway. So why change what's not broken. Exactly. I just wondered. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] Handling compilation errors
Torsten Curdt tcurdt at apache.org writes: 1. Keep the ProblemHandler across compilations (and add a lifecycle) or re-create the object Hmm, this also depends :) For the error counter there is no problem to create one on every compilation cycle. You mean create counter object?? Yes. But for the external ones passed as parameter you might want to use always the same. Which is why you need to reset it which means a lifecycle. Yes, I didn't speak against lifecycle. Only against *one* lifecycle in the interface. And handling different lifecycles in the interface gets difficult or confusing IMO. Somehow I got the feeling we are a bit running round in circles here. So let's break the circles. From what I see we see the same requirements but only draw different conclusions. 2. Is there really a usecase where you don't need the compilation result in a ProblemHandler? I don't know if I understand the question correctly, but a ProblemHandler not handling problems makes no sense. It does handle the problem ...but a name like ProblemConsumer would probably make more sense. Yes, ok, but this has no implication on the deliberation. YOU ALWAYS NEED THE COMPILATION RESULT ...and that's my point. Yes, otherwise you would not need a handler/consumer. Sorry for exasperating you :) Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] Handling compilation errors
Don Brown donald.brown at gmail.com writes: As I integrate jci into Struts Ti, I'm faced with how to display the compilation errors to the user. What general strategy does Cocoon or any other web framework use to do this? The asynchronous nature of the compiler makes it difficult to display the errors to the user the next time the refresh their browser. Do you just assume they will be tailing the logs? Is there any way to manually control the file monitor check so, for example, a refresh of the browser would trigger the check and compilation so the errors could simply be displayed on the page returned to the browser? Hello Don, do you really want to show compiler errors to the user? If so, you can pass a problem handler that consumes the problems up to a refresh of a page. For this refresh the problem handler is asked for the problems and they are passed to the view. After getting the problems from the handler it can be resetted or cleared. (BTW, this use case shows a different lifecycle for the handler and is another signal for removing lifecycle specific stuff from the handler interface.) For the integration into web frameworks: Do you need the CompilingClassLoader? Isn't the Compiler sufficient? At least for XSP in Cocoon the reload is handled by Cocoon. I'm going to provide a JCI implementation for the LanguageCompiler interface (used in XSP), but probably not in the next two weeks. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] Handling compilation errors
My use case is a development mode for Struts Ti. One of the key features I'm going for in this mode is the ability to modify the source code, the refresh your browser to see the changes. For example, if the user added an action method, but they made a typo that would cause the compilation to fail, when they refreshed their browser, they'd see a helpful error page detailing all the compilation errors and code snippets where the error came from. To do this, I'd imagine I need the ability to manually initiate a file system check for new/modified/removed files on every web request. After all the changed files are finished compiling, I could pull out the errors from my problem handler and generate a web page. The CompilingClassLoader runs only in asynchron mode. You only have the chance of a problem handler with a specific lifecycle as I wrote: do you really want to show compiler errors to the user? If so, you can pass a problem handler that consumes the problems up to a refresh of a page. For this refresh the problem handler is asked for the problems and they are passed to the view. After getting the problems from the handler it can be resetted or cleared. If you need sychron mode you need to write something yourself wrapping just the compilers, e.g. a SynchronCompilingClassLoader. Former versions of CCL were synchron, maybe you can take just an older revision. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jci][fyi] JSR 199: Sun's JCI?
http://www.cafeaulait.org/oldnews/news2005August17.html JSR 199 seems to be nearly three years old. Not much result to see :-) Their analogy to the CompilationProblem handling: a DiagnosticListener (like our CompilationProblemHandler) with just one method problemFound(DiagnosticMessage) with DiagnosticMessage being really similar to CompilationProblem. Instead of isError() it has a getKind() which allows finer handling. Another interesting interface might be JavaFileObject hiding the details of accessing resources. Though JCI has ResourceReader and ResourceStore it is not really detached from file system. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci][fyi] JSR 199: Sun's JCI?
Torsten Curdt tcurdt at apache.org writes: Another interesting interface might be JavaFileObject hiding the details of accessing resources. Though JCI has ResourceReader and ResourceStore it is not really detached from file system. Huh? Why not? The memory implementations don't care much of the file system :-P That was one of the main goal of JCI. Yes and that's fine. But search for the String.replace(char, char) method and you know what I mean :-) There are many places where class names are converted to file names and back. It's not only the FileResourceStore. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
resource names vs. file names (was: [jci][fyi] JSR 199: Sun's JCI?)
Torsten Curdt tcurdt at apache.org writes: Huh? Why not? The memory implementations don't care much of the file system :-P That was one of the main goal of JCI. Yes and that's fine. But search for the String.replace(char, char) method and you know what I mean There are many places where class names are converted to file names and back. It's not only the FileResourceStore. These are converting between class names and resource names! Which is fine! Ah, ok. I should not talk that loud before looking exactly ;-) I had again a look into the sources. One naming that might give wrong impression is the parameter name of the methods in ResourceReader: final String filename. Another point is the FileResourceStore. The patch I sent in to get rest of Java world-filenames was a step in the wrong direction. The stores should store the resources by their resource name, not the class name. This would also solve the inconsistency for non-to-be-compiled resources I mentioned in the bug description. This needs some adaptions in certain places (ResourceStoreClassLoader, compilers), but the handling would be consistent afterwards. WDYT? Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bug 36261] - [jci] no class could be loaded after a compilation error occured
http://issues.apache.org/bugzilla/show_bug.cgi?id=36261 wait a sec ...let's discuss that on the list first. while I agree that it makes sense to remove the counting from the problem handler interface I am not too sure I like the other changes too much. Off-list you talked about possibly introducing a lifecycle to the CompilationProblemHandler. IMO their purpose is to different to get a common lifecycle. Many purposes do not even need a lifecycle at all (e.g. logging the compilation problems, or (as in my adapter to XSP) delegating the problem to Cocoon. The so-called CompilationProblemCounter (in the patch) is a special case for the CompilingListener, so the CL should also care about its lifecycle, not the compilers. There are even other lifecycles conceivable - shall the compilers manage all of them? I have the Avalon interfaces in mind ... ;-) At the end this means I like the idea of having a most simple CompilationProblemHandler interface with just the one method (also as in the DiagnosticListener of JSR 199). The classes registering the handlers have to care about the rest, they know their purpose. Remains the question of passing the handlers to the compilers. Passing a factory is not possible I think as the registering classes might need access to the handlers like the CompilingListener needs to reset the error counter. At the end I come back to my patch - with details debatable of course ;-) WDYT? Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bug 36261] - [jci] no class could be loaded after a compilation error occured
http://issues.apache.org/bugzilla/show_bug.cgi?id=36261 wait a sec ...let's discuss that on the list first. while I agree that it makes sense to remove the counting from the problem handler interface I am not too sure I like the other changes too much. We could also make use of a factory pattern here. And instead of a CPHandler instance you pass a CPHandlerFactory? Sounds good. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] initial compiling
Torsten Curdt tcurdt at apache.org writes: I have a problem with loading a class immediately after the setup of the CompilingClassLoader. With a setup like in the TestCases using a signal object it does not work (I get ClassNotFoundException), because the CCL does release a reload() event immediately after setup - before my files have been compiled. Why would you expect the classes be available right away? It's an asynchronous process. But maybe explain your environment a bit more. That's absolutely clear. I have a setup like in the TestCases with a signal object waiting for the reload signal. But the first reload signal is released by the CCL itself without waiting for the compiling. And IMO this is wrong. If the files are already on disk the start of the CL should start the fam that will trigger the compilation after the first run. Yes, it does. But at the same time it releases a hasReloaded event - before it is actually setup correctly. The hasReloaded notification should happen after the compilation has finished and your classes should be available after that. As I wrote above the first hasReloaded happens already by the CCL itself at the end of its start() method. The second hasReloaded is the one to go at the moment. But this looks more like a bug than a reliable feature. Please try the latest version and report back. I did some substantial changes over the weekend. Still the same like on Friday. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jci] JaninoJavaCompiler and other issues
Hello, today I came across an issue with the Janino version 2.3.3 in use in JCI. It does not find static methods in classes. After an update to 2.3.8 (which unfortunately needs adaptions in JaninoJavaCompiler the compilation of my classes work again. Is there any interest in this update to JCI codebase? Next issue is triggered by this update to 2.3.8. We also use Janino for XSP compilation in Cocoon, which also did no longer work after the update to 2.3.8. I made the changes and now please let me point out the issues mentioned in the subject. The class is actually an implementation of Cocoon's LanguageCompiler interface and a wrapper around JaninoJavaCompiler. 1. The LanguageCompiler interface has a method setEncoding(String). Unfortunately I can not propagate the param to JaninoJavaCompiler, because the value is not parameterizable there, but hard-coded. 2. The CompilationProblem class has nice field storing e.g. location information. Unfortunately there is no access to these fields, just a toString() method. But the class CompilerError in Cocoon would like to see these informations. Would it be possible to add public getters to CompilationProblem? 3. The CompilationProblem is a nice abstraction, but isn't it somewhat limited? Both Eclipse and Janino provide more information than CompilationProblem can accept. Wouldn't it be better to convert CompilationProblem to an interface and create class like EclipseCompilationProblem and JaninoCompilationProblem being wrappers for the original problem/exception classes? So like in my case where I know that the CompilationProblem should be an instance of a JaninoCompilationProblem I can react more specifically (e.g. accessing the column number of the problem). WDYT? Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] JaninoJavaCompiler and other issues
After an update to 2.3.8 (which unfortunately needs adaptions in JaninoJavaCompiler the compilation of my classes work again. Is there any interest in this update to JCI codebase? Of course! ...what a question ;) There is just the problem of the incompatible change, i.e. JCI does no longer work with Janino versions below 2.3.4. But this might be a minor issue as long as JCI has not been released. Next issue is triggered by this update to 2.3.8. We also use Janino for XSP compilation in Cocoon, ..as well as the eclipse compiler - I know ;) Yes, but this one works OOTB without JCI ;) The class is actually an implementation of Cocoon's LanguageCompiler interface and a wrapper around JaninoJavaCompiler. Why not create a JciCompiler implementation of the LanguageCompiler interface? It could act as a factory. The implementation could be passed in through the component configuration. Ah, of course, that's most consistent. Will look into it tonight I can do some of the work too and send in some patches if you like. I will see what you have managed tonight. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jci] initial compiling
Hello, I have a problem with loading a class immediately after the setup of the CompilingClassLoader. With a setup like in the TestCases using a signal object it does not work (I get ClassNotFoundException), because the CCL does release a reload() event immediately after setup - before my files have been compiled. Removing the reload() from the last line of start() in the CCL seems to be the correct way. The CCL is waiting for the CompilingListener then and does release a reload() event after compiling is finished. The problem seems to be an initial empty directory, because in this case the CompilingListener does not release the reload() event. But with the two reload()s I can not distinct between the events (just wait for the second reload() sounds not really reliable). So I need either access to the CompilingListener to get informed about the finished compiling or the reload() must send information about the type of event (like the ActionListeners in AWT). But IMO this should be fixed in the CompilingListener without the reload() in CCL as there is no difference in starting with an empty directory or later emptying a directory. Do I have missed something? WDYT? Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Bug 16429 Align the code base with checkstyle
Mike Bowler wrote: I've added a second patch to the bug which fixes more checkstyle warnings. I'm still not sure why the patches were being discarded from my emails this morning so I'm just playing it safe and putting them in bugzilla. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16429 Hi Mike, shouldn't this be the default? Not everybody reading the list needs all the patches, they increase only the list traffic. But everybody, who needs a patch before it's added to CVS, can get it from Bugzilla. Furthermore they couldn't get lost there. I definitely prefer Bugzilla instead of mail attachement. Regards, Joerg -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
