[jira] Commented: (POOL-97) EVICTION_TIMER is never cancelled.
[ https://issues.apache.org/jira/browse/POOL-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514495 ] Robert Burrell Donkin commented on POOL-97: --- This fix breaks binary compatibility but only at package private level. One question which may need to investigated is whether any subtle concurrency issues are prevent by using a static instance. I've taken a look at the code and i can only see it being used to set up eviction timings. Not sure whether these are ever cleared out. So, the instance will ensure the pool remains in memory until the server is restarted. More eyes would be good since it's very easy to miss subtle concurrency issues. I suppose that some benchmarks would be the right way to assess the performance impact of this patch. A more complex solution would be to create a private subclass of timer that does knows when to unschedule eviction tasks. The evictor would need to implement a package interface (unschedulable?) and then test for the pool being closed (or something like that). This would be quite a bit more effort with more to go wrong. EVICTION_TIMER is never cancelled. -- Key: POOL-97 URL: https://issues.apache.org/jira/browse/POOL-97 Project: Commons Pool Issue Type: Bug Affects Versions: 1.3 Reporter: Devendra Patil Fix For: 2.0 Attachments: timer.patch The static EVICTION_TIMER (java.util.Timer) used in GenericObjectPool is never cancelled (even after closing the pool). The GenericObjectPool.close() method just cancels the _evictor (TimerTask). I agree this behaviour is ideal if EVICTION_TIMER is to be used across multiple pools. But, In my case, the resources (i.e. jars) are dynamically deployed and undeployed on remote grid-servers. If EVICTION_TIMER thread doesn't stop, the grid-servers fails to undeploy (i.e. delete) the jars. The grid-server doesn't restart during resource deployment/undeployment, so, setting EVICTION_TIMER to daemon doesn't help me. -- 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: (BETWIXT-57) Class loader problem in JBoss version 4.0.4GA
[
https://issues.apache.org/jira/browse/BETWIXT-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464026
]
Robert Burrell Donkin commented on BETWIXT-57:
--
I was a little concerned about the effects on existing installations of using
the context classloader but Betwixt is only a 0.x so feel free to break the
semantics if it's right thing to do and you documentation it at the bottom of
tasks.xml.
Please feel free to go ahead and add more javadocs (and documentation, if you
can find some time)
Class loader problem in JBoss version 4.0.4GA
-
Key: BETWIXT-57
URL: https://issues.apache.org/jira/browse/BETWIXT-57
Project: Commons Betwixt
Issue Type: Bug
Environment: JBoss application server version 4.0.4GA. Probably
affects most versions of JBoss
Reporter: Surjit Sen
Priority: Critical
When using betwixt in a JBoss application, Class not found exceptions get
thrown when Class.forName methods are called in classes
org.apache.commons.betwixt.digester.ElementRule and
org.apache.commons.betwixt.digester.ClassRule. Specifically the Class.forName
method uses the system class loader to load classes and in JBoss the
classpath normally does not contain the application jar files. The fix is
very simple. The Class.forName method calls in both the classes were replaced
with the following code lines in ElementRule and similar changes were made in
ClassRule as well. This fix ensures that the appropriate class loader is used
for loading classes and is similar to the fix made in log4j.
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
if (loader == null) {
loader =
Class.forName(implementationClass).getClassLoader();
//Class clazz = Class.forName(implementationClass);
}
Class clazz = loader.loadClass(implementationClass);
descriptor.setImplementationClass(clazz);
--
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]
[jira] Commented: (BETWIXT-57) Class loader problem in JBoss version 4.0.4GA
[
https://issues.apache.org/jira/browse/BETWIXT-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462843
]
Robert Burrell Donkin commented on BETWIXT-57:
--
There are issues with switching universally to using the context classloader:
too many containers do not set this classloader correctly. Digester rules
should use the classloader provided by Digester. So, the Betwixt rules should
use the Digester classloader. However, the Digester implemetation is not
exposed by XmlIntrospector. So, this setting needs to be added into the
IntrospectionConfiguration.
I've committed these changes into trunk.
Now, when using Betwixt in a container like JBoss with a well behaved context
classloader, setUseContextClassLoader(true) should called on
IntrospectionConfiguration for the XMLIntrospector. This should produce the
same result as the fix above. Please try the latest code and open this again if
this fix doesn't work.
Class loader problem in JBoss version 4.0.4GA
-
Key: BETWIXT-57
URL: https://issues.apache.org/jira/browse/BETWIXT-57
Project: Commons Betwixt
Issue Type: Bug
Environment: JBoss application server version 4.0.4GA. Probably
affects most versions of JBoss
Reporter: Surjit Sen
Priority: Critical
When using betwixt in a JBoss application, Class not found exceptions get
thrown when Class.forName methods are called in classes
org.apache.commons.betwixt.digester.ElementRule and
org.apache.commons.betwixt.digester.ClassRule. Specifically the Class.forName
method uses the system class loader to load classes and in JBoss the
classpath normally does not contain the application jar files. The fix is
very simple. The Class.forName method calls in both the classes were replaced
with the following code lines in ElementRule and similar changes were made in
ClassRule as well. This fix ensures that the appropriate class loader is used
for loading classes and is similar to the fix made in log4j.
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
if (loader == null) {
loader =
Class.forName(implementationClass).getClassLoader();
//Class clazz = Class.forName(implementationClass);
}
Class clazz = loader.loadClass(implementationClass);
descriptor.setImplementationClass(clazz);
--
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]
[jira] Resolved: (BETWIXT-57) Class loader problem in JBoss version 4.0.4GA
[
https://issues.apache.org/jira/browse/BETWIXT-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Burrell Donkin resolved BETWIXT-57.
--
Resolution: Fixed
Fix committed.
Class loader problem in JBoss version 4.0.4GA
-
Key: BETWIXT-57
URL: https://issues.apache.org/jira/browse/BETWIXT-57
Project: Commons Betwixt
Issue Type: Bug
Environment: JBoss application server version 4.0.4GA. Probably
affects most versions of JBoss
Reporter: Surjit Sen
Priority: Critical
When using betwixt in a JBoss application, Class not found exceptions get
thrown when Class.forName methods are called in classes
org.apache.commons.betwixt.digester.ElementRule and
org.apache.commons.betwixt.digester.ClassRule. Specifically the Class.forName
method uses the system class loader to load classes and in JBoss the
classpath normally does not contain the application jar files. The fix is
very simple. The Class.forName method calls in both the classes were replaced
with the following code lines in ElementRule and similar changes were made in
ClassRule as well. This fix ensures that the appropriate class loader is used
for loading classes and is similar to the fix made in log4j.
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
if (loader == null) {
loader =
Class.forName(implementationClass).getClassLoader();
//Class clazz = Class.forName(implementationClass);
}
Class clazz = loader.loadClass(implementationClass);
descriptor.setImplementationClass(clazz);
--
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]
[jira] Closed: (BETWIXT-56) Build improvements
[ http://issues.apache.org/jira/browse/BETWIXT-56?page=all ] Robert Burrell Donkin closed BETWIXT-56. Resolution: Fixed Committed. Many thanks. BTW i'm happy for apache folks to add their names to the betwixt and hack away Build improvements -- Key: BETWIXT-56 URL: http://issues.apache.org/jira/browse/BETWIXT-56 Project: Commons Betwixt Issue Type: Improvement Reporter: Niall Pemberton Priority: Minor Attachments: betwixt-0.8-rc2-nits.patch Attaching patch to: 1) Include the xdocs in the source distro 2) Addi scope elements to the xerces, xml-apis and junit dependencies in the project.xml for maven 2 3) Switch mail archive links 4) Chnage the maven build to create md5 checksums -- 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] Closed: (BETWIXT-54) CyclicReferenceException Logging
[ http://issues.apache.org/jira/browse/BETWIXT-54?page=all ] Robert Burrell Donkin closed BETWIXT-54. Resolution: Fixed hi holgar thanks for the patch i've committed a variation upon the patch. i'm a little concerned that logging to error is a little high. so, i've logged to info but included the information in the exception which should be printed out when caught. please give this a try. if this isn't good enough then i'll consider turning up the log level again. robert CyclicReferenceException Logging Key: BETWIXT-54 URL: http://issues.apache.org/jira/browse/BETWIXT-54 Project: Commons Betwixt Issue Type: Improvement Environment: / Reporter: Holger Haag Priority: Trivial Attachments: betwixt-cyclic-reference-logging.patch I got screwed last night because of a CyclicReferenceException without additional info (debug level not switched on). So I've increased the priority of some log entries from debug to error and added some more information (class names of all objects in the stack). I think this will make debugging CyclicReferenceException much easier. Patch attached. -- 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] Closed: (BETWIXT-53) Patch: MethodExpression - improved error logging
[ http://issues.apache.org/jira/browse/BETWIXT-53?page=all ] Robert Burrell Donkin closed BETWIXT-53. Resolution: Fixed Committed. Many thanks. Robert Patch: MethodExpression - improved error logging Key: BETWIXT-53 URL: http://issues.apache.org/jira/browse/BETWIXT-53 Project: Commons Betwixt Issue Type: Improvement Reporter: Holger Haag Priority: Trivial Attachments: betwixt.patch added new parameter to handleException: Method m to show/log which method invocation did not work -- 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: (LOGGING-105) Implementation dependencies should be set to runtime scope
[ http://issues.apache.org/jira/browse/LOGGING-105?page=all ] Robert Burrell Donkin resolved LOGGING-105: --- Resolution: Duplicate JCL does not fit nicely into the Maven2 dependency management scheme so this creating a good POM difficult. The Commons team does not maintain the Maven2 POMs for JCL. Please add any comments you have to http://jira.codehaus.org/browse/MEV-392. Implementation dependencies should be set to runtime scope -- Key: LOGGING-105 URL: http://issues.apache.org/jira/browse/LOGGING-105 Project: Commons Logging Type: Bug Versions: 1.1 Final Reporter: Michael Hartman The logkit, log4j, and avalon-framework dependencies listed in the commons-logging-1.1.pom Maven2 POM should have their scopes set to runtime or otherwise be set to optional. -- 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: (BETWIXT-52) Bug/Testcase: Reading does not work: Container holding a list (generics) of interface implementations
[ http://issues.apache.org/jira/browse/BETWIXT-52?page=all ] Robert Burrell Donkin resolved BETWIXT-52: -- Resolution: Fixed This took quite a lot of work for what turned out to be a small fix! Thanks very much for unit tests - I don't think I'd have stayed the course without them. Please free to reopen if I haven't fixed it fully. Bug/Testcase: Reading does not work: Container holding a list (generics) of interface implementations - Key: BETWIXT-52 URL: http://issues.apache.org/jira/browse/BETWIXT-52 Project: Commons Betwixt Type: Bug Reporter: Holger Haag Attachments: AlphaListHolder.java, TestPolyListHolder.java, betwixt-polylistholder-2006-05-24-svn-patch, poly.zip Referring to the thread http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200605.mbox/[EMAIL PROTECTED] on the commons-user mailing list: I've created a test case reproducing this issue. First of all I've extended the existing test case TestPolyList: The interface implementations of AlphaOneImpl and AlphaTwoImpl now have attributes which are serialized/deserialized. This is closer to real-world examples. Secondly, there is now a new javabean-like class, AlphaListHolder which holds an instance of AlphaList. The test case TestPolyListHolder tries to do the serialization/deserialization. Serialization works nicely, but reading the XML fails. I'll attach four files: - betwixt-polylistholder-2006-05-24-svn-patch: svn patch for existing files - TestPolyListHolder.java: new test case - AlphaListHolder.java: the holder class - poly.zip: the whole poly package, just in case (the above mentioned three files should be sufficient to patch the SVN trunk) -- 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] Closed: (BETWIXT-52) Bug/Testcase: Reading does not work: Container holding a list (generics) of interface implementations
[ http://issues.apache.org/jira/browse/BETWIXT-52?page=all ] Robert Burrell Donkin closed BETWIXT-52: Bug/Testcase: Reading does not work: Container holding a list (generics) of interface implementations - Key: BETWIXT-52 URL: http://issues.apache.org/jira/browse/BETWIXT-52 Project: Commons Betwixt Type: Bug Reporter: Holger Haag Attachments: AlphaListHolder.java, TestPolyListHolder.java, betwixt-polylistholder-2006-05-24-svn-patch, poly.zip Referring to the thread http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200605.mbox/[EMAIL PROTECTED] on the commons-user mailing list: I've created a test case reproducing this issue. First of all I've extended the existing test case TestPolyList: The interface implementations of AlphaOneImpl and AlphaTwoImpl now have attributes which are serialized/deserialized. This is closer to real-world examples. Secondly, there is now a new javabean-like class, AlphaListHolder which holds an instance of AlphaList. The test case TestPolyListHolder tries to do the serialization/deserialization. Serialization works nicely, but reading the XML fails. I'll attach four files: - betwixt-polylistholder-2006-05-24-svn-patch: svn patch for existing files - TestPolyListHolder.java: new test case - AlphaListHolder.java: the holder class - poly.zip: the whole poly package, just in case (the above mentioned three files should be sufficient to patch the SVN trunk) -- 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: (BETWIXT-50) Versioning of XML Output
[
http://issues.apache.org/jira/browse/BETWIXT-50?page=comments#action_12413183 ]
Robert Burrell Donkin commented on BETWIXT-50:
--
Committed. Many thanks.
Versioning of XML Output
Key: BETWIXT-50
URL: http://issues.apache.org/jira/browse/BETWIXT-50
Project: Commons Betwixt
Type: Improvement
Reporter: Holger Haag
Assignee: Robert Burrell Donkin
Attachments: betwixt-versioning-patch, src.zip
Referring to the thread Versioning of XML Output
(http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200605.mbox/[EMAIL
PROTECTED]) on the jakarta-commons-user mailing list, I'll provide here a
SVN patch for the described problem.
- Two new strategies: Attribute and Element suppression. Chose interfaces
instead of abstract class so that one class (see test cases) can implement
both.
- After an element/attribute descriptor has been build completely (including
the options), the suppression strategies are evaluated. If the
element/attribute shall be suppressed, it is removed from the introspection
results.
- Important: use addDefaults add-properties=false / ! Otherwise the
effects of element/attribute suppression will be ... none.
- Test cases for illustration
=== Code snippets + explanation == :
* Added new Interfaces
org.apache.commons.betwixt.strategy.AttributeSuppressionStrategy
public boolean suppress(AttributeDescriptor descr);
org.apache.commons.betwixt.strategy.ElementSuppressionStrategy
public boolean suppress(ElementDescriptor descr);
* Added setter/getter methods for such strategies in
org.apache.commons.betwixt.IntrospectionConfiguration
* org.apache.commons.betwixt.digester.ElementRule: Remove element descriptor
if suppressed:
ElementDescriptor descriptor = (ElementDescriptor)digester.pop();
final Object peek = digester.peek();
if(peek instanceof ElementDescriptor) {
ElementDescriptor parent = (ElementDescriptor)digester.peek();
// check for element suppression
if(
getXMLIntrospector().getConfiguration().getElementSuppressionStrategy().suppress(descriptor))
{
parent.removeElementDescriptor(descriptor);
}
}
* org.apache.commons.betwixt.digester.AttributeRule: Remove attribute
descrptor if suppressed:
AttributeDescriptor descriptor =
(AttributeDescriptor)digester.pop();
ElementDescriptor parent = (ElementDescriptor)digester.peek();
// check for attribute suppression
if(
getXMLIntrospector().getConfiguration().getAttributeSuppressionStrategy().suppress(descriptor))
{
parent.removeAttributeDescriptor(descriptor);
}
* ElementDescriptor: new methods:
public void removeAttributeDescriptor(AttributeDescriptor descriptor) {
getAttributeList().remove(descriptor);
}
public void removeElementDescriptor(ElementDescriptor descriptor) {
getElementList().remove(descriptor);
getContentList().remove(descriptor);
}
public AttributeDescriptor getAttributeDescriptor(final String name)
{
for (int i = 0, size = attributeDescriptors.length; i size;
i++)
{
AttributeDescriptor descr = attributeDescriptors[i];
if (descr.getQualifiedName().equals(name)) {
return descr;
}
}
return null;
}
* Test cases: package org.apache.commons.betwixt.versioning
VersioningStrategy implements both an element and versioning strategy
VersioningTest well.. .test the versioning.
--
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] Closed: (BETWIXT-50) Versioning of XML Output
[ http://issues.apache.org/jira/browse/BETWIXT-50?page=all ]
Robert Burrell Donkin closed BETWIXT-50:
Resolution: Fixed
Committed. Many thanks.
Wrong issues number in commit message :-/
Maybe I'll learn one day...
Versioning of XML Output
Key: BETWIXT-50
URL: http://issues.apache.org/jira/browse/BETWIXT-50
Project: Commons Betwixt
Type: Improvement
Reporter: Holger Haag
Assignee: Robert Burrell Donkin
Attachments: betwixt-versioning-patch, src.zip
Referring to the thread Versioning of XML Output
(http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200605.mbox/[EMAIL
PROTECTED]) on the jakarta-commons-user mailing list, I'll provide here a
SVN patch for the described problem.
- Two new strategies: Attribute and Element suppression. Chose interfaces
instead of abstract class so that one class (see test cases) can implement
both.
- After an element/attribute descriptor has been build completely (including
the options), the suppression strategies are evaluated. If the
element/attribute shall be suppressed, it is removed from the introspection
results.
- Important: use addDefaults add-properties=false / ! Otherwise the
effects of element/attribute suppression will be ... none.
- Test cases for illustration
=== Code snippets + explanation == :
* Added new Interfaces
org.apache.commons.betwixt.strategy.AttributeSuppressionStrategy
public boolean suppress(AttributeDescriptor descr);
org.apache.commons.betwixt.strategy.ElementSuppressionStrategy
public boolean suppress(ElementDescriptor descr);
* Added setter/getter methods for such strategies in
org.apache.commons.betwixt.IntrospectionConfiguration
* org.apache.commons.betwixt.digester.ElementRule: Remove element descriptor
if suppressed:
ElementDescriptor descriptor = (ElementDescriptor)digester.pop();
final Object peek = digester.peek();
if(peek instanceof ElementDescriptor) {
ElementDescriptor parent = (ElementDescriptor)digester.peek();
// check for element suppression
if(
getXMLIntrospector().getConfiguration().getElementSuppressionStrategy().suppress(descriptor))
{
parent.removeElementDescriptor(descriptor);
}
}
* org.apache.commons.betwixt.digester.AttributeRule: Remove attribute
descrptor if suppressed:
AttributeDescriptor descriptor =
(AttributeDescriptor)digester.pop();
ElementDescriptor parent = (ElementDescriptor)digester.peek();
// check for attribute suppression
if(
getXMLIntrospector().getConfiguration().getAttributeSuppressionStrategy().suppress(descriptor))
{
parent.removeAttributeDescriptor(descriptor);
}
* ElementDescriptor: new methods:
public void removeAttributeDescriptor(AttributeDescriptor descriptor) {
getAttributeList().remove(descriptor);
}
public void removeElementDescriptor(ElementDescriptor descriptor) {
getElementList().remove(descriptor);
getContentList().remove(descriptor);
}
public AttributeDescriptor getAttributeDescriptor(final String name)
{
for (int i = 0, size = attributeDescriptors.length; i size;
i++)
{
AttributeDescriptor descr = attributeDescriptors[i];
if (descr.getQualifiedName().equals(name)) {
return descr;
}
}
return null;
}
* Test cases: package org.apache.commons.betwixt.versioning
VersioningStrategy implements both an element and versioning strategy
VersioningTest well.. .test the versioning.
--
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]
