[JBoss JIRA] (AS7-977) Dynamic Detection of SPNEGO auth method and adding of NegotiationAuthenticator
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/AS7-977?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated AS7-977:
---------------------------------
Assignee: (was: Darran Lofthouse)
> Dynamic Detection of SPNEGO auth method and adding of NegotiationAuthenticator
> ------------------------------------------------------------------------------
>
> Key: AS7-977
> URL: https://issues.jboss.org/browse/AS7-977
> Project: Application Server 7
> Issue Type: Task
> Components: Security, Web
> Reporter: Darran Lofthouse
> Fix For: Open To Community
>
>
> Previously a mapping for the SPNEGO auth method and the authenticator had to be manually defined, this capability is not present in AS7 however it is suggested that alternatively we can detect the auth method ourselves and dynamically add the valve - this seems cleaner as it potentially allows SPNEGO to be added/removed from a server without manual configuration being required.
> It is suggested to look at the following code for an example where a valve has been added dynamically before: -
> org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor in the JPA subsystem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6031) deploy directories not cleaned up
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6031?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-6031:
---------------------------------------
What's the effect on a clean boot? I figure negligible, butI want to know for sure.
-1 to making this configurable.
> deploy directories not cleaned up
> ---------------------------------
>
> Key: AS7-6031
> URL: https://issues.jboss.org/browse/AS7-6031
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Shaun Appleton
> Assignee: Bartosz Baranowski
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6291) deploy hangs if module import doesn't exist
by Bill Burke (JIRA)
Bill Burke created AS7-6291:
-------------------------------
Summary: deploy hangs if module import doesn't exist
Key: AS7-6291
URL: https://issues.jboss.org/browse/AS7-6291
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.1.Final
Reporter: Bill Burke
If you have a module dependency and that module has its own dependency that doesn't exist, deployment will hang.
To reproduce, create a simple WAR that has a jboss-deployment-structure.xml that imports an existing module. Have that existing module import a different module that doesn't exist.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (JBLOGGING-88) Support setting the logging provider via a resource file
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-88?page=com.atlassian.jira.plug... ]
David Lloyd commented on JBLOGGING-88:
--------------------------------------
Reviewing pull requests today. I still don't see a clear use case that is solved this way; also, the usage of META-INF/services is not consistent with the ServiceProvider mechanism which uses this directory. Can you clarify a bit?
> Support setting the logging provider via a resource file
> --------------------------------------------------------
>
> Key: JBLOGGING-88
> URL: https://issues.jboss.org/browse/JBLOGGING-88
> Project: JBoss Logging
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 3.1.2.GA
> Reporter: Jérôme Delagnes
> Assignee: David Lloyd
>
> Logging provider can be set via the system property {{org.jboss.logging.provider}}.
> It could be nice if the provider could be also set via the resource {{META-INF/services/org.jboss.logging.provider}} or others.
> The algorithm used to locate the provider:
> # system property
> # resource file
> # existing logic
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6082) EJbLogger contains messages that should be in EjbMessages
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/AS7-6082?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins commented on AS7-6082:
--------------------------------------
The PR does not merges the two loggers, need to discuss with [~jaikiran] which one to keep. Anyway I think that probably should go into a separated JIRA, avoiding a big log of changes hard to review properly.
> EJbLogger contains messages that should be in EjbMessages
> ---------------------------------------------------------
>
> Key: AS7-6082
> URL: https://issues.jboss.org/browse/AS7-6082
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Reporter: Stuart Douglas
> Assignee: Eduardo Martins
> Priority: Minor
>
> The EjbLogger class also contains exception messages, not just log messages.
> It also has two loggers (ROOT_LOGGER and EJB3_LOGGER) with the same package name, it would be good to get rid of one of them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-5722) Backward compatibility issue with JMS clients
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/AS7-5722?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak commented on AS7-5722:
-------------------------------------
Current status:
There are serveral types of clients for HornetQ:
* HornetQ core client (uses only HornetQ core API)
* JMS client (uses HornetQ core and JMS API)
* JMS client with JNDI (uses JMS API and JNDI)
HornetQ core client with older EAP 5/6 libraries (hornetq-core-client.jar, netty.jar) can communicate to newer EAP 5 and EAP 6 server.
JMS client with older EAP 5/6 libraries (hornetq-core-client.jar, hornetq-core-client.jar, javaee.jar, netty.jar) can communicate to newer EAP 5 and EAP 6 server.
JMS client with JNDI with EAP 5 older client libraries can communicate to newer EAP 5 server.
JMS client with JNDI with EAP 6 older client library (jboss-client.jar) can communicate to newer EAP 6 server.
JMS client with JNDI which uses EAP 5 client libraries cannot communicate with those libraries to EAP 6 server because there are different libraries for remoting and jndi lookups.
JMS client with JNDI which uses hornetq-core-client.jar, hornetq-jms-client.jar and netty.jar from EAP 5 and then uses EAP 6 libraries to do jndi lookups can communicate with EAP 6 server.
We should define which combinations will be supported. For example following table should clarify it and we should select:
Type of client/ EAP server (Y = supported, N = unsupported)
----------------------------------------------------------------------------------------| EAP 5 server | EAP 6 server
EAP 5 client with HQ API
EAP 5 client with JMS API
EAP 5 client with JMS API with JNDI
EAP 5 client with JMS API with JNDI + updated jars
EAP 6 client with HQ API
EAP 6 client with JMS API
EAP 6 client with JMS API with JNDI
EAP 6 client with JMS API with JNDI
> Backward compatibility issue with JMS clients
> ---------------------------------------------
>
> Key: AS7-5722
> URL: https://issues.jboss.org/browse/AS7-5722
> Project: Application Server 7
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 7.2.0.Alpha1
>
>
> When standalone jms client is trying to connect with "old" jboss-client.jar from AS 7.1.2.Final (HornetQ 2.2.16.Final) to AS 7.2.0.Alpha1 (HornetQ 2.3.0.Beta1) then ClassNotFoundException it thrown:
> Console log of jms client:
> {code}
> [jbossqa@station4 as7-with-hq-replicated]$ java -cp /home/jbossqa/hornetq_eap6_testsuite/as7-with-hq-replicated/client-1.0-SNAPSHOT.jar:/home/jbossqa/hornetq_eap6_testsuite/server1/jboss-eap-6.0/bin/client/jboss-client.jar org.jboss.jms.client.TestProducer 192.168.40.1 jms/queue/testQueue0 10
> remote://192.168.40.1:4447
> Oct 10, 2012 11:44:41 AM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.6.GA-redhat-1
> Oct 10, 2012 11:44:41 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.6.GA-redhat-1
> Oct 10, 2012 11:44:41 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.8.SP1-redhat-1
> Oct 10, 2012 11:44:42 AM org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver handleEnd
> ERROR: Channel end notification received, closing channel Channel ID f6fa08e1 (outbound) of Remoting connection 2a0ab444 to /192.168.40.1:4447
> org.jboss.naming.remote.protocol.NamingIOException: Failed to lookup [Root exception is java.io.IOException: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration]
> at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:49)
> at org.jboss.naming.remote.protocol.v1.Protocol$1.execute(Protocol.java:104)
> at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.lookup(RemoteNamingStoreV1.java:78)
> at org.jboss.naming.remote.client.HaRemoteNamingStore$1.operation(HaRemoteNamingStore.java:227)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:119)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:223)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)
> at javax.naming.InitialContext.lookup(InitialContext.java:409)
> at org.jboss.jms.client.TestProducer.startClient(TestProducer.java:47)
> at org.jboss.jms.client.TestProducer.main(TestProducer.java:28)
> Caused by: java.io.IOException: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration
> at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:159)
> at org.jboss.naming.remote.protocol.v1.BaseProtocolCommand.readResult(BaseProtocolCommand.java:60)
> at org.jboss.naming.remote.protocol.v1.Protocol$1.handleClientMessage(Protocol.java:149)
> at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver$1.run(RemoteNamingStoreV1.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> Caused by: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration
> at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:871)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:903)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:903)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1205)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1678)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1594)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1558)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1236)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
> at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:156)
> ... 6 more
> Oct 10, 2012 11:44:42 AM org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver handleEnd
> ERROR: Channel end notification received, closing channel Channel ID dac0f594 (outbound) of Remoting connection 16e1eea8 to /192.168.40.1:4447
> {code}
> How to reproduce:
> 1) Download reproducer.zip from QA Lab and unzip reproducer.zip: {code}scp -r messaging-18.jbm.lab.bos.redhat.com:/home/mnovak/reproducer-backward-compatibility .{code}
> 2) Start AS7 server:{code}cd jboss-as-7.2.0.Alpha1-SNAPSHOT/bin;sh standalone.sh -c standalone-full-ha.xml -b localhost{code}
> 3) Start jms producer:{code}java -cp $PWD/client-1.0-SNAPSHOT.jar:$PWD/jboss-old-hq226-client.jar org.jboss.jms.client.TestProducer localhost jms/queue/testQueue0 10{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (JASSIST-189) Bridge methods are proxied instead of desired methods
by Donnchadh Ó Donnabháin (JIRA)
[ https://issues.jboss.org/browse/JASSIST-189?page=com.atlassian.jira.plugi... ]
Donnchadh Ó Donnabháin commented on JASSIST-189:
------------------------------------------------
I had considered the following patch but it breaks {{ProxyTester.testBridgeMethod()}}
{noformat}
Index: ProxyFactory.java
===================================================================
--- ProxyFactory.java (revision 698)
+++ ProxyFactory.java (working copy)
@@ -1109,7 +1109,7 @@
Method[] methods = SecurityActions.getDeclaredMethods(clazz);
for (int i = 0; i < methods.length; i++)
- if (!Modifier.isPrivate(methods[i].getModifiers())) {
+ if (!Modifier.isPrivate(methods[i].getModifiers()) && !methods[i].isBridge()) {
Method m = methods[i];
// JIRA JASSIST-127 (covariant return types).
String key = m.getName() + ':' + RuntimeSupport.makeDescriptor(m.getParameterTypes(), null);
{noformat}
> Bridge methods are proxied instead of desired methods
> -----------------------------------------------------
>
> Key: JASSIST-189
> URL: https://issues.jboss.org/browse/JASSIST-189
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.1-GA
> Environment: OS X, Java 1.7.0_09
> Reporter: Donnchadh Ó Donnabháin
> Assignee: Shigeru Chiba
>
> The following test intermittently fails:
> {code}
> package org.javassist.test.covariantproxy;
> import java.lang.reflect.Method;
> import javassist.util.proxy.MethodHandler;
> import javassist.util.proxy.ProxyFactory;
> import javassist.util.proxy.ProxyObject;
> import junit.framework.TestCase;
> public class CovariantProxyTest extends TestCase {
>
> public interface TestProxy {
>
> }
>
> public static class TestMethodHandler implements MethodHandler {
>
> boolean invoked = false;
> public Object invoke(Object self, Method thisMethod, Method proceed, Object[] args) throws Throwable {
> invoked = true;
> return proceed.invoke(self, args);
> }
>
> public boolean wasInvoked() {
> return invoked;
> }
> public void reset() {
> invoked = false;
> }
> }
> public static class Issue {
>
> private Integer id;
>
> public Integer getId() {
> return id;
> }
>
> public void setId(Integer id) {
> this.id = id;
> }
> }
>
> public static class PublishedIssue extends Issue {
>
> }
> public static abstract class Article {
>
> private Integer id;
>
> public Integer getId() {
> return id;
> }
>
> public void setId(Integer id) {
> this.id = id;
> }
>
> public abstract Issue getIssue();
> }
> public static class PublishedArticle extends Article {
>
> private PublishedIssue issue;
>
> @Override
> public PublishedIssue getIssue() {
> return issue;
> }
>
> public void setIssue(PublishedIssue issue) {
> this.issue = issue;
> }
>
> }
>
> public void testThatCallingAMethodWithCovariantReturnTypeCallsProxy() throws Exception {
> Class persistentClass = PublishedArticle.class;
> ProxyFactory factory = new ProxyFactory();
> factory.setUseCache(false);
> factory.setSuperclass(persistentClass);
> factory.setInterfaces(new Class[] {TestProxy.class});
> Class cl = factory.createClass();
> TestProxy proxy = ( TestProxy ) cl.newInstance();
> TestMethodHandler methodHandler = new TestMethodHandler();
> ( ( ProxyObject ) proxy ).setHandler( methodHandler );
>
> ((Article)proxy).getIssue();
> assertTrue(methodHandler.wasInvoked());
>
> methodHandler.reset();
>
> PublishedArticle article = (PublishedArticle) proxy;
>
> article.getIssue();
>
> assertTrue(methodHandler.wasInvoked());
>
> }
>
> }
> {code}
> Were there tests added for JASSIST-24 ? I don't see any associated source.
> This bug causes a problem in hibernate, described in https://hibernate.onjira.com/browse/HHH-7884 .
> This may be related to JASSIST-162 but the circumstances are slightly different.
> The problem occurs intermittently so it appears to depend on the order in which the methods are processed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-5929) :reload operation clears up the restart-required process-state
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/AS7-5929?page=com.atlassian.jira.plugin.s... ]
Bartosz Baranowski updated AS7-5929:
------------------------------------
Git Pull Request: https://github.com/jbossas/jboss-as/pull/3535, https://github.com/jbossas/jboss-as/pull/3554 (was: https://github.com/jbossas/jboss-as/pull/3535)
> :reload operation clears up the restart-required process-state
> --------------------------------------------------------------
>
> Key: AS7-5929
> URL: https://issues.jboss.org/browse/AS7-5929
> Project: Application Server 7
> Issue Type: Bug
> Components: Server
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Jeff Mesnil
> Assignee: Bartosz Baranowski
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
>
> For the patching service, the patch command leaves the server in a restart-required state
> {noformat}
> [standalone@localhost:9999 /] patch /home/jmesnil/Developer/jboss-as/build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/patch.zip
> {
> "outcome" : "success",
> "response-headers" : {
> "operation-requires-restart" : true,
> "process-state" : "restart-required"
> }
> }
> {noformat}
> If I try to change the AS7 configuration, the CLI warns me that a restart is required, for example:
> {noformat}
> [standalone@localhost:9999 hornetq-server=default] ./queue=foo:add(queue-address=foo)
> {
> "outcome" => "success",
> "response-headers" => {"process-state" => "restart-required"}
> }
> {noformat}
> However, when I reload the server using the /:reload command, the process-state header is cleared out:
> {noformat}
> [standalone@localhost:9999 hornetq-server=default] /:reload
> {"outcome" => "success"}
> [standalone@localhost:9999 hornetq-server=default] ./queue=bar:add(queue-address=bar)
> {"outcome" => "success"}
> {noformat}
> This is not correct: until the server is restarted (not reloaded), the result of my patch operation will not be taken into account (eg changing the AS7 module path).
> Reloading the server should not clear its process-state if it is set to "restart-required"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6031) deploy directories not cleaned up
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/AS7-6031?page=com.atlassian.jira.plugin.s... ]
Bartosz Baranowski updated AS7-6031:
------------------------------------
Git Pull Request: https://github.com/jbossas/jboss-as/pull/3816, https://github.com/jbossas/jboss-as/pull/3817 (was: https://github.com/jbossas/jboss-as/pull/3816)
> deploy directories not cleaned up
> ---------------------------------
>
> Key: AS7-6031
> URL: https://issues.jboss.org/browse/AS7-6031
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Shaun Appleton
> Assignee: Bartosz Baranowski
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months