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]
[jira] Created: (VFS-169) Thrown exception reveals passwords
Thrown exception reveals passwords -- Key: VFS-169 URL: https://issues.apache.org/jira/browse/VFS-169 Project: Commons VFS Issue Type: Bug Affects Versions: 1.0 Reporter: Joerg Schaible If an exception occurs accessing a FileObject on a FileSystem that is addressed with an URL containing user and password the thrown exception contains the password as part of the error message: org.apache.commons.vfs.FileSystemException: Could not connect to SFTP server at sftp://user:[EMAIL PROTECTED]/. In such a case the URL should be printed as sftp://user:[EMAIL PROTECTED]/. Same applied to log messages - at least for INFO and higher. This is a security risk, since in big companies exceptions and logs are normally collected and archived in monitoring systems and may reveal the password to persons that have normally no authorization to the target system. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
[ https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511709 ] Joerg Schaible commented on LOGGING-114: IMHO this is really a JCL problem. It detects log4j and tries to use it. It is fine that it searches for something else if log4j is not present. But here it even suppresses a thrown Error that indicates also a problem for JCL. From user's PoV either the presence of log4j was not expected at all, he failed to configure to Log4J or he failed to configure JCL. In any case he must realize that something is not working as expected. Silent Swallowing of NoClassDefFoundError - Key: LOGGING-114 URL: https://issues.apache.org/jira/browse/LOGGING-114 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Environment: Various OSs, in combination with log4j 1.2.14. Reporter: Malcolm Cleaton Priority: Minor Hi. I'm using commons logging with log4j; my team ship a library which uses log4j, and some of our clients use it with commons-logging. If commons-logging is in its default configuration, and log4j is present but fails to load its configuration with an unhandled exception, the results are pretty nasty: - commons-logging silently swallows the exception and logs with something else. If diagnostics are turned on, the message is: Could not instantiate Log 'org.apache.commons.logging.impl.Log4JLogger' -- java.lang.reflect.InvocationTargetException: null - future attempts to use log4j directly get a pretty unhelpful error: java.lang.NoClassDefFoundError at org.apache.log4j.Logger.getLogger(Logger.java:117). I realise you're trying to deal with a very large number of cases in this code, but it does seem like something better could be done here. If nothing else is possible, at least recognising the InvocationTargetException and pulling out the target exception for the diagnostic log would have helped with tracking this one down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-284) ability to read OS environment variables
[
https://issues.apache.org/jira/browse/CONFIGURATION-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510608
]
Joerg Schaible commented on CONFIGURATION-284:
--
Interpolation for system properties is already available, simply set up your
configuration properly:
{code:java}
final CompositeConfiguration configuration = new
CompositeConfiguration();
// system properties override every setting
configuration.addConfiguration(ConfigurationConverter.getConfiguration(System.getProperties()));
// add other configuration instances here
{code}
ability to read OS environment variables
Key: CONFIGURATION-284
URL: https://issues.apache.org/jira/browse/CONFIGURATION-284
Project: Commons Configuration
Issue Type: New Feature
Components: Interpolation
Reporter: Aksel Schmidt
Priority: Minor
suggestion:
interpolation with system environment, i.e.
${sys:user.name} reads from systemproperties (as of today)
${sysenv:TEMP} reads from OS environment
these can be parsed from a supported set of OS's - windows read from a set in
a cmd /c, unix/linux from an env etc. (just once on demand)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (CONFIGURATION-284) ability to read OS environment variables
[
https://issues.apache.org/jira/browse/CONFIGURATION-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510608
]
Joerg Schaible edited comment on CONFIGURATION-284 at 7/6/07 12:08 AM:
---
Interpolation for system properties is already available, simply set up your
configuration properly:
{noformat}
final CompositeConfiguration configuration = new CompositeConfiguration();
// system properties override every setting
configuration.addConfiguration(ConfigurationConverter.getConfiguration(System.getProperties()));
// add other configuration instances here
{noformat}
was:
Interpolation for system properties is already available, simply set up your
configuration properly:
{code:java}
final CompositeConfiguration configuration = new
CompositeConfiguration();
// system properties override every setting
configuration.addConfiguration(ConfigurationConverter.getConfiguration(System.getProperties()));
// add other configuration instances here
{code}
ability to read OS environment variables
Key: CONFIGURATION-284
URL: https://issues.apache.org/jira/browse/CONFIGURATION-284
Project: Commons Configuration
Issue Type: New Feature
Components: Interpolation
Reporter: Aksel Schmidt
Priority: Minor
suggestion:
interpolation with system environment, i.e.
${sys:user.name} reads from systemproperties (as of today)
${sysenv:TEMP} reads from OS environment
these can be parsed from a supported set of OS's - windows read from a set in
a cmd /c, unix/linux from an env etc. (just once on demand)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
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]
[jira] Commented: (VFS-139) Fix javac 1.5 warnings
[ https://issues.apache.org/jira/browse/VFS-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495596 ] Joerg Schaible commented on VFS-139: Cast the null value. Fix javac 1.5 warnings -- Key: VFS-139 URL: https://issues.apache.org/jira/browse/VFS-139 Project: Commons VFS Issue Type: Improvement Affects Versions: 1.1 Reporter: Adam Heath Priority: Trivial Fix For: 1.1 Attachments: fix_java15-warnings.patch In java1.5, javac has support for varargs. It does this by auto-creating an array of the appropriate type, when a variable number of parameters are passed. However, in such cases, when a null is passed to such a method, it isn't completely sure how to proceed. Should it create an array with a single null value, or should it just pass the null value straight thru? In any event, the attached patch fixes it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - 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]
svn commit: r528701 - /jakarta/commons/proper/transaction/trunk/lib/
Author: joerg Date: Fri Apr 13 16:25:30 2007 New Revision: 528701 URL: http://svn.apache.org/viewvc?view=revrev=528701 Log: drop jars, dependencies are now fetched via build target download Removed: jakarta/commons/proper/transaction/trunk/lib/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r528704 - in /jakarta/commons/proper/transaction/trunk: build.properties.sample build.xml
Author: joerg
Date: Fri Apr 13 16:37:24 2007
New Revision: 528704
URL: http://svn.apache.org/viewvc?view=revrev=528704
Log:
integrate download target into build,
expect all dependencies to be in lib.dir
Modified:
jakarta/commons/proper/transaction/trunk/build.properties.sample
jakarta/commons/proper/transaction/trunk/build.xml
Modified: jakarta/commons/proper/transaction/trunk/build.properties.sample
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/build.properties.sample?view=diffrev=528704r1=528703r2=528704
==
Binary files - no diff available.
Modified: jakarta/commons/proper/transaction/trunk/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/build.xml?view=diffrev=528704r1=528703r2=528704
==
--- jakarta/commons/proper/transaction/trunk/build.xml (original)
+++ jakarta/commons/proper/transaction/trunk/build.xml Fri Apr 13 16:37:24 2007
@@ -75,15 +75,8 @@
property name=dist.lib value=${dist.dir}/lib/
property name=dist.deploy value=${dist.dir}/deploy/
- property name=jta.jar
value=${lib.dir}/geronimo-jta_1.0.1B_spec-1.1.1.jar/
- property name=jca.jar
value=${lib.dir}/geronimo-j2ee-connector_1.5_spec-1.1.1.jar/
- property name=servlet.jar
value=${lib.dir}/geronimo-servlet_2.4_spec-1.1.1.jar/
-
path id=classpath
pathelement location=${build.classes} /
-pathelement location=${jta.jar}/
-pathelement location=${jca.jar}/
-pathelement location=${servlet.jar}/
fileset dir=${lib.dir}/
/path
@@ -102,9 +95,9 @@
equals arg1=${ant.java.version} arg2=1.6/
/or
/condition
-available property=jta.present classname=javax.transaction.Status
classpath=${jta.jar}/
-available property=jca.present
classname=javax.resource.cci.Connection classpath=${jca.jar}/
-available property=servlet.present classname=javax.servlet.Servlet
classpath=${servlet.jar}/
+available property=jta.present classname=javax.transaction.Status
classpathref=classpath/
+available property=jca.present
classname=javax.resource.cci.Connection classpathref=classpath/
+available property=servlet.present classname=javax.servlet.Servlet
classpathref=classpath/
echo message=+---/
echo message=| Build environment for ${name} ${version}/
echo message=| /
@@ -162,6 +155,7 @@
mkdir dir=${build.classes}/
mkdir dir=${build.lib}/
mkdir dir=${build.deploy}/
+mkdir dir=${lib.dir}/
/target
!--
@@ -183,7 +177,7 @@
===
--
- target name=build depends=prepare,detect description=Compiles the main
classes
+ target name=build depends=prepare,download,detect description=Compiles
the main classes
javac destdir=${build.classes}
source=${compile.source}
target=${compile.target}
@@ -518,9 +512,7 @@
!-- == Download Dependencies = --
- target name=download
-
-mkdir dir=${lib.dir}/
+ target name=download unless=dependencies.provided
echo message=Downloading Commons Codec jar.../
get dest=${lib.dir}/commons-codec-1.2.jar usetimestamp=true
ignoreerrors=true
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r528707 - in /jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction: memory/jca/MapXAResource.java util/xa/AbstractTransactionalResource.java
Author: joerg
Date: Fri Apr 13 16:46:37 2007
New Revision: 528707
URL: http://svn.apache.org/viewvc?view=revrev=528707
Log:
clean up, private fields
Modified:
jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapXAResource.java
jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/util/xa/AbstractTransactionalResource.java
Modified:
jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapXAResource.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapXAResource.java?view=diffrev=528707r1=528706r2=528707
==
---
jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapXAResource.java
(original)
+++
jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapXAResource.java
Fri Apr 13 16:46:37 2007
@@ -34,13 +34,12 @@
*/
public class MapXAResource extends AbstractXAResource {
-TransactionalMapWrapper map;
-LoggerFacade loggerFacade;
+private final TransactionalMapWrapper map;
+private LoggerFacade loggerFacade;
public MapXAResource(TransactionalMapWrapper map) {
-this.map = map;
// log important stuff to standard out as long as nothing else is
configured
-this.loggerFacade = new PrintWriterLogger(new PrintWriter(System.out),
WebDAVXAResource, false);
+this(map, new PrintWriterLogger(new PrintWriter(System.out),
MapXAResource, false));
}
public MapXAResource(TransactionalMapWrapper map, LoggerFacade
loggerFacade) {
@@ -57,7 +56,7 @@
}
public boolean isSameRM(XAResource xares) throws XAException {
-return (xares != null xares instanceof MapXAResource
map.equals(((MapXAResource) xares).map));
+return (xares instanceof MapXAResource
this.map.equals(((MapXAResource) xares).map));
}
public Xid[] recover(int flag) throws XAException {
@@ -65,7 +64,7 @@
}
public LoggerFacade getLoggerFacade() {
-return loggerFacade;
+return this.loggerFacade;
}
public void setLoggerFacade(LoggerFacade loggerFacade) {
@@ -73,11 +72,11 @@
}
protected void setLoggerFacade(PrintWriter out) {
-loggerFacade = new PrintWriterLogger(out, WebDAVXAResource, true);
+this.loggerFacade = new PrintWriterLogger(out, MapXAResource, true);
}
protected TransactionalResource createTransactionResource(Xid xid) throws
Exception {
-return new MapTransactionalResource(xid, map, getLoggerFacade());
+return new MapTransactionalResource(xid, this.map);
}
protected boolean includeBranchInXid() {
@@ -86,20 +85,17 @@
protected static class MapTransactionalResource extends
AbstractTransactionalResource {
-TransactionalMapWrapper map;
+private final TransactionalMapWrapper map;
private TransactionalMapWrapper.TxContext txContext = null;
-LoggerFacade loggerFacade;
-
-public MapTransactionalResource(Xid xid, TransactionalMapWrapper map,
LoggerFacade loggerFacade) {
+public MapTransactionalResource(Xid xid, TransactionalMapWrapper map) {
super(xid);
this.map = map;
-this.loggerFacade = loggerFacade;
}
public void commit() throws XAException {
try {
-map.commitTransaction();
+this.map.commitTransaction();
} catch (IllegalStateException e) {
throw new XAException(e.toString());
}
@@ -112,7 +108,7 @@
resume();
try {
-map.rollbackTransaction();
+this.map.rollbackTransaction();
} catch (IllegalStateException e) {
throw new XAException(e.toString());
}
@@ -124,25 +120,25 @@
if (isSuspended())
resume();
-if (map.isTransactionMarkedForRollback()) {
+if (this.map.isTransactionMarkedForRollback()) {
throw new XAException(XAException.XA_RBROLLBACK);
}
-return (map.isReadOnly() ? XA_RDONLY : XA_OK);
+return (this.map.isReadOnly() ? XA_RDONLY : XA_OK);
}
public void suspend() throws XAException {
if (isSuspended()) {
throw new XAException(XAException.XAER_PROTO);
}
-this.txContext = map.suspendTransaction();
+this.txContext = this.map.suspendTransaction();
}
public void resume() throws XAException {
if (!isSuspended()) {
throw new XAException(XAException.XAER_PROTO);
}
-map.resumeTransaction
svn commit: r528708 - /jakarta/commons/proper/transaction/trunk/build.properties.sample
Author: joerg
Date: Fri Apr 13 16:52:38 2007
New Revision: 528708
URL: http://svn.apache.org/viewvc?view=revrev=528708
Log:
properties set (it's a text file actually)
Modified:
jakarta/commons/proper/transaction/trunk/build.properties.sample
(contents, props changed)
Modified: jakarta/commons/proper/transaction/trunk/build.properties.sample
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/build.properties.sample?view=diffrev=528708r1=528707r2=528708
==
Binary files - no diff available.
Propchange: jakarta/commons/proper/transaction/trunk/build.properties.sample
--
svn:eol-style = native
Propchange: jakarta/commons/proper/transaction/trunk/build.properties.sample
('svn:mime-type' removed)
-
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]
svn commit: r520582 - /jakarta/commons/proper/transaction/trunk/maven.xml
Author: joerg Date: Tue Mar 20 13:56:08 2007 New Revision: 520582 URL: http://svn.apache.org/viewvc?view=revrev=520582 Log: Maven says: java:jar: [echo] java:jar is deprecated and will be removed. Please use jar:jar Modified: jakarta/commons/proper/transaction/trunk/maven.xml Modified: jakarta/commons/proper/transaction/trunk/maven.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/maven.xml?view=diffrev=520582r1=520581r2=520582 == --- jakarta/commons/proper/transaction/trunk/maven.xml (original) +++ jakarta/commons/proper/transaction/trunk/maven.xml Tue Mar 20 13:56:08 2007 @@ -14,7 +14,7 @@ See the License for the specific language governing permissions and limitations under the License. -- -project default=java:jar +project default=jar:jar xmlns:ant=jelly:ant xmlns:j=jelly:core - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r520583 - /jakarta/commons/proper/transaction/trunk/project.xml
Author: joerg
Date: Tue Mar 20 13:57:40 2007
New Revision: 520583
URL: http://svn.apache.org/viewvc?view=revrev=520583
Log:
at least Maven build works now with Geronimo spec jars from repository
Modified:
jakarta/commons/proper/transaction/trunk/project.xml
Modified: jakarta/commons/proper/transaction/trunk/project.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/project.xml?view=diffrev=520583r1=520582r2=520583
==
--- jakarta/commons/proper/transaction/trunk/project.xml (original)
+++ jakarta/commons/proper/transaction/trunk/project.xml Tue Mar 20 13:57:40
2007
@@ -25,7 +25,7 @@
shortDescriptionCommons Transaction/shortDescription
descriptionCommons Transaction/description
- currentVersion1.2-rc4/currentVersion
+ currentVersion1.3-dev/currentVersion
urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
packageorg.apache.commons.${pom.artifactId.substring(8)}/package
@@ -141,28 +141,19 @@
dependencies
dependency
- groupIdgeronimo-spec/groupId
+ groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-j2ee-connector_1.5_spec/artifactId
- version1.1/version
- properties
-scopeprovided/scope
- /properties
+ version1.1.1/version
/dependency
dependency
- groupIdgeronimo-spec/groupId
+ groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-jta_1.0.1B_spec/artifactId
- version1.1/version
- properties
-scopeprovided/scope
- /properties
+ version1.1.1/version
/dependency
dependency
- groupIdgeronimo-spec/groupId
+ groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-servlet_2.4_spec/artifactId
- version1.1/version
- properties
-scopeprovided/scope
- /properties
+ version1.1.1/version
/dependency
dependency
groupIdcommons-codec/groupId
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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)
Added:
jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.1.jar
(with props)
jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.1.jar
(with props)
jakarta/commons/proper/transaction/trunk/lib/geronimo-servlet_2.4_spec-1.1.1.jar
(with props)
Removed:
jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.jar
jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.pom
jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.jar
jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.pom
jakarta/commons/proper/transaction/trunk/lib/geronimo-servlet_2.4_spec-1.1.jar
jakarta/commons/proper/transaction/trunk/lib/geronimo-servlet_2.4_spec-1.1.pom
Modified:
jakarta/commons/proper/transaction/trunk/build.xml
Modified: jakarta/commons/proper/transaction/trunk/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/build.xml?view=diffrev=520602r1=520601r2=520602
==
--- jakarta/commons/proper/transaction/trunk/build.xml (original)
+++ jakarta/commons/proper/transaction/trunk/build.xml Tue Mar 20 14:15:48 2007
@@ -36,7 +36,7 @@
property name=compile.deprecation value=true /
property name=compile.optimize value=true /
- property name=version value=1.2-rc4/
+ property name=version value=1.3-dev/
property name=name value=commons-transaction /
property name=title value=Commons Transaction /
property name=package value=org.apache.commons.transaction /
@@ -74,9 +74,9 @@
property name=dist.lib value=${dist.dir}/lib/
property name=dist.deploy value=${dist.dir}/deploy/
- property name=jta.jar
value=${lib.dir}/geronimo-jta_1.0.1B_spec-1.1.jar/
- property name=jca.jar
value=${lib.dir}/geronimo-j2ee-connector_1.5_spec-1.1.jar/
- property name=servlet.jar
value=${lib.dir}/geronimo-servlet_2.4_spec-1.1.jar/
+ property name=jta.jar
value=${lib.dir}/geronimo-jta_1.0.1B_spec-1.1.1.jar/
+ property name=jca.jar
value=${lib.dir}/geronimo-j2ee-connector_1.5_spec-1.1.1.jar/
+ property name=servlet.jar
value=${lib.dir}/geronimo-servlet_2.4_spec-1.1.1.jar/
path id=classpath
pathelement location=${build.classes} /
Added:
jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.1.jar
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.1.jar?view=autorev=520602
==
Binary file - no diff available.
Propchange:
jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.1.jar
--
svn:mime-type = application/octet-stream
Added:
jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.1.jar
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.1.jar?view=autorev=520602
==
Binary file - no diff available.
Propchange:
jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.1.jar
--
svn:mime-type = application/octet-stream
Added:
jakarta/commons/proper/transaction/trunk/lib/geronimo-servlet_2.4_spec-1.1.1.jar
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/lib/geronimo-servlet_2.4_spec-1.1.1.jar?view=autorev=520602
==
Binary file - no diff available.
Propchange:
jakarta/commons/proper/transaction/trunk/lib/geronimo-servlet_2.4_spec-1.1.1.jar
--
svn:mime-type = application/octet-stream
-
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]
[jira] Commented: (CONFIGURATION-203) [configuration] Make Configuration Serializable
[ https://issues.apache.org/jira/browse/CONFIGURATION-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478222 ] Joerg Schaible commented on CONFIGURATION-203: -- You may consider implementing the writeReplace method. This allows you to serialize every Configuration into a tailored version especially designed for serialization. You may even have different impls e.g. a different one for hierarchical configs. However, some features like reloading do not make really sense for some sources ... what is a file URL really worth after serialization? [configuration] Make Configuration Serializable --- Key: CONFIGURATION-203 URL: https://issues.apache.org/jira/browse/CONFIGURATION-203 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.1 Environment: Operating System: other Platform: Other Reporter: Joe Wolf Priority: Minor Fix For: 1.5 It would be nice if org.apache.commons.configuration.Configuration extended java.io.Serializable and its implementations were serializable as well. Theoretically, most configurations are constructed from serialized data sources. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - 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]
[jira] Created: (IO-115) FileUtilsCleanDirectoryTestCase fails on Windoes if command chmod is available
FileUtilsCleanDirectoryTestCase fails on Windoes if command chmod is available -- Key: IO-115 URL: https://issues.apache.org/jira/browse/IO-115 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.3.1 Reporter: Joerg Schaible Fix For: 1.3.1 Some tests in FileUtilsCleanDirectoryTestCase try to delete files that have been set to read-only. This is expected to throw an exception. To set the read-only flag the method chmod() tries to execute the unix chmod command. If this fails (which should normally be the case on windows), the test is ignored. If Posix tools are available e.g. from Cygwin, MKS Toolkit, Microsoft's Posix Tools or similar ones the test fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-317) Enum Serialization - not backwards compatible
[ https://issues.apache.org/jira/browse/LANG-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1247 ] Joerg Schaible commented on LANG-317: - This has less to do with the JDK, but more with the compiler you're using. E.g. if you have compiled the class with Eclipse (it uses *always* the internal compiler and not the selected JDK's one) it will have a different serialVersionUID generated that the same class from the Sun compiler from the identical JDK. The only way to get them compatible is to define an own serialVersionUID. Enum Serialization - not backwards compatible - Key: LANG-317 URL: https://issues.apache.org/jira/browse/LANG-317 Project: Commons Lang Issue Type: Bug Affects Versions: 2.2 Environment: JDK 1.5 - JDK 1.4 Reporter: U. Klinkmüller Priority: Critical In our distributed application we have to deal with different environments. The server runs in a JDK 1.5 environment while some clients runs with JDK 1.4. In this scenario we get an error when we try to transfer the result object via RMI. The error message is: Exception:BusinessDelegatorComp.login() - connection error ocurred during loginCORBA MARSHAL 0x4942f89a No; nested exception is: org.omg.CORBA.MARSHAL: Unable to read value from underlying bridge : Mismatched serialization UIDs : Source (Rep. IDRMI:de.fraport.biaf.apm.user.UserRoleEnum:CBEF51ADA936FFFE:D100D6F29BD50386) = D100D6F29BD50386 whereas Target (Rep. ID RMI:de.fraport.biaf.apm.user.UserRoleEnum:CBEF51ADA936FFFE:D041682DA5693C42) = D041682DA5693C42 vmcid: IBM minor code: 89A completed: No The class causing this problem is derived from org.apache.commons.lang.enums.ValuedEnum. Aftre some recherches we found on http://people.apache.org/~bayard/ that there is a upcoming new release 2.3 of Commons-Lang. We saw that in this release a bug [LANG-286] has been fixed which seemed to be exactly our problem. We downloaded this version hopening that we can forget this problem. But unfortunately the problem still exists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (COMMONSSITE-14) ApacheCon advertisement does not work for Konqueror
ApacheCon advertisement does not work for Konqueror
---
Key: COMMONSSITE-14
URL: https://issues.apache.org/jira/browse/COMMONSSITE-14
Project: Commons All
Issue Type: Bug
Components: Site
Environment: Gentoo Linux, Konqueror 3.5.5
Reporter: Joerg Schaible
Priority: Minor
The ad for the ApacheCon is injected into the site by a style for the
leftColumn:
{code:css}
div#leftColumn {
color: #000;
background-color: #eee;
margin-left: 0px;
margin-top: 0px;
border-right: 1px solid #aaa;
border-bottom: 1px solid #aaa;
border-top: none;
border-left: none;
width: 150px;
background-image:url(http://www.apache.org/ads/ApacheCon/2007-europe-125x125.png);
background-repeat: no-repeat;
background-position: 50% 1%;
}
{code}
The image does not show up with Konqueror though, the space stays just empty
!navi.gif!
This does not
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COMMONSSITE-14) ApacheCon advertisement does not work for Konqueror
[
https://issues.apache.org/jira/browse/COMMONSSITE-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible updated COMMONSSITE-14:
--
Attachment: navi.gif
ApacheCon advertisement does not work for Konqueror
---
Key: COMMONSSITE-14
URL: https://issues.apache.org/jira/browse/COMMONSSITE-14
Project: Commons All
Issue Type: Bug
Components: Site
Environment: Gentoo Linux, Konqueror 3.5.5
Reporter: Joerg Schaible
Priority: Minor
Attachments: navi.gif
The ad for the ApacheCon is injected into the site by a style for the
leftColumn:
{code:css}
div#leftColumn {
color: #000;
background-color: #eee;
margin-left: 0px;
margin-top: 0px;
border-right: 1px solid #aaa;
border-bottom: 1px solid #aaa;
border-top: none;
border-left: none;
width: 150px;
background-image:url(http://www.apache.org/ads/ApacheCon/2007-europe-125x125.png);
background-repeat: no-repeat;
background-position: 50% 1%;
}
{code}
The image does not show up with Konqueror though, the space stays just empty
!navi.gif!
This does not
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-318) HashCodeBuilderTest and ToStringBuilderTest fail with IBM JDK 1.4.2
HashCodeBuilderTest and ToStringBuilderTest fail with IBM JDK 1.4.2
---
Key: LANG-318
URL: https://issues.apache.org/jira/browse/LANG-318
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.2
Environment: Gentoo Linux, IBM JDK 1.4.2_5
Reporter: Joerg Schaible
Priority: Minor
The IBM JDK 1.4.2 reports the declared fields of a class in reverse declaration
order. The tests are affected by this:
{noformat}
Testsuite: org.apache.commons.lang.builder.BuilderTestSuite
Tests run: 263, Failures: 8, Errors: 0, Time elapsed: 0,451 sec
Testcase:
testReflectionHierarchyHashCode(org.apache.commons.lang.builder.HashCodeBuilderTest):
FAILED
expected:11785967 but was:1276487
junit.framework.AssertionFailedError: expected:11785967 but was:1276487
at
org.apache.commons.lang.builder.HashCodeBuilderTest.testReflectionHierarchyHashCode(HashCodeBuilderTest.java:166)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testReflectionHashCodeExcludeFields(org.apache.commons.lang.builder.HashCodeBuilderTest):
FAILED
expected:862547 but was:865283
junit.framework.AssertionFailedError: expected:862547 but was:865283
at
org.apache.commons.lang.builder.HashCodeBuilderTest.testReflectionHashCodeExcludeFields(HashCodeBuilderTest.java:480)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testReflectionHierarchyArrayList(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:...elementData={null,null,null,null,null,null,null,null,null,null},size=0...
but
was:...size=0,elementData={null,null,null,null,null,null,null,null,null,null}...
junit.framework.ComparisonFailure:
expected:...elementData={null,null,null,null,null,null,null,null,null,null},size=0...
but
was:...size=0,elementData={null,null,null,null,null,null,null,null,null,null}...
at
org.apache.commons.lang.builder.ToStringBuilderTest.testReflectionHierarchyArrayList(ToStringBuilderTest.java:327)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testReflectionHierarchy(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:...a=a,transientA=t... but was:...transientA=t,a=a...
junit.framework.ComparisonFailure: expected:...a=a,transientA=t... but
was:...transientA=t,a=a...
at
org.apache.commons.lang.builder.ToStringBuilderTest.testReflectionHierarchy(ToStringBuilderTest.java:338)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testSelfInstanceTwoVarsReflectionObjectCycle(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:[EMAIL PROTECTED],otherType=The
Other Type... but was:...otherType=The Other
Type,[EMAIL PROTECTED]
junit.framework.ComparisonFailure:
expected:[EMAIL PROTECTED],otherType=The
Other Type... but was:...otherType=The Other
Type,[EMAIL PROTECTED]
at
org.apache.commons.lang.builder.ToStringBuilderTest.testSelfInstanceTwoVarsReflectionObjectCycle(ToStringBuilderTest.java:543)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testSimpleReflectionStatics(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:...String=staticString,staticInt=12345... but
was:...Int=12345,staticString=staticString...
junit.framework.ComparisonFailure:
expected:...String=staticString,staticInt=12345... but
was:...Int=12345,staticString=staticString
[jira] Created: (LANG-319) CharEncodingTest fails in IBM JDK 1.4.2
CharEncodingTest fails in IBM JDK 1.4.2 --- Key: LANG-319 URL: https://issues.apache.org/jira/browse/LANG-319 Project: Commons Lang Issue Type: Bug Affects Versions: 2.2 Environment: Gentoo Linux, IBM JDK 1.4.2_5 Reporter: Joerg Schaible Priority: Minor The test CharEncodingTest.testNotSupported tests with invalid character encodings. According the JDK docu of String(byte[], String) the JDK should throw in this case an java.lang.UnsupportedCharacterEncoding exception, but the IBM JDK 1.4.2 throws java.nio.charset.IllegalCharsetNameException. This is not an issue with IBM JDK 1.5.0_3 anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LANG-319) CharEncodingTest fails in IBM JDK 1.4.2
[ https://issues.apache.org/jira/browse/LANG-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible closed LANG-319. --- Resolution: Won't Fix Fix Version/s: 2.3 This is a JDK bug and we cannot catch the thrown exception, since it is only available in JDK 1.4+. CharEncodingTest fails in IBM JDK 1.4.2 --- Key: LANG-319 URL: https://issues.apache.org/jira/browse/LANG-319 Project: Commons Lang Issue Type: Bug Affects Versions: 2.2 Environment: Gentoo Linux, IBM JDK 1.4.2_5 Reporter: Joerg Schaible Assigned To: Joerg Schaible Priority: Minor Fix For: 2.3 The test CharEncodingTest.testNotSupported tests with invalid character encodings. According the JDK docu of String(byte[], String) the JDK should throw in this case an java.lang.UnsupportedCharacterEncoding exception, but the IBM JDK 1.4.2 throws java.nio.charset.IllegalCharsetNameException. This is not an issue with IBM JDK 1.5.0_3 anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-318) HashCodeBuilderTest and ToStringBuilderTest fail with IBM JDK 1.4.2
[
https://issues.apache.org/jira/browse/LANG-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471821
]
Joerg Schaible commented on LANG-318:
-
This is not an issue with IBM JDK 1.5.0_3 anymore.
HashCodeBuilderTest and ToStringBuilderTest fail with IBM JDK 1.4.2
---
Key: LANG-318
URL: https://issues.apache.org/jira/browse/LANG-318
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.2
Environment: Gentoo Linux, IBM JDK 1.4.2_5
Reporter: Joerg Schaible
Priority: Minor
The IBM JDK 1.4.2 reports the declared fields of a class in reverse
declaration order. The tests are affected by this:
{noformat}
Testsuite: org.apache.commons.lang.builder.BuilderTestSuite
Tests run: 263, Failures: 8, Errors: 0, Time elapsed: 0,451 sec
Testcase:
testReflectionHierarchyHashCode(org.apache.commons.lang.builder.HashCodeBuilderTest):
FAILED
expected:11785967 but was:1276487
junit.framework.AssertionFailedError: expected:11785967 but was:1276487
at
org.apache.commons.lang.builder.HashCodeBuilderTest.testReflectionHierarchyHashCode(HashCodeBuilderTest.java:166)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testReflectionHashCodeExcludeFields(org.apache.commons.lang.builder.HashCodeBuilderTest):
FAILED
expected:862547 but was:865283
junit.framework.AssertionFailedError: expected:862547 but was:865283
at
org.apache.commons.lang.builder.HashCodeBuilderTest.testReflectionHashCodeExcludeFields(HashCodeBuilderTest.java:480)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testReflectionHierarchyArrayList(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:...elementData={null,null,null,null,null,null,null,null,null,null},size=0...
but
was:...size=0,elementData={null,null,null,null,null,null,null,null,null,null}...
junit.framework.ComparisonFailure:
expected:...elementData={null,null,null,null,null,null,null,null,null,null},size=0...
but
was:...size=0,elementData={null,null,null,null,null,null,null,null,null,null}...
at
org.apache.commons.lang.builder.ToStringBuilderTest.testReflectionHierarchyArrayList(ToStringBuilderTest.java:327)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testReflectionHierarchy(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:...a=a,transientA=t... but was:...transientA=t,a=a...
junit.framework.ComparisonFailure: expected:...a=a,transientA=t... but
was:...transientA=t,a=a...
at
org.apache.commons.lang.builder.ToStringBuilderTest.testReflectionHierarchy(ToStringBuilderTest.java:338)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testSelfInstanceTwoVarsReflectionObjectCycle(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:[EMAIL PROTECTED],otherType=The
Other Type... but was:...otherType=The Other
Type,[EMAIL PROTECTED]
junit.framework.ComparisonFailure:
expected:[EMAIL PROTECTED],otherType=The
Other Type... but was:...otherType=The Other
Type,[EMAIL PROTECTED]
at
org.apache.commons.lang.builder.ToStringBuilderTest.testSelfInstanceTwoVarsReflectionObjectCycle(ToStringBuilderTest.java:543)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testSimpleReflectionStatics
[jira] Created: (LANG-320) LocaleUtilsTest fails with IBM JDK 1.5.0 because of false assuptions
LocaleUtilsTest fails with IBM JDK 1.5.0 because of false assuptions Key: LANG-320 URL: https://issues.apache.org/jira/browse/LANG-320 Project: Commons Lang Issue Type: Bug Affects Versions: 2.2 Reporter: Joerg Schaible LocaleUtilsTest.testLanguagesByCountry makes the assumption, that within the JDK there is only one language defined for GB: en. This is not true for the IBM JDK 1.5.0 that also knows about cy_GB i.e. Welsh. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-320) LocaleUtilsTest fails with IBM JDK 1.5.0 because of false assuptions
[ https://issues.apache.org/jira/browse/LANG-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471849 ] Joerg Schaible commented on LANG-320: - This test in special has not to do much with the vendor. Sun might deliver the cy_GB local with every new patch and then the test will fails also. LANG-318 is different though. LocaleUtilsTest fails with IBM JDK 1.5.0 because of false assuptions Key: LANG-320 URL: https://issues.apache.org/jira/browse/LANG-320 Project: Commons Lang Issue Type: Bug Affects Versions: 2.2 Reporter: Joerg Schaible LocaleUtilsTest.testLanguagesByCountry makes the assumption, that within the JDK there is only one language defined for GB: en. This is not true for the IBM JDK 1.5.0 that also knows about cy_GB i.e. Welsh. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DISCOVERY-10) Add jar target to commons-discovery build.xml
[ https://issues.apache.org/jira/browse/DISCOVERY-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466408 ] Joerg Schaible commented on DISCOVERY-10: - Hi Petteri, commons-discovery (as all other Jakarta commons components) will use now Maven 2 to build the package. That means any available build.xml will be generated by Maven and not edited manually. - Jörg Add jar target to commons-discovery build.xml - Key: DISCOVERY-10 URL: https://issues.apache.org/jira/browse/DISCOVERY-10 Project: Commons Discovery Issue Type: Bug Affects Versions: 0.4 Reporter: Petteri Räty Priority: Minor Fix For: Nightly Builds Attachments: commons-discovery-jar-target.patch I added the jar target so that you don't have to generate javadocs to be able to build the jar file. This is required to follow the Gentoo java packaging policy and is the most common build.xml target layout. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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]
svn commit: r495428 - in /jakarta/commons/proper/transaction/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/transaction/file/ResourceManager.java
Author: joerg Date: Thu Jan 11 15:21:34 2007 New Revision: 495428 URL: http://svn.apache.org/viewvc?view=revrev=495428 Log: revert commit 494203 / TRANSACTION-11 (http://marc.theaimsgroup.com/?t=11682925535r=1w=4) Modified: jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java Modified: jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt?view=diffrev=495428r1=495427r2=495428 == --- jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt (original) +++ jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt Thu Jan 11 15:21:34 2007 @@ -29,7 +29,6 @@ - Added functions to FileResourceManager for copying and moving resources. - Added possibility to append to (instead of overwriting) an existing resource with writeResource in FileResourceManager. - Added LoggerFacade implementation for Jakarta Commons Logging -- Added setDefaultTransactionTimeout() and reset() to ResourceManager (Jira issue TRANSACTION-11). BUGFIXES FROM 1.1 - Modified: jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java?view=diffrev=495428r1=495427r2=495428 == --- jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java (original) +++ jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java Thu Jan 11 15:21:34 2007 @@ -133,13 +133,6 @@ public boolean recover() throws ResourceManagerSystemException; /** - * Resets the store if applicable (optional operation). - * - * @throws UnsupportedOperationException if the codereset/code operation is not supported by this ResourceManager. - */ -public void reset(); - -/** * Gets the default isolation level as an integer. * The higher the value the higher the isolation. * @@ -210,15 +203,6 @@ */ public long getDefaultTransactionTimeout() throws ResourceManagerException; -/** - * Sets the default transaction timeout in milliseconds. - * - * @param mSecs default transaction timeout in milliseconds - * @throws ResourceManagerException if an error occured - * @see #getDefaultTransactionTimeout - */ -public void setDefaultTransactionTimeout(long mSecs) throws ResourceManagerException; - /** * Gets the transaction timeout of the specified transaction in milliseconds. * - 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]
svn commit: r494203 - in /jakarta/commons/proper/transaction/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/transaction/file/ResourceManager.java
Author: joerg Date: Mon Jan 8 13:41:21 2007 New Revision: 494203 URL: http://svn.apache.org/viewvc?view=revrev=494203 Log: TRANSACTION-11: Added setDefaultTransactionTimeout() and reset() to ResourceManager. Modified: jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java Modified: jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt?view=diffrev=494203r1=494202r2=494203 == --- jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt (original) +++ jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt Mon Jan 8 13:41:21 2007 @@ -29,6 +29,7 @@ - Added functions to FileResourceManager for copying and moving resources. - Added possibility to append to (instead of overwriting) an existing resource with writeResource in FileResourceManager. - Added LoggerFacade implementation for Jakarta Commons Logging +- Added setDefaultTransactionTimeout() and reset() to ResourceManager (Jira issue TRANSACTION-11). BUGFIXES FROM 1.1 - Modified: jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java?view=diffrev=494203r1=494202r2=494203 == --- jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java (original) +++ jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java Mon Jan 8 13:41:21 2007 @@ -133,6 +133,13 @@ public boolean recover() throws ResourceManagerSystemException; /** + * Resets the store if applicable (optional operation). + * + * @throws UnsupportedOperationException if the codereset/code operation is not supported by this ResourceManager. + */ +public void reset(); + +/** * Gets the default isolation level as an integer. * The higher the value the higher the isolation. * @@ -193,17 +200,27 @@ public void setIsolationLevel(Object txId, int level) throws ResourceManagerException; /** - * Gets the default transaction timeout. After this time expires and the concerned transaction - * has not finished - either rolled back or committed - the resource manager is allowed and - * also encouraged - but not required - to abort the transaction and to roll it back. + * Gets the default transaction timeout in milliseconds. + * After this time expires and the concerned transaction has not finished + * - either rolled back or committed - the resource manager is allowed and + * also encouraged - but not required - to abort the transaction and to roll it back. * - * @return default transaction timeout + * @return default transaction timeout in milliseconds * @throws ResourceManagerException if an error occured */ public long getDefaultTransactionTimeout() throws ResourceManagerException; /** - * Gets the transaction timeout of the specified transaction. + * Sets the default transaction timeout in milliseconds. + * + * @param mSecs default transaction timeout in milliseconds + * @throws ResourceManagerException if an error occured + * @see #getDefaultTransactionTimeout + */ +public void setDefaultTransactionTimeout(long mSecs) throws ResourceManagerException; + +/** + * Gets the transaction timeout of the specified transaction in milliseconds. * * @param txId identifier for the concerned transaction * @return transaction timeout of the specified transaction in milliseconds @@ -213,7 +230,7 @@ public long getTransactionTimeout(Object txId) throws ResourceManagerException; /** - * Sets the transaction timeout of the specified transaction. + * Sets the transaction timeout of the specified transaction in milliseconds. * * @param txId identifier for the concerned transaction * @param mSecs transaction timeout of the specified transaction in milliseconds - 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]
svn commit: r494275 - /jakarta/commons/proper/transaction/trunk/build.xml
Author: joerg
Date: Mon Jan 8 16:20:33 2007
New Revision: 494275
URL: http://svn.apache.org/viewvc?view=revrev=494275
Log:
follow hint of Ant:
[javac] The -source switch defaults to 1.5 in JDK 1.5 and 1.6.
[javac] If you specify -target 1.3 you now must also specify -source 1.3.
[javac] Ant will implicitly add -source 1.3 for you. Please change your build
file.
Modified:
jakarta/commons/proper/transaction/trunk/build.xml
Modified: jakarta/commons/proper/transaction/trunk/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/build.xml?view=diffrev=494275r1=494274r2=494275
==
--- jakarta/commons/proper/transaction/trunk/build.xml (original)
+++ jakarta/commons/proper/transaction/trunk/build.xml Mon Jan 8 16:20:33 2007
@@ -30,6 +30,7 @@
property file=${basedir}/build.properties/
+ property name=compile.source value=1.3 /
property name=compile.target value=1.3 /
property name=compile.debug value=true /
property name=compile.deprecation value=true /
@@ -183,6 +184,7 @@
target name=build depends=prepare,detect description=Compiles the main
classes
javac destdir=${build.classes}
+ source=${compile.source}
target=${compile.target}
debug=${compile.debug}
deprecation=${compile.deprecation}
@@ -194,6 +196,7 @@
target name=build-test depends=detect,build
javac destdir=${build.classes}
+ source=${compile.source}
target=${compile.target}
debug=${compile.debug}
deprecation=${compile.deprecation}
@@ -205,6 +208,7 @@
target name=build-jca depends=build if=java1.4.present
javac destdir=${build.classes}
+ source=${compile.source}
target=${compile.target}
debug=${compile.debug}
deprecation=${compile.deprecation}
@@ -216,6 +220,7 @@
target name=build-map-example depends=build-jca if=java1.4.present
javac destdir=${build.classes}
+ source=${compile.source}
target=${compile.target}
debug=${compile.debug}
deprecation=${compile.deprecation}
-
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]
svn commit: r493489 - in /jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file: DirectTransactionIdToPathMapper.java FileResourceManager.java NoOpTransactionIdToPathMa
Author: joerg
Date: Sat Jan 6 07:41:01 2007
New Revision: 493489
URL: http://svn.apache.org/viewvc?view=revrev=493489
Log:
before it gets released:
rename DirectTITPMapper to NoOpTITPMapper and really do nothing
(using toString() in the one direction and doing nothing in the other one was
somewhat inconsistent)
Added:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/NoOpTransactionIdToPathMapper.java
(with props)
Removed:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/DirectTransactionIdToPathMapper.java
Modified:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
Modified:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java?view=diffrev=493489r1=493488r2=493489
==
---
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
(original)
+++
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
Sat Jan 6 07:41:01 2007
@@ -1,10 +1,4 @@
/*
- * $Header:
/home/jerenkrantz/tmp/commons/commons-convert/cvs/home/cvs/jakarta-commons//transaction/src/java/org/apache/commons/transaction/file/FileResourceManager.java,v
1.6 2005/01/07 13:32:33 ozeigermann Exp $
- * $Revision$
- * $Date$
- *
- *
- *
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
@@ -19,9 +13,7 @@
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
- *
*/
-
package org.apache.commons.transaction.file;
import java.io.BufferedReader;
@@ -237,7 +229,7 @@
boolean urlEncodePath,
LoggerFacade logger,
boolean debug) {
-this(storeDir, workDir, urlEncodePath ? new URLEncodeIdMapper() :
null, new DirectTransactionIdToPathMapper(), logger, debug);
+this(storeDir, workDir, urlEncodePath ? new URLEncodeIdMapper() :
null, new NoOpTransactionIdToPathMapper(), logger, debug);
}
/**
Added:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/NoOpTransactionIdToPathMapper.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/NoOpTransactionIdToPathMapper.java?view=autorev=493489
==
---
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/NoOpTransactionIdToPathMapper.java
(added)
+++
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/NoOpTransactionIdToPathMapper.java
Sat Jan 6 07:41:01 2007
@@ -0,0 +1,36 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.transaction.file;
+
+/**
+ * Default implementation of [EMAIL PROTECTED] TransactionIdToPathMapper},
which expects
+ * transaction ids being strings and using them as path.
+ *
+ * @version $Id$
+ * @since 1.2
+ */
+public class NoOpTransactionIdToPathMapper implements
TransactionIdToPathMapper {
+
+public String getPathForId(Object txId) {
+return (String)txId;
+}
+
+public Object getIdForPath(String path) {
+return path;
+}
+
+}
Propchange:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/NoOpTransactionIdToPathMapper.java
--
svn:eol-style = native
-
To unsubscribe, 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]
svn commit: r493594 - in /jakarta/commons/proper/transaction/trunk: RELEASE-NOTES.txt lib/commons-logging-1.1.jar src/java/org/apache/commons/transaction/util/CommonsLoggingLogger.java
Author: joerg
Date: Sat Jan 6 15:25:25 2007
New Revision: 493594
URL: http://svn.apache.org/viewvc?view=revrev=493594
Log:
Added LoggerFacade implementation for Jakarta Commons Logging
Added:
jakarta/commons/proper/transaction/trunk/lib/commons-logging-1.1.jar
(with props)
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/CommonsLoggingLogger.java
(with props)
Modified:
jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt
Modified: jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt?view=diffrev=493594r1=493593r2=493594
==
--- jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt Sat Jan 6
15:25:25 2007
@@ -28,6 +28,7 @@
- Better error reporting in FileHelper when destination directories (moveRec)
or files (copyRec) could not be created
- Added functions to FileResourceManager for copying and moving resources.
- Added possibility to append to (instead of overwriting) an existing resource
with writeResource in FileResourceManager.
+- Added LoggerFacade implementation for Jakarta Commons Logging
BUGFIXES FROM 1.1
-
Added: jakarta/commons/proper/transaction/trunk/lib/commons-logging-1.1.jar
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/lib/commons-logging-1.1.jar?view=autorev=493594
==
Binary file - no diff available.
Propchange: jakarta/commons/proper/transaction/trunk/lib/commons-logging-1.1.jar
--
svn:mime-type = application/octet-stream
Added:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/CommonsLoggingLogger.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/CommonsLoggingLogger.java?view=autorev=493594
==
---
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/CommonsLoggingLogger.java
(added)
+++
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/CommonsLoggingLogger.java
Sat Jan 6 15:25:25 2007
@@ -0,0 +1,81 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.transaction.util;
+
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+
+/**
+ * @version $Id$
+ */
+public class CommonsLoggingLogger implements LoggerFacade {
+
+private final Log log;
+
+public CommonsLoggingLogger(final Log log) {
+this.log = log;
+}
+
+public LoggerFacade createLogger(final String name) {
+return new CommonsLoggingLogger(LogFactory.getLog(name));
+}
+
+public void logInfo(final String message) {
+ this.log.info(message);
+}
+
+public void logFine(final String message) {
+ this.log.debug(message);
+}
+
+public boolean isFineEnabled() {
+return this.log.isDebugEnabled();
+}
+
+public void logFiner(final String message) {
+ this.log.debug(message);
+}
+
+public boolean isFinerEnabled() {
+return this.log.isDebugEnabled();
+}
+
+public void logFinest(final String message) {
+ this.log.trace(message);
+}
+
+public boolean isFinestEnabled() {
+return this.log.isTraceEnabled();
+}
+
+public void logWarning(final String message) {
+ this.log.warn(message);
+}
+
+public void logWarning(final String message, final Throwable t) {
+ this.log.warn(message, t);
+}
+
+public void logSevere(final String message) {
+ this.log.error(message);
+}
+
+public void logSevere(final String message, final Throwable t) {
+ this.log.error(message, t);
+}
+
+}
Propchange:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util
svn commit: r493595 - /jakarta/commons/proper/transaction/trunk/lib/
Author: joerg Date: Sat Jan 6 15:34:47 2007 New Revision: 493595 URL: http://svn.apache.org/viewvc?view=revrev=493595 Log: 1.3 recompiled j2ee jars from Geronimo 1.1 including the POMs (actually I checked out the tagged versions from SVN, modified the POMs for getting 1.3 compiled JARs and added both POMs and JARs installed into my local repo to this lib dir) Added: jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.jar (with props) jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.pom (with props) jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.jar (with props) jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.pom (with props) jakarta/commons/proper/transaction/trunk/lib/geronimo-servlet_2.4_spec-1.1.jar (with props) jakarta/commons/proper/transaction/trunk/lib/geronimo-servlet_2.4_spec-1.1.pom (with props) Removed: jakarta/commons/proper/transaction/trunk/lib/geronimo-spec-j2ee-1.4-rc4.jar jakarta/commons/proper/transaction/trunk/lib/geronimo-spec-servlet-2.4-rc4.jar Added: jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.jar URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.jar?view=autorev=493595 == Binary file - no diff available. Propchange: jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.jar -- svn:mime-type = application/octet-stream Added: jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.pom URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.pom?view=autorev=493595 == --- jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.pom (added) +++ jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.pom Sat Jan 6 15:34:47 2007 @@ -0,0 +1,40 @@ +?xml version=1.0 encoding=UTF-8?project + parent +artifactIdspecs/artifactId +groupIdorg.apache.geronimo.specs/groupId +version1.2/version + /parent + modelVersion4.0.0/modelVersion + artifactIdgeronimo-j2ee-connector_1.5_spec/artifactId + nameJ2EE Connector 1.5/name + version1.1/version + scm + connectionscm:svn:https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-j2ee-connector_1.5_spec-1.1/connection + developerConnectionscm:svn:https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-j2ee-connector_1.5_spec-1.1/developerConnection + urlhttps://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-j2ee-connector_1.5_spec-1.1/url + /scm + build +plugins + plugin +artifactIdmaven-compiler-plugin/artifactId +configuration + verbosetrue/verbose + source1.3/source + target1.3/target + compilerVersion1.3/compilerVersion +/configuration + /plugin +/plugins + /build + dependencies +dependency + groupIdorg.apache.geronimo.specs/groupId + artifactIdgeronimo-jta_1.0.1B_spec/artifactId + version1.1/version + scopeprovided/scope +/dependency + /dependencies + distributionManagement +statusdeployed/status + /distributionManagement +/project \ No newline at end of file Propchange: jakarta/commons/proper/transaction/trunk/lib/geronimo-j2ee-connector_1.5_spec-1.1.pom -- svn:eol-style = native Added: jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.jar URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.jar?view=autorev=493595 == Binary file - no diff available. Propchange: jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.jar -- svn:mime-type = application/octet-stream Added: jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.pom URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.pom?view=autorev=493595 == --- jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.pom (added) +++ jakarta/commons/proper/transaction/trunk/lib/geronimo-jta_1.0.1B_spec-1.1.pom Sat Jan 6 15:34:47 2007 @@ -0,0 +1,32 @@ +?xml version=1.0 encoding=UTF-8?project + parent +artifactIdspecs/artifactId
svn commit: r493596 - in /jakarta/commons/proper/transaction/trunk/src/test/org/apache/commons/transaction: file/FileResourceManagerTest.java memory/MapWrapperTest.java memory/OptimisticMapWrapperTest
Author: joerg
Date: Sat Jan 6 15:37:31 2007
New Revision: 493596
URL: http://svn.apache.org/viewvc?view=revrev=493596
Log:
modified tests to use CommonsLoggingLogger to make tests work with JDK 1.3,
minor clean up (direct static access to constants + removed unused local
variables)
Modified:
jakarta/commons/proper/transaction/trunk/src/test/org/apache/commons/transaction/file/FileResourceManagerTest.java
jakarta/commons/proper/transaction/trunk/src/test/org/apache/commons/transaction/memory/MapWrapperTest.java
jakarta/commons/proper/transaction/trunk/src/test/org/apache/commons/transaction/memory/OptimisticMapWrapperTest.java
jakarta/commons/proper/transaction/trunk/src/test/org/apache/commons/transaction/memory/PessimisticMapWrapperTest.java
Modified:
jakarta/commons/proper/transaction/trunk/src/test/org/apache/commons/transaction/file/FileResourceManagerTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/test/org/apache/commons/transaction/file/FileResourceManagerTest.java?view=diffrev=493596r1=493595r2=493596
==
---
jakarta/commons/proper/transaction/trunk/src/test/org/apache/commons/transaction/file/FileResourceManagerTest.java
(original)
+++
jakarta/commons/proper/transaction/trunk/src/test/org/apache/commons/transaction/file/FileResourceManagerTest.java
Sat Jan 6 15:37:31 2007
@@ -1,10 +1,4 @@
/*
- * $Header:
/home/jerenkrantz/tmp/commons/commons-convert/cvs/home/cvs/jakarta-commons//transaction/src/test/org/apache/commons/transaction/file/FileResourceManagerTest.java,v
1.3 2005/01/13 01:34:25 ozeigermann Exp $
- * $Revision$
- * $Date$
- *
- *
- *
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
@@ -19,9 +13,7 @@
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
- *
*/
-
package org.apache.commons.transaction.file;
import java.io.BufferedReader;
@@ -32,7 +24,6 @@
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.OutputStream;
-import java.util.logging.Logger;
import javax.transaction.Status;
@@ -40,8 +31,11 @@
import junit.framework.TestCase;
import junit.framework.TestSuite;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+
+import org.apache.commons.transaction.util.CommonsLoggingLogger;
import org.apache.commons.transaction.util.FileHelper;
-import org.apache.commons.transaction.util.Jdk14Logger;
import org.apache.commons.transaction.util.LoggerFacade;
import org.apache.commons.transaction.util.RendezvousBarrier;
@@ -52,8 +46,8 @@
*/
public class FileResourceManagerTest extends TestCase {
-private static final Logger logger =
Logger.getLogger(FileResourceManagerTest.class.getName());
-private static final LoggerFacade sLogger = new Jdk14Logger(logger);
+private static final Log log =
LogFactory.getLog(FileResourceManagerTest.class.getName());
+private static final LoggerFacade sLogger = new CommonsLoggingLogger(log);
private static final String STORE = tmp/store;
private static final String WORK = tmp/work;
@@ -185,18 +179,6 @@
}
}
-private static final void deleteInDir(String dirPath, String[] fileNames) {
-File dir = new File(dirPath);
-
-if (dir.isDirectory()) {
-for (int i = 0; i fileNames.length; i++) {
-String fileName = fileNames[i];
-File file = new File(dir, fileName);
-file.delete();
-}
-}
-}
-
private static final void checkIsEmpty(String dirPath) {
checkExactlyContains(dirPath, null);
}
@@ -590,7 +572,7 @@
FileResourceManager.TransactionContext context = rm.getContext(txId);
// needing synchronization in order not to interfer with shutdown
thread
synchronized (context) {
-logger.fine(Committing Tx + txId);
+sLogger.logFine(Committing Tx + txId);
context.status = Status.STATUS_COMMITTING;
context.saveState();
@@ -629,7 +611,7 @@
}
public void testConflict() throws Throwable {
-logger.info(Checking concurrent transaction features);
+sLogger.logInfo(Checking concurrent transaction features);
reset();
createInitialFiles();
@@ -662,7 +644,7 @@
rm.commitTransaction(tx1);
} catch (InterruptedException ie) {
} catch (ResourceManagerException e) {
-assertEquals(e.getStatus
svn commit: r493599 - in /jakarta/commons/proper/transaction/trunk/src/java1.4: ./ org/ org/apache/ org/apache/commons/ org/apache/commons/transaction/ org/apache/commons/transaction/file/ org/apache/
Author: joerg Date: Sat Jan 6 15:44:06 2007 New Revision: 493599 URL: http://svn.apache.org/viewvc?view=revrev=493599 Log: first time svn-moving stuff around, hope it works: separated classes only compilable with JDK 1.4 and JCA stuff (due to javax.security.auth.Subject being only available in JDK 1.4) to extra src dir java1.4 Added: jakarta/commons/proper/transaction/trunk/src/java1.4/ jakarta/commons/proper/transaction/trunk/src/java1.4/org/ jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/ jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/ jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/ jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/file/ jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/ jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/util/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r493600 - in /jakarta/commons/proper/transaction/trunk/src: java/org/apache/commons/transaction/file/ java/org/apache/commons/transaction/memory/jca/ java/org/apache/commons/transaction/ut
Author: joerg Date: Sat Jan 6 15:44:26 2007 New Revision: 493600 URL: http://svn.apache.org/viewvc?view=revrev=493600 Log: first time svn-moving stuff around, hope it works: separated classes only compilable with JDK 1.4 and JCA stuff (due to javax.security.auth.Subject being only available in JDK 1.4) to extra src dir java1.4 Added: jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/file/JDK14URLEncodeIdMapper.java - copied unchanged from r493489, jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/JDK14URLEncodeIdMapper.java jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/ - copied from r490336, jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/memory/jca/ jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapConnection.java - copied unchanged from r493594, jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/memory/jca/MapConnection.java jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapConnectionFactory.java - copied unchanged from r493594, jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/memory/jca/MapConnectionFactory.java jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapConnectionSpec.java - copied unchanged from r493594, jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/memory/jca/MapConnectionSpec.java jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapLocalTransaction.java - copied unchanged from r493594, jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/memory/jca/MapLocalTransaction.java jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapManagedConnection.java - copied unchanged from r493594, jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/memory/jca/MapManagedConnection.java jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapManagedConnectionFactory.java - copied unchanged from r493594, jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/memory/jca/MapManagedConnectionFactory.java jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapXAResource.java - copied unchanged from r493594, jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/memory/jca/MapXAResource.java jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MemoryMapResourceManager.java - copied unchanged from r493594, jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/memory/jca/MemoryMapResourceManager.java jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/util/Jdk14Logger.java - copied unchanged from r490336, jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/Jdk14Logger.java Removed: jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/JDK14URLEncodeIdMapper.java jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/memory/jca/ jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/Jdk14Logger.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r493603 - in /jakarta/commons/proper/transaction/trunk/src: java/org/apache/commons/transaction/util/xa/ java1.4/org/apache/commons/transaction/util/xa/
Author: joerg Date: Sat Jan 6 15:52:35 2007 New Revision: 493603 URL: http://svn.apache.org/viewvc?view=revrev=493603 Log: nearly everything worked as expected, so next try: separated classes only compilable with JDK 1.4 and JCA stuff (due to javax.security.auth.Subject being only available in JDK 1.4) to extra src dir java1.4 Added: jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/util/xa/ - copied from r490336, jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/xa/ jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/util/xa/AbstractTransactionalResource.java - copied unchanged from r493600, jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/xa/AbstractTransactionalResource.java jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/util/xa/AbstractXAResource.java - copied unchanged from r493600, jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/xa/AbstractXAResource.java jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/util/xa/TransactionalResource.java - copied unchanged from r493600, jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/xa/TransactionalResource.java jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/util/xa/XidWrapper.java - copied unchanged from r493600, jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/xa/XidWrapper.java Removed: jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/xa/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r493604 - /jakarta/commons/proper/transaction/trunk/build.xml
Author: joerg
Date: Sat Jan 6 15:54:33 2007
New Revision: 493604
URL: http://svn.apache.org/viewvc?view=revrev=493604
Log:
finally the fixed build.xml
Modified:
jakarta/commons/proper/transaction/trunk/build.xml
Modified: jakarta/commons/proper/transaction/trunk/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/build.xml?view=diffrev=493604r1=493603r2=493604
==
--- jakarta/commons/proper/transaction/trunk/build.xml (original)
+++ jakarta/commons/proper/transaction/trunk/build.xml Sat Jan 6 15:54:33 2007
@@ -34,6 +34,7 @@
property name=src.dir value=${basedir}/src/
property name=java.dir value=${src.dir}/java/
+ property name=java14.dir value=${src.dir}/java1.4/
property name=test.dir value=${src.dir}/test/
property name=lib.dir value=${basedir}/lib/
property name=conf.dir value=${src.dir}/conf/
@@ -57,12 +58,14 @@
property name=dist.lib value=${dist.dir}/lib/
property name=dist.deploy value=${dist.dir}/deploy/
- property name=j2ee.jar value=${lib.dir}/geronimo-spec-j2ee-1.4-rc4.jar/
- property name=servlet.jar
value=${lib.dir}/geronimo-spec-servlet-2.4-rc4.jar/
+ property name=jta.jar
value=${lib.dir}/geronimo-jta_1.0.1B_spec-1.1.jar/
+ property name=jca.jar
value=${lib.dir}/geronimo-j2ee-connector_1.5_spec-1.1.jar/
+ property name=servlet.jar
value=${lib.dir}/geronimo-servlet_2.4_spec-1.1.jar/
path id=classpath
pathelement location=${build.classes} /
-pathelement location=${j2ee.jar}/
+pathelement location=${jta.jar}/
+pathelement location=${jca.jar}/
pathelement location=${servlet.jar}/
fileset dir=${lib.dir}/
/path
@@ -82,18 +85,9 @@
equals arg1=${ant.java.version} arg2=1.6/
/or
/condition
-condition property=j2ee.present
- and
-isset property=jvm14.present/
-available property=j2ee.present
classname=javax.resource.cci.Connection classpath=${j2ee.jar}/
- /and
-/condition
-condition property=servlet.present
- and
-isset property=jvm14.present/
-available property=j2ee.present classname=javax.servlet.Servlet
classpath=${servlet.jar}/
- /and
-/condition
+available property=jta.present classname=javax.transaction.Status
classpath=${jta.jar}/
+available property=jca.present
classname=javax.resource.cci.Connection classpath=${jca.jar}/
+available property=servlet.present classname=javax.servlet.Servlet
classpath=${servlet.jar}/
echo message=+---/
echo message=| Build environment for ${name} ${version}/
echo message=| /
@@ -103,35 +97,36 @@
echo message=+---/
echo message=/
echo message=Environment:/
-echo message= Java home ${java.home}/
-echo message= Java version ${ant.java.version}/
+echo message= Java home${java.home}/
+echo message= Java version
${ant.java.version}/
echo message=/
echo message=Build options:/
-echo message= Generate debugging info ${compile.debug}/
-echo message= Display deprecation info ${compile.deprecation}/
-echo message= Optimize ${compile.optimize}/
+echo message= Generate debugging info ${compile.debug}/
+echo message= Display deprecation info
${compile.deprecation}/
+echo message= Optimize
${compile.optimize}/
echo message=/
echo message=Directories:/
-echo message= Build directory ${build.dir}/
-echo message= Distribution directory${dist.dir}/
-echo message= JBoss deploy directory${jboss.deploy.dir}/
+echo message= Build directory ${build.dir}/
+echo message= Distribution directory ${dist.dir}/
+echo message= JBoss deploy directory
${jboss.deploy.dir}/
echo message=/
echo message=Optional Libraries:/
-echo message= J2EE API ${j2ee.present}/
-echo message= Servlet API ${servlet.present}/
-echo message= JVM 14${jvm14.present}/
+echo message= Java Transaction API ${jta.present}/
+echo message= J2EE Connection Architecture API ${jca.present}/
+echo message= Servlet API ${servlet.present}/
+echo message= JVM 14 ${jvm14.present}/
echo message=/
-property name=required.present value=true/
-!--condition property=required.present
+condition property=required.present
and
-equals arg1=${j2ee.present} arg2=true/
+equals arg1=${jta.present} arg2=true/
+equals arg1=${jca.present} arg2=true
svn commit: r493607 - /jakarta/commons/proper/transaction/trunk/project.xml
Author: joerg Date: Sat Jan 6 16:12:15 2007 New Revision: 493607 URL: http://svn.apache.org/viewvc?view=revrev=493607 Log: applied changes to dependencies (1.3 compiled j2ee jars) - but they don't exist in repository Modified: jakarta/commons/proper/transaction/trunk/project.xml Modified: jakarta/commons/proper/transaction/trunk/project.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/project.xml?view=diffrev=493607r1=493606r2=493607 == --- jakarta/commons/proper/transaction/trunk/project.xml (original) +++ jakarta/commons/proper/transaction/trunk/project.xml Sat Jan 6 16:12:15 2007 @@ -126,16 +126,24 @@ dependencies dependency groupIdgeronimo-spec/groupId - artifactIdgeronimo-spec-j2ee/artifactId - version1.4-rc4/version + artifactIdgeronimo-j2ee-connector_1.5_spec/artifactId + version1.1/version properties scopeprovided/scope /properties /dependency dependency groupIdgeronimo-spec/groupId - artifactIdgeronimo-spec-servlet/artifactId - version2.4-rc4/version + artifactIdgeronimo-jta_1.0.1B_spec/artifactId + version1.1/version + properties +scopeprovided/scope + /properties +/dependency +dependency + groupIdgeronimo-spec/groupId + artifactIdgeronimo-servlet_2.4_spec/artifactId + version1.1/version properties scopeprovided/scope /properties @@ -144,6 +152,11 @@ groupIdcommons-codec/groupId artifactIdcommons-codec/artifactId version1.2/version +/dependency +dependency + groupIdcommons-logging/groupId + artifactIdcommons-logging/artifactId + version1.1/version /dependency dependency groupIdlog4j/groupId - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r493614 - /jakarta/commons/proper/transaction/trunk/build.xml
Author: joerg
Date: Sat Jan 6 16:23:55 2007
New Revision: 493614
URL: http://svn.apache.org/viewvc?view=revrev=493614
Log:
consistent naming: directory name is java1.4, so changed java14 and jvm14 to
java1.4
Modified:
jakarta/commons/proper/transaction/trunk/build.xml
Modified: jakarta/commons/proper/transaction/trunk/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/build.xml?view=diffrev=493614r1=493613r2=493614
==
--- jakarta/commons/proper/transaction/trunk/build.xml (original)
+++ jakarta/commons/proper/transaction/trunk/build.xml Sat Jan 6 16:23:55 2007
@@ -34,7 +34,7 @@
property name=src.dir value=${basedir}/src/
property name=java.dir value=${src.dir}/java/
- property name=java14.dir value=${src.dir}/java1.4/
+ property name=java1.4.dir value=${src.dir}/java1.4/
property name=test.dir value=${src.dir}/test/
property name=lib.dir value=${basedir}/lib/
property name=conf.dir value=${src.dir}/conf/
@@ -78,7 +78,7 @@
target name=detect depends=detect.display,detect.fail
description=Display configuration and conditional compilation flags/
target name=detect.display
-condition property=jvm14.present
+condition property=java1.4.present
or
equals arg1=${ant.java.version} arg2=1.4/
equals arg1=${ant.java.version} arg2=1.5/
@@ -114,7 +114,7 @@
echo message= Java Transaction API ${jta.present}/
echo message= J2EE Connection Architecture API ${jca.present}/
echo message= Servlet API ${servlet.present}/
-echo message= JVM 14 ${jvm14.present}/
+echo message= Java 1.4 ${java1.4.present}/
echo message=/
condition property=required.present
and
@@ -188,18 +188,18 @@
/javac
/target
- target name=build-jca depends=build if=jvm14.present
+ target name=build-jca depends=build if=java1.4.present
javac destdir=${build.classes}
target=${compile.target}
debug=${compile.debug}
deprecation=${compile.deprecation}
optimize=${compile.optimize}
- src path=${java14.dir}/
+ src path=${java1.4.dir}/
classpath refid=classpath /
/javac
/target
- target name=build-map-example depends=build-jca if=jvm14.present
+ target name=build-map-example depends=build-jca if=java1.4.present
javac destdir=${build.classes}
target=${compile.target}
debug=${compile.debug}
-
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]
svn commit: r493628 [2/2] - in /jakarta/commons/proper/transaction/trunk: ./ example/mapConnector/src/conf/ example/mapConnector/src/java/connector/ lib/ src/conf/connector/map/ src/conf/connector/map
Modified:
jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/file/JDK14URLEncodeIdMapper.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/file/JDK14URLEncodeIdMapper.java?view=diffrev=493628r1=493627r2=493628
==
---
jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/file/JDK14URLEncodeIdMapper.java
(original)
+++
jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/file/JDK14URLEncodeIdMapper.java
Sat Jan 6 17:42:48 2007
@@ -1,10 +1,4 @@
/*
- * $Header:
/home/jerenkrantz/tmp/commons/commons-convert/cvs/home/cvs/jakarta-commons//transaction/src/java/org/apache/commons/transaction/file/JDK14URLEncodeIdMapper.java,v
1.2 2005/01/09 15:12:12 ozeigermann Exp $
- * $Revision$
- * $Date$
- *
- *
- *
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
@@ -19,9 +13,7 @@
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
- *
*/
-
package org.apache.commons.transaction.file;
import java.io.UnsupportedEncodingException;
@@ -29,7 +21,8 @@
/**
* URL encodes a resource id using JDK1.4 functionality.
- *
+ *
+ * @version $Id$
* @since 1.1
*/
public class JDK14URLEncodeIdMapper implements ResourceIdToPathMapper {
Modified:
jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapConnection.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapConnection.java?view=diffrev=493628r1=493627r2=493628
==
---
jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapConnection.java
(original)
+++
jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapConnection.java
Sat Jan 6 17:42:48 2007
@@ -1,10 +1,4 @@
/*
- * $Header:
/home/jerenkrantz/tmp/commons/commons-convert/cvs/home/cvs/jakarta-commons//transaction/src/java/org/apache/commons/transaction/memory/jca/MapConnection.java,v
1.1 2004/11/18 23:27:18 ozeigermann Exp $
- * $Revision$
- * $Date$
- *
- *
- *
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
@@ -19,9 +13,7 @@
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
- *
*/
-
package org.apache.commons.transaction.memory.jca;
import java.util.Map;
@@ -35,9 +27,7 @@
import javax.resource.spi.ManagedConnection;
/**
- *
- * @version $Revision$
- *
+ * @version $Id$
*/
public class MapConnection implements Connection {
Modified:
jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapConnectionFactory.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapConnectionFactory.java?view=diffrev=493628r1=493627r2=493628
==
---
jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapConnectionFactory.java
(original)
+++
jakarta/commons/proper/transaction/trunk/src/java1.4/org/apache/commons/transaction/memory/jca/MapConnectionFactory.java
Sat Jan 6 17:42:48 2007
@@ -1,10 +1,4 @@
/*
- * $Header:
/home/jerenkrantz/tmp/commons/commons-convert/cvs/home/cvs/jakarta-commons//transaction/src/java/org/apache/commons/transaction/memory/jca/MapConnectionFactory.java,v
1.1 2004/11/18 23:27:17 ozeigermann Exp $
- * $Revision$
- * $Date$
- *
- *
- *
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
@@ -19,9 +13,7 @@
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
- *
*/
-
package org.apache.commons.transaction.memory.jca;
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]
svn commit: r493632 - in /jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction: file/NoOpTransactionIdToPathMapper.java file/TransactionIdToPathMapper.java util/CommonsLogg
Author: joerg
Date: Sat Jan 6 17:57:31 2007
New Revision: 493632
URL: http://svn.apache.org/viewvc?view=revrev=493632
Log:
enable keyword replacement
Modified:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/NoOpTransactionIdToPathMapper.java
(props changed)
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/TransactionIdToPathMapper.java
(props changed)
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/CommonsLoggingLogger.java
(contents, props changed)
Propchange:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/NoOpTransactionIdToPathMapper.java
--
svn:keywords = Id
Propchange:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/TransactionIdToPathMapper.java
--
svn:keywords = Id
Modified:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/CommonsLoggingLogger.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/CommonsLoggingLogger.java?view=diffrev=493632r1=493631r2=493632
==
---
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/CommonsLoggingLogger.java
(original)
+++
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/CommonsLoggingLogger.java
Sat Jan 6 17:57:31 2007
@@ -21,6 +21,7 @@
/**
* @version $Id$
+ * @since 1.3
*/
public class CommonsLoggingLogger implements LoggerFacade {
Propchange:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/CommonsLoggingLogger.java
--
svn:keywords = Id
-
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]
[httpclient] multicast message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, Does commons-httpclient support multicast messages? I want to send a SSDP Multicast Message. I could create the HTTP Header myself and send the bytes brute force with java.net but if I use httpclient I suppose I will have way more flexibility I will love to have later. As I digged in the sources, I could not find something like this. Can I write my own ProtocolSocketFactory that creates a MulticastSocket instead of a regular socket? How do I use my custom socket factory together with httpclient? Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFlXxcmPuec2Dcv/8RApgCAJ4oYISxksICtlI7m7rnCWbpvuJGTwCfY/5C VzCwsyOLmr3rBc7CdR+kqmI= =4SeJ -END PGP SIGNATURE- - 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]
svn commit: r490336 - /jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/DirectTransactionIdToPathMapper.java
Author: joerg Date: Tue Dec 26 09:27:59 2006 New Revision: 490336 URL: http://svn.apache.org/viewvc?view=revrev=490336 Log: license as normal comment, not javadoc Modified: jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/DirectTransactionIdToPathMapper.java Modified: jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/DirectTransactionIdToPathMapper.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/DirectTransactionIdToPathMapper.java?view=diffrev=490336r1=490335r2=490336 == --- jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/DirectTransactionIdToPathMapper.java (original) +++ jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/DirectTransactionIdToPathMapper.java Tue Dec 26 09:27:59 2006 @@ -1,4 +1,4 @@ -/** +/* * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r490419 - /jakarta/commons/proper/transaction/trunk/build.xml
Author: joerg
Date: Tue Dec 26 16:51:23 2006
New Revision: 490419
URL: http://svn.apache.org/viewvc?view=revrev=490419
Log:
uniform indentation
Modified:
jakarta/commons/proper/transaction/trunk/build.xml
Modified: jakarta/commons/proper/transaction/trunk/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/build.xml?view=diffrev=490419r1=490418r2=490419
==
--- jakarta/commons/proper/transaction/trunk/build.xml (original)
+++ jakarta/commons/proper/transaction/trunk/build.xml Tue Dec 26 16:51:23 2006
@@ -75,56 +75,57 @@
target name=detect depends=detect.display,detect.fail
description=Display configuration and conditional compilation flags/
target name=detect.display
-available property=j2ee.present
classname=javax.resource.cci.Connection classpath=${j2ee.jar}/
-available property=servlet.present
classname=javax.servlet.Servlet classpath=${servlet.jar}/
-condition property=jvm14.present
-or
- equals arg1=${ant.java.version} arg2=1.4/
- equals arg1=${ant.java.version} arg2=1.5/
- equals arg1=${ant.java.version} arg2=1.6/
-/or
-/condition
-echo
message=+---/
-echo message=| Build environment for ${name} ${version}/
-echo message=| /
-echo message=| Note: /
-echo message=| If ${property.name} is displayed for a library /
-echo message=| instead of 'true', that library is not present./
-echo
message=+---/
-echo message=/
-echo message=Environment:/
-echo message= Java home ${java.home}/
-echo message= Java version ${ant.java.version}/
-echo message=/
-echo message=Build options:/
-echo message= Generate debugging info ${compile.debug}/
-echo message= Display deprecation info
${compile.deprecation}/
-echo message= Optimize ${compile.optimize}/
-echo message=/
-echo message=Directories:/
-echo message= Build directory ${build.dir}/
-echo message= Distribution directory${dist.dir}/
-echo message= JBoss deploy directory${jboss.deploy.dir}/
-echo message=/
-echo message=Optional Libraries:/
-echo message= J2EE API ${j2ee.present}/
-echo message= Servlet API ${servlet.present}/
-echo message= JVM 14${jvm14.present}/
-echo message=/
-property name=required.present value=true/
-!--condition property=required.present
-and
-equals arg1=${j2ee.present} arg2=true/
-equals arg1=${servlet.present} arg2=true/
-/and
-/condition--
-/target
-target name=detect.fail unless=required.present
-fail message=Failed dependancy
+available property=j2ee.present
classname=javax.resource.cci.Connection classpath=${j2ee.jar}/
+available property=servlet.present classname=javax.servlet.Servlet
classpath=${servlet.jar}/
+condition property=jvm14.present
+ or
+equals arg1=${ant.java.version} arg2=1.4/
+equals arg1=${ant.java.version} arg2=1.5/
+equals arg1=${ant.java.version} arg2=1.6/
+ /or
+/condition
+echo message=+---/
+echo message=| Build environment for ${name} ${version}/
+echo message=| /
+echo message=| Note: /
+echo message=| If ${property.name} is displayed for a library /
+echo message=| instead of 'true', that library is not present./
+echo message=+---/
+echo message=/
+echo message=Environment:/
+echo message= Java home ${java.home}/
+echo message= Java version ${ant.java.version}/
+echo message=/
+echo message=Build options:/
+echo message= Generate debugging info ${compile.debug}/
+echo message= Display deprecation info ${compile.deprecation}/
+echo message= Optimize ${compile.optimize}/
+echo message=/
+echo message=Directories:/
+echo message= Build directory ${build.dir}/
+echo message= Distribution directory${dist.dir}/
+echo message= JBoss deploy directory${jboss.deploy.dir}/
+echo message=/
+echo message=Optional Libraries:/
+echo message= J2EE API ${j2ee.present}/
+echo message= Servlet API ${servlet.present}/
+echo message= JVM 14${jvm14.present}/
+echo message=/
+property name
svn commit: r490420 - /jakarta/commons/proper/transaction/trunk/build.xml
Author: joerg
Date: Tue Dec 26 16:54:19 2006
New Revision: 490420
URL: http://svn.apache.org/viewvc?view=revrev=490420
Log:
bugfix: Both j2ee and servlet jar are JDK 1.4 compiled. So even checking for
existance with JDK 1.3 fails with UnsupportedClassVersionError.
Modified:
jakarta/commons/proper/transaction/trunk/build.xml
Modified: jakarta/commons/proper/transaction/trunk/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/build.xml?view=diffrev=490420r1=490419r2=490420
==
--- jakarta/commons/proper/transaction/trunk/build.xml (original)
+++ jakarta/commons/proper/transaction/trunk/build.xml Tue Dec 26 16:54:19 2006
@@ -75,14 +75,24 @@
target name=detect depends=detect.display,detect.fail
description=Display configuration and conditional compilation flags/
target name=detect.display
-available property=j2ee.present
classname=javax.resource.cci.Connection classpath=${j2ee.jar}/
-available property=servlet.present classname=javax.servlet.Servlet
classpath=${servlet.jar}/
condition property=jvm14.present
or
equals arg1=${ant.java.version} arg2=1.4/
equals arg1=${ant.java.version} arg2=1.5/
equals arg1=${ant.java.version} arg2=1.6/
/or
+/condition
+condition property=j2ee.present
+ and
+isset property=jvm14.present/
+available property=j2ee.present
classname=javax.resource.cci.Connection classpath=${j2ee.jar}/
+ /and
+/condition
+condition property=servlet.present
+ and
+isset property=jvm14.present/
+available property=j2ee.present classname=javax.servlet.Servlet
classpath=${servlet.jar}/
+ /and
/condition
echo message=+---/
echo message=| Build environment for ${name} ${version}/
-
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]
[jira] Commented: (IO-94) New Mock InputStream Writer implementations
[ http://issues.apache.org/jira/browse/IO-94?page=comments#action_12441670 ] Joerg Schaible commented on IO-94: -- Personally I have always used (CGLIB-enhanced) jMock to create mocks of streams on the fly. Therefore I agree with Stephen, that this is not really something that should be included into the runtime part. Moving to test is IMHO fine though. New Mock InputStream Writer implementations - Key: IO-94 URL: http://issues.apache.org/jira/browse/IO-94 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Niall Pemberton Assigned To: Niall Pemberton Priority: Minor Fix For: 1.3 Attachments: MockInputStream.java, MockInputStreamTestCase.java I have created a MockInputStream which can be plugged in for testing parts of systems where the data doesn't matter - the main use I've had for it was testing large files - without actually having the InputStream process large amounts of bytes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-94) New Mock InputStream Writer implementations
[ http://issues.apache.org/jira/browse/IO-94?page=comments#action_12441674 ] Joerg Schaible commented on IO-94: -- Yes, but not *that* easy :) But what I really needed and wrote once was a NullInputStream of a specific capacity delivering bytes of value 0 (because of assembling a data stream on the fly for a format with 'holes'). Maybe such an implementation with an arbitrary byte value might be added as ConstantInputStream with a certain capacity. Something like this should be similar/equal to the MockInputStream but does not sound so determined for test ;-) New Mock InputStream Writer implementations - Key: IO-94 URL: http://issues.apache.org/jira/browse/IO-94 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Niall Pemberton Assigned To: Niall Pemberton Priority: Minor Fix For: 1.3 Attachments: MockInputStream.java, MockInputStreamTestCase.java I have created a MockInputStream which can be plugged in for testing parts of systems where the data doesn't matter - the main use I've had for it was testing large files - without actually having the InputStream process large amounts of bytes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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: [logging] SLF4J?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Boris, Your arguments against some bad design in some JDK libraries may be OK or not, I maybe was a little harsh ;) but I do not see the point against JUL. I think there are still good arguments to use JUL: - I18N support with default JDK mechanisms (there may be better, OK, but the JCP decided to use this ones). I care a lot about I18N. But I personally think that i18n has nothing lost in loggers. Do you want to get bug-reports with japanese log-files? The log-file is NOT for the end user. It might be ignorant: but which developer can not understand english? How do we communicate on mailing lists? The application itself should be able to support i18n for user feedback: in exceptions, GUI, etc. - Good (not excellent) possibilities to extend/override/exchange the backend. May be your oppinion but not mine. - No further dependencies than JDK1.4 or above That is the major point - Interface of the logger-class has some good helper methods I see no Interface. There is an overloaded Java-Class. Helpers should not be part of the usage Interface but be add-on classes. - Supported by the major wrappers JCL causing no dependency problems if an API requires JCL I am not sure if I get you wrong here. But we are talking about the API you are using. You can of course use JCL together with JUL and everything is fine if you get all the features you need. But if someone is using JUL directly it does not help anyone if it can be adapted by JCL or whatever. BTW have you tried to hot-configure the JUL system at runtime? Works fine with log4j, though. - Supported by the currently niche player SLF4J causing no dependency problems if an API requires SLF4J same as above. - Major issues solved in third party APIs (i.E., but not the only one, x4juli) Okay we need to make sure what we are talking about. Maybe I got it wrong when I catched up the discussion. But there are two things to distinguis: 1) The API you are programming agains when you are writing code that wants to log. 2) The logging toolkit implementation For me the important thing is 1). And JUL is NOT an acceptable API to me. But JCL is. For 2) you can use log4j or JUL or whatever you like. I often have to integrate components from different open-source projects and different vendors. This could be so easy if there was just one logging API (e.g. JCL). Then I can choose for my complete application what logging toolkit I want to use. Another one might choose a different one for the same application. But the truth is different. One component uses JCL via LogFactory, one JUL, one log4j, one logkit, one avalon, one DNA, one plexus, one metro, etc. You end up with tons of logging jars and a situation that makes it impossible to have a homogenous logging system for the application. - From this point of view I can not see the point for slf4j!!! Why can't log4j directly implement the JCL Log interface. I guess that the JCL team would allow log4j team to include their Log interface in the log4j JAR file. But Java classpaths somehow tend to be a political issue. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE7Mm+mPuec2Dcv/8RAuCdAJ9ivXKYCOjxiXQM7GfPDFicC1dQrgCgl1de 44YN4Zeqd7h6rtKdcn9x6e8= =xStS -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (CONFIGURATION-216) Inconsistent way to locate filename when creating configuration
[ http://issues.apache.org/jira/browse/CONFIGURATION-216?page=all ] Joerg Schaible reopened CONFIGURATION-216: -- Reopened by request. Since the bug is only resolved, you should have been able to do so yourself. But maybe there's a flaw in the JIRA workflow configuration ... Inconsistent way to locate filename when creating configuration --- Key: CONFIGURATION-216 URL: http://issues.apache.org/jira/browse/CONFIGURATION-216 Project: Commons Configuration Issue Type: Bug Environment: commons-configuration-1.3-dev Reporter: Gabriele Garuglieri Assigned To: Oliver Heger Priority: Minor Attachments: 216.patch There is a different behaviour locating the configuration file in classpath depending on the way it is set in the configuration class. For example assuming conf/conf1.properties exists in classpath: PropertiesConfiguration pc = new PropertiesConfiguration(conf/conf1.properties); gives org.apache.commons.configuration.ConfigurationException: Cannot locate configuration source conf1.properties while PropertiesConfiguration pc = new PropertiesConfiguration(); pc.setFileName(conf/conf1.properties); pc.load(); properly locate file in classpath and loads it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (SANDBOX-71) [id] Sporadic test failures in TimeBasesAlphanumericIdentifierGeneratorTest
[ http://issues.apache.org/jira/browse/SANDBOX-71?page=all ] Joerg Schaible resolved SANDBOX-71. --- Fix Version/s: Nightly Builds Resolution: Fixed Fixed another test failing for forward time shifts. [id] Sporadic test failures in TimeBasesAlphanumericIdentifierGeneratorTest --- Key: SANDBOX-71 URL: http://issues.apache.org/jira/browse/SANDBOX-71 Project: Commons Sandbox Issue Type: Bug Components: Id Environment: Operating System: other Platform: All Reporter: Joerg Schaible Assigned To: Joerg Schaible Fix For: Nightly Builds Attachments: TimeBasedAIGTest.patch The unit tests for TimeBasesAlphanumericIdentifierGenerator fail with Gump sometimes for unknown reason. Unfortunately it seems, that the exactly test reports are unavailable. Nevertheless I suspect timing problems that interfere and may fail running the fixtures of the test within the same time slice. Therefore was in setUp() a sleep(50) call that might fail to create a unique operation environment for each test fixture depending on the OS/hardware environment. This synchronization has been replaced with an explicit loop waiting for the next time slice. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] statement about commons-logging at plexus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, you might remember me as the getChildLogger and IoC phreak. I recently discoverd this site: http://plexus.codehaus.org/ref/feature-comparison.html There you can read about commons-configuration: ### or example Spring is promoting terrible things like logging based on commons-logging, which makes most of the component dependent on an ugly singleton (IoC is against singletons!) and inevitably leads to incorrect class loader hierarchies (commons-logging must be in root classloader of the container). ### The problem that many people have about commons-logging is that they do not see that commons-logging is an API and an implementation. And even the implementation can be used with or without the LogFactory. My vision is that open-source components can be integrated easily with each other. This gets really ugly if each component uses a different logger API. For me commons-logging should be __ THE API __ for logging. A container can use it's own implementation if he has problems with the implementation you provide. In this manner I suggest you to push this issue. Put something on your website to clearify that commons-logging is the most popular API. Then there is an implementation that now also works with custom CCL magic (e.g. in servlet-containers, etc.). Describe how simple it is to integrate commons-logging in container environments where LogFactory is NOT desired. I do this in my open-source project, too. It is rediculous how simple it is. Finnaly think again about my proposal of the getChildLogger thing. You might think it is insane but it would really help if you could just include the Logger interface that extends Log with the suggested methods in your API jar - - but implement it nowhere. Of course this would cause lots of questions by confused users... If you have further questions or you think it is a good idea to target the IoC and anti-LogFactory guys on your site and would like me to contribute in any way do NOT hesitate to let me know :) Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE5NrUmPuec2Dcv/8RAmWxAJwOuujlMq/boh81sp1ghJBK8zXfigCcCgpE IIsuZ9TkfpaFr4KnMXiRpbA= =jdpS -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] SLF4J?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, But in the end, JCL will continue to improve as will SLF4J I expect, and people can choose as they wish - until j.u.logging knocks both libs into the dustbin of history. just to let you know my oppinion: this will never ever happen. j.u.l is crap because it does NOT have something that one can call an API! I do not know what they drink at sun's but the jdk is full of rotten design mistakes. Some highlights: * See Calendar.get(int). And a Month starts with 0, but day with 1. * Why does Iterator not extend Enumeration * See the complete collections and OperationNotSupportedException - is that an API? I know its not always easy to design a great API and of course JDK is the most central part so there will always be someone complaining. At least the newer things get designed better. Serious applications will continue NOT to use j.u.l !!! Please keep going with JCL - hey, ho :) Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE5N3OmPuec2Dcv/8RAl9AAKCFd6dWhYdOvm00Aa0PipB+JeLitQCdGBMo xMzusRvgkZhDuu+r0NMt9f4= =TgBP -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] pom for commons-logging-api and building/testing JCL with Maven 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, Dennis Lundberg wrote: Hi Simon I think this is a Maven 1 vs Maven 2 issue. As long as we deploy our artifacts (jars) to the Maven 1 repo, which we will do until we switch to Maven 2 as a build system, we need to also supply Maven 1 poms for them. The reason I created this pom was that the deployed commons-logging-api.jar does not have an accompanying pom. Adding this pom to the repo means that other products can set up commons-logging-api as a dependency. I think it is a good idea to keep the tiny commons-logging-api as separate artifact and allow people to only depend on that. For the review of the pom.xml some comments from me: - -consider about spitting off commons-logging-api as a separate project with its own pom.xml. The build logic could be so much simpler. - -what do you think about a common pom.xml for all commons? - -whenever you swith to maven2 then you should switch to the default directory layout - -the profile based dependency stuff is also very complicated magic. Following the maven2 conventions could make it a lot easier. But this might require that you split of the implementation (commons-logging-logj4, commons-logging-avalon, etc.) then you even do not need to declare the dependencies optional - I gues you are not looking foreward to do this (e.g. from the maintaince point of view)... Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE5OG2mPuec2Dcv/8RAow/AJ9mIdj40xd7kXwq0FSSVQ0oTnOTyQCfdmdn UBpuYgDNsa82Z+V3DcRnH9U= =V5TA -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SANDBOX-169) Can`t attach patch to SANDBOX-150
[ http://issues.apache.org/jira/browse/SANDBOX-169?page=all ] Joerg Schaible updated SANDBOX-169: --- Summary: Can`t attach patch to SANDBOX-150 (was: Can`t attache patch to SENDBOX-150) Can`t attach patch to SANDBOX-150 - Key: SANDBOX-169 URL: http://issues.apache.org/jira/browse/SANDBOX-169 Project: Commons Sandbox Issue Type: Sub-task Components: JCI Reporter: Peter Konstantinov Attachments: jci-06-08-15.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (SANDBOX-150) [jci][GSOC] Status patchs
[ http://issues.apache.org/jira/browse/SANDBOX-150?page=all ] Joerg Schaible reopened SANDBOX-150: New patch by Peter ... see subtask SANDBOX-169 [jci][GSOC] Status patchs - Key: SANDBOX-150 URL: http://issues.apache.org/jira/browse/SANDBOX-150 Project: Commons Sandbox Issue Type: New Feature Components: JCI Reporter: Dmitriy Khayredinov Assigned To: Torsten Curdt Attachments: jci-06.07.06.patch, jci-14.06.06.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SANDBOX-169) Can`t attach patch to SANDBOX-150
[ http://issues.apache.org/jira/browse/SANDBOX-169?page=comments#action_12428093 ] Joerg Schaible commented on SANDBOX-169: The original issue was closed, therefore I was more surprised, that you still could add a new open subtask ;-) Can`t attach patch to SANDBOX-150 - Key: SANDBOX-169 URL: http://issues.apache.org/jira/browse/SANDBOX-169 Project: Commons Sandbox Issue Type: Sub-task Components: JCI Reporter: Peter Konstantinov Attachments: jci-06-08-15-2.patch, jci-06-08-15.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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]
[jira] Resolved: (SANDBOX-151) [ID] VersionFourGenerator.nextIdentifier fails in secure mode
[ http://issues.apache.org/jira/browse/SANDBOX-151?page=all ]
Joerg Schaible resolved SANDBOX-151.
Fix Version/s: Nightly Builds
Resolution: Fixed
Fixed in Subversion.
[ID] VersionFourGenerator.nextIdentifier fails in secure mode
-
Key: SANDBOX-151
URL: http://issues.apache.org/jira/browse/SANDBOX-151
Project: Commons Sandbox
Issue Type: Bug
Components: Id
Environment: This JIRA environment is horrible: If I am not logged in
I cannot report a bug (may be OK), but I am then on a page which just does
not tell me about authorization problems but offers me some other projects
where I could report!
Reporter: Martin Heitz
Assigned To: Joerg Schaible
Priority: Critical
Fix For: Nightly Builds
Generating secure ID only works on initialization, aftyerwards always the
same ID is returned.
Fix the wrong if-blocks, then also the third ID will be unique...:
private UUID nextUUID(boolean secure)
{
byte[] raw = new byte[UUID_BYTE_LENGTH];
if (secure) {
//Initialize the secure random if null.
if (secureRandom == null) {
try {
if (usePRNGPackage != null) {
secureRandom = SecureRandom.getInstance(usePRNG,
usePRNGPackage);
} else {
secureRandom = SecureRandom.getInstance(usePRNG);
}
} catch (NoSuchAlgorithmException nsae) {
nsae.printStackTrace();
secure = false; //Fail back to default PRNG/Random
} catch (NoSuchProviderException nspe) {
nspe.printStackTrace();
secure = false; //Fail back to default PRNG/Random
}
}
// fix by mattin
if (secureRandom != null) {
secureRandom.nextBytes(raw);
}
}
if (!secure) {
regularRandom.nextBytes(raw);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
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]
svn commit: r422219 - /jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
Author: joerg
Date: Sat Jul 15 06:59:32 2006
New Revision: 422219
URL: http://svn.apache.org/viewvc?rev=422219view=rev
Log:
re-establish JDK 1.3 compatibility by using different FileOutputStream
constructor
Modified:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
Modified:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java?rev=422219r1=422218r2=422219view=diff
==
---
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
(original)
+++
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
Sat Jul 15 06:59:32 2006
@@ -891,9 +891,8 @@
String resourcePath = getPathForWrite(txId, resourceId);
-File file = new File(resourcePath);
try {
-FileOutputStream stream = new FileOutputStream(file, append);
+FileOutputStream stream = new FileOutputStream(resourcePath,
append);
TransactionContext context = getContext(txId);
context.registerResource(stream);
context.readOnly = false;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r422227 - in /jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction: locking/ReadWriteUpgradeLock.java util/xa/TransactionalResource.java
Author: joerg Date: Sat Jul 15 07:11:10 2006 New Revision: 47 URL: http://svn.apache.org/viewvc?rev=47view=rev Log: fixed Javadoc errors Modified: jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/locking/ReadWriteUpgradeLock.java jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/xa/TransactionalResource.java Modified: jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/locking/ReadWriteUpgradeLock.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/locking/ReadWriteUpgradeLock.java?rev=47r1=46r2=47view=diff == --- jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/locking/ReadWriteUpgradeLock.java (original) +++ jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/locking/ReadWriteUpgradeLock.java Sat Jul 15 07:11:10 2006 @@ -27,7 +27,7 @@ /** * Convenience implementation of a read/write lock with an option for upgrade - * based on [EMAIL PROTECTED] ReadWriteUpgradeLockLock}.br + * based on [EMAIL PROTECTED] ReadWriteUpgradeLock}.br * br * Reads are shared which means there can be any number of concurrent read * accesses allowed by this lock. Writes are exclusive. This means when there is Modified: jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/xa/TransactionalResource.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/xa/TransactionalResource.java?rev=47r1=46r2=47view=diff == --- jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/xa/TransactionalResource.java (original) +++ jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/util/xa/TransactionalResource.java Sat Jul 15 07:11:10 2006 @@ -44,7 +44,7 @@ /** * Prepares the changes done inside this transaction reasource. Same - * semantics as [EMAIL PROTECTED] XAResource.prepare(Xid)}. + * semantics as [EMAIL PROTECTED] javax.transaction.xa.XAResource#prepare(Xid)}. * * @throws XAException * when anything goes wrong the error must be described in XA @@ -70,7 +70,7 @@ /** * Returns the current status of this transaction resource. * - * @return the current status of this resource as defined by [EMAIL PROTECTED] Status}. + * @return the current status of this resource as defined by [EMAIL PROTECTED] javax.transaction.Status}. */ public int getStatus(); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
