You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by "lionel gomez (JIRA)" <hi...@jakarta.apache.org> on 2006/11/15 03:19:39 UTC
[jira] Created: (HIVEMIND-192) Using tapestry 4.0 with java 2
security enabled prevents the application from starting on several
application servers (solution proposed)
Using tapestry 4.0 with java 2 security enabled prevents the application from starting on several application servers (solution proposed)
-----------------------------------------------------------------------------------------------------------------------------------------
Key: HIVEMIND-192
URL: http://issues.apache.org/jira/browse/HIVEMIND-192
Project: HiveMind
Issue Type: Bug
Affects Versions: 1.1
Environment: java version 1.4.1_07 , apache tomcat server, 5.0 IBM Websphere server 5.0
Reporter: lionel gomez
problem: Using tapestry 4.0 with java 2 security enabled on several application servers prevents the application from starting
Cause:
The SecurityManager do security checks for sensitive operation based on context of the current execution thread and its execution stack. The AccessControlContext obtains a stack of ProtectionDomains of all objects in the execution stack and checks if all these ProtectionDomain have all the permision required to perform the operation.
Tapestry/Hivemind uses javassist library to create enhaced pages and components using bytecode manipulation and generates a ctClass object, then use HivemindPool wich ends up in a call to ClassPool.toClass(CtClass).
Javassist uses reflection to make a call to ClassLoader.defineClass(String name, byte[] b, int off, int len) wich generates an object with a default ProtectionDomain. So pages and componentes will have the default ProtectionDomain.
copied from java API:
This method assigns a default ProtectionDomain to the newly defined class. The ProtectionDomain is effectively granted the same set of permissions returned when Policy.getPolicy().getPermissions(new CodeSource(null, null)) is invoked.
When the AccessControlContext do the security checks on the ProtectionDomain of these enhaced classes it fails to find the required permisions, because they dont have any permision (or protectiondomain is null cant remember for sure any way fails to find required permisions).
The solution is to instead use the method ClassLoader.defineClass(String name, byte[] b, int off, int len, ProtectionDomain protectionDomain) this way we can assign a ProtectionDomain that has the defined permisions in the policy.
So this is really a javassist problem not a Tapestry/Hivemind problem.
But fixing this in javassist is not easy. The ctClass class deal with bytecode manipulation only, and the ProtectionDomain is a responsability of the ClassLoader. Should javassist also take over the ClassLoader responsibility of assigning ProtectionDomains and get the assigned permisions from policy. What ProtectionDomain should a new set of bytecode have if made with makeClass() ?
Until javassist solves this in another realease and this realease is included in another tapestry release, a solution is to modify the class HivemindPool. We have used this and work fine. it works without modifying javassist.
Proposed Solution:
1. Modifyng the HivemindClassPool class to assign the ProtectionDomain of the classloader or the HivemindClassPool to all the enhanced classes.
2. Rebuild the hivemind.jar
3. Modify the security policy file that grants the required permision for the application. (start by granting all permisions to test and then replace with the fine grained ones)
This makes all enhaced class to have a ProtectionDomain with permisions granted on the policy file. Non enhaced classes will still have the fine grained permisions specified in the policy file, but enhaced class will have the same permision granted to the HivemindClassPool.
In file org.apache.hivemind.service.impl.HiveMindClassPool replace the following :
public Class toClass(CtClass ctClass) throws CannotCompileException
{
return ctClass.toClass(_loader);
}
with the following:
It uses the other method of ClassLoader and pass the ProtectionDomain of the HivemindClassPool.
public Class toClass(CtClass ctClass) throws CannotCompileException
{
return toClass(ctClass, _loader);
}
public Class toClass(CtClass ct, ClassLoader loader)
throws CannotCompileException
{
try {
byte[] b = ct.toBytecode();
Class cl = Class.forName("java.lang.ClassLoader");
java.lang.reflect.Method method =
cl.getDeclaredMethod("defineClass",
new Class[] { String.class, byte[].class,
int.class, int.class, ProtectionDomain.class });
method.setAccessible(true);
Object[] args = new Object[] { ct.getName(), b, new Integer(0),
new Integer(b.length), this.getClass().getProtectionDomain()};
Class clazz = (Class)method.invoke(loader, args);
method.setAccessible(false);
return clazz;
}
catch (RuntimeException e) {
throw e;
}
catch (java.lang.reflect.InvocationTargetException e) {
throw new CannotCompileException(e.getTargetException());
}
catch (Exception e) {
throw new CannotCompileException(e);
}
}
--
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
[jira] Commented: (HIVEMIND-192) Using tapestry 4.0 with java 2
security enabled prevents the application from starting on several
application servers (solution proposed)
Posted by "lionel gomez (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-192?page=comments#action_12449894 ]
lionel gomez commented on HIVEMIND-192:
---------------------------------------
solution 2 (fined grained java 2 security)
The first solution gives all permisions that classloader has to the enhaced class, but doesnt allow to give specific permisions for each enhaced class like done for non enhaced classes.
First solution was enough for the proyect.
If your application requires this then many changes are required. (I didnt provide all the changes since they are to many, only the main ones. please let me know if you require these).
1. In file org.apache.hivemind.service.impl.HiveMindClassPool replace the following :
public Class toClass(CtClass ctClass) throws CannotCompileException
{
return ctClass.toClass(_loader);
}
with the following:
public Class toClass(CtClass clazz, Class baseClass) throws CannotCompileException {
return toClass(clazz, _loader, baseClass);
}
this method receives the baseclass as parameter (i.e. the base page that will be enhaced).
The code uses the ProtectionDomain of the baseClass. This results in the enhaced class having the specific permisionss that where asigned to the baseClass
public Class toClass(CtClass ct, ClassLoader loader, Class baseClass)
throws CannotCompileException
{
try {
byte[] b = ct.toBytecode();
Class cl = Class.forName("java.lang.ClassLoader");
java.lang.reflect.Method method =
cl.getDeclaredMethod("defineClass",
new Class[] { String.class, byte[].class,
int.class, int.class, ProtectionDomain.class });
method.setAccessible(true);
Object[] args = new Object[] { ct.getName(), b, new Integer(0),
new Integer(b.length), baseClass.getProtectionDomain()};
Class clazz = (Class)method.invoke(loader, args);
method.setAccessible(false);
return clazz;
}
catch (RuntimeException e) {
throw e;
}
catch (java.lang.reflect.InvocationTargetException e) {
throw new CannotCompileException(e.getTargetException());
}
catch (Exception e) {
throw new CannotCompileException(e);
}
}
Also org.apache.hivemind.service.impl.CtClassSource
change this method
public Class createClass(CtClass ctClass)
{
to this
public Class createClass(CtClass ctClass, Class baseClass)
{
try
{
return _pool.toClass(ctClass, baseClass);
}
catch (Throwable ex)
{
throw new ApplicationRuntimeException(ServiceMessages.unableToWriteClass(ctClass, ex),
ex);
}
}
Now these methods are called by many classes in (hivemind-1.1.jar, hivemind-lib-1.1.jar, tapestry-4.0.jar).
This requires a change on all the calls to pass the extra Baseclass parameter.
the list of files are:
Tapestry-4.0.jar
EnhancementOperationImpl
hivemind-1.1.jar
HiveMindClassPool
CtClassSource
AbstractFab
AbstractServiceModelImpl
ProxyUtils
ClassFab
ClassFabImpl
InterfaceFab
InterfaceFabImpl
InterfaceSynthesizerImpl
SingletonServiceModel
LoggingInterceptorFactory
hivemind-lib-1.1.jar
ChainBuilderImpl
BridgeBuilder
StrategyFactory
DefaultImplementationBuilderImpl
ServicePropertyFactory
EJBProxyFactory
The criteria to assign a ProtectionDomain is the following:
- if a class is to be enahced use the ProtectionDomain of the base class
- if a service is to be created, use the ProtectionDomain of the service interface class
- if a configurationpoint is to be created, use the ProtectionDomain of the configuration point interface
- if a ejbproxy is to be create, use the ProtectionDomain of the remote interface class
- else use any Class that resembles to a baseclass, interface class or service class that is available on the method.
for example in AbstractFab.java
replace
public Class createClass()
{
return _source.createClass(_ctClass);
}
with the following to pass the baseClass
public Class createClass(Class baseClass)
{
return _source.createClass(_ctClass, baseClass);
> Using tapestry 4.0 with java 2 security enabled prevents the application from starting on several application servers (solution proposed)
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HIVEMIND-192
> URL: http://issues.apache.org/jira/browse/HIVEMIND-192
> Project: HiveMind
> Issue Type: Bug
> Affects Versions: 1.1
> Environment: java version 1.4.1_07 , apache tomcat server, 5.0 IBM Websphere server 5.0
> Reporter: lionel gomez
>
> problem: Using tapestry 4.0 with java 2 security enabled on several application servers prevents the application from starting
> Cause:
> The SecurityManager do security checks for sensitive operation based on context of the current execution thread and its execution stack. The AccessControlContext obtains a stack of ProtectionDomains of all objects in the execution stack and checks if all these ProtectionDomain have all the permision required to perform the operation.
> Tapestry/Hivemind uses javassist library to create enhaced pages and components using bytecode manipulation and generates a ctClass object, then use HivemindPool wich ends up in a call to ClassPool.toClass(CtClass).
> Javassist uses reflection to make a call to ClassLoader.defineClass(String name, byte[] b, int off, int len) wich generates an object with a default ProtectionDomain. So pages and componentes will have the default ProtectionDomain.
> copied from java API:
> This method assigns a default ProtectionDomain to the newly defined class. The ProtectionDomain is effectively granted the same set of permissions returned when Policy.getPolicy().getPermissions(new CodeSource(null, null)) is invoked.
> When the AccessControlContext do the security checks on the ProtectionDomain of these enhaced classes it fails to find the required permisions, because they dont have any permision (or protectiondomain is null cant remember for sure any way fails to find required permisions).
> The solution is to instead use the method ClassLoader.defineClass(String name, byte[] b, int off, int len, ProtectionDomain protectionDomain) this way we can assign a ProtectionDomain that has the defined permisions in the policy.
> So this is really a javassist problem not a Tapestry/Hivemind problem.
> But fixing this in javassist is not easy. The ctClass class deal with bytecode manipulation only, and the ProtectionDomain is a responsability of the ClassLoader. Should javassist also take over the ClassLoader responsibility of assigning ProtectionDomains and get the assigned permisions from policy. What ProtectionDomain should a new set of bytecode have if made with makeClass() ?
> Until javassist solves this in another realease and this realease is included in another tapestry release, a solution is to modify the class HivemindPool. We have used this and work fine. it works without modifying javassist.
> Proposed Solution:
> 1. Modifyng the HivemindClassPool class to assign the ProtectionDomain of the classloader or the HivemindClassPool to all the enhanced classes.
> 2. Rebuild the hivemind.jar
> 3. Modify the security policy file that grants the required permision for the application. (start by granting all permisions to test and then replace with the fine grained ones)
> This makes all enhaced class to have a ProtectionDomain with permisions granted on the policy file. Non enhaced classes will still have the fine grained permisions specified in the policy file, but enhaced class will have the same permision granted to the HivemindClassPool.
> In file org.apache.hivemind.service.impl.HiveMindClassPool replace the following :
> public Class toClass(CtClass ctClass) throws CannotCompileException
> {
> return ctClass.toClass(_loader);
> }
> with the following:
> It uses the other method of ClassLoader and pass the ProtectionDomain of the HivemindClassPool.
> public Class toClass(CtClass ctClass) throws CannotCompileException
> {
> return toClass(ctClass, _loader);
> }
>
> public Class toClass(CtClass ct, ClassLoader loader)
> throws CannotCompileException
> {
> try {
> byte[] b = ct.toBytecode();
> Class cl = Class.forName("java.lang.ClassLoader");
> java.lang.reflect.Method method =
> cl.getDeclaredMethod("defineClass",
> new Class[] { String.class, byte[].class,
> int.class, int.class, ProtectionDomain.class });
> method.setAccessible(true);
> Object[] args = new Object[] { ct.getName(), b, new Integer(0),
> new Integer(b.length), this.getClass().getProtectionDomain()};
> Class clazz = (Class)method.invoke(loader, args);
> method.setAccessible(false);
> return clazz;
> }
> catch (RuntimeException e) {
> throw e;
> }
> catch (java.lang.reflect.InvocationTargetException e) {
> throw new CannotCompileException(e.getTargetException());
> }
> catch (Exception e) {
> throw new CannotCompileException(e);
> }
> }
--
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
[jira] Commented: (HIVEMIND-192) Using tapestry 4.0 with java 2
security enabled prevents the application from starting on several
application servers (solution proposed)
Posted by "Renat Zubairov (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-192?page=comments#action_12455185 ]
Renat Zubairov commented on HIVEMIND-192:
-----------------------------------------
Proposed solution will work but it is wrong because it is not a HiveMind problem and it shouldn't be fix in the Hivemind source code. Although it is not possible to fix this problem without changes in HiveMind but correct solution should be done in Javassist and then different utility method should be used in Hivemind.
The problem in Javassist is already fixed see http://jira.jboss.com/jira/browse/JASSIST-23. So now HiveMind should only use this fix. In my opinion it will be better solution.
> Using tapestry 4.0 with java 2 security enabled prevents the application from starting on several application servers (solution proposed)
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HIVEMIND-192
> URL: http://issues.apache.org/jira/browse/HIVEMIND-192
> Project: HiveMind
> Issue Type: Bug
> Affects Versions: 1.1
> Environment: java version 1.4.1_07 , apache tomcat server, 5.0 IBM Websphere server 5.0
> Reporter: lionel gomez
>
> problem: Using tapestry 4.0 with java 2 security enabled on several application servers prevents the application from starting
> Cause:
> The SecurityManager do security checks for sensitive operation based on context of the current execution thread and its execution stack. The AccessControlContext obtains a stack of ProtectionDomains of all objects in the execution stack and checks if all these ProtectionDomain have all the permision required to perform the operation.
> Tapestry/Hivemind uses javassist library to create enhaced pages and components using bytecode manipulation and generates a ctClass object, then use HivemindPool wich ends up in a call to ClassPool.toClass(CtClass).
> Javassist uses reflection to make a call to ClassLoader.defineClass(String name, byte[] b, int off, int len) wich generates an object with a default ProtectionDomain. So pages and componentes will have the default ProtectionDomain.
> copied from java API:
> This method assigns a default ProtectionDomain to the newly defined class. The ProtectionDomain is effectively granted the same set of permissions returned when Policy.getPolicy().getPermissions(new CodeSource(null, null)) is invoked.
> When the AccessControlContext do the security checks on the ProtectionDomain of these enhaced classes it fails to find the required permisions, because they dont have any permision (or protectiondomain is null cant remember for sure any way fails to find required permisions).
> The solution is to instead use the method ClassLoader.defineClass(String name, byte[] b, int off, int len, ProtectionDomain protectionDomain) this way we can assign a ProtectionDomain that has the defined permisions in the policy.
> So this is really a javassist problem not a Tapestry/Hivemind problem.
> But fixing this in javassist is not easy. The ctClass class deal with bytecode manipulation only, and the ProtectionDomain is a responsability of the ClassLoader. Should javassist also take over the ClassLoader responsibility of assigning ProtectionDomains and get the assigned permisions from policy. What ProtectionDomain should a new set of bytecode have if made with makeClass() ?
> Until javassist solves this in another realease and this realease is included in another tapestry release, a solution is to modify the class HivemindPool. We have used this and work fine. it works without modifying javassist.
> Proposed Solution:
> 1. Modifyng the HivemindClassPool class to assign the ProtectionDomain of the classloader or the HivemindClassPool to all the enhanced classes.
> 2. Rebuild the hivemind.jar
> 3. Modify the security policy file that grants the required permision for the application. (start by granting all permisions to test and then replace with the fine grained ones)
> This makes all enhaced class to have a ProtectionDomain with permisions granted on the policy file. Non enhaced classes will still have the fine grained permisions specified in the policy file, but enhaced class will have the same permision granted to the HivemindClassPool.
> In file org.apache.hivemind.service.impl.HiveMindClassPool replace the following :
> public Class toClass(CtClass ctClass) throws CannotCompileException
> {
> return ctClass.toClass(_loader);
> }
> with the following:
> It uses the other method of ClassLoader and pass the ProtectionDomain of the HivemindClassPool.
> public Class toClass(CtClass ctClass) throws CannotCompileException
> {
> return toClass(ctClass, _loader);
> }
>
> public Class toClass(CtClass ct, ClassLoader loader)
> throws CannotCompileException
> {
> try {
> byte[] b = ct.toBytecode();
> Class cl = Class.forName("java.lang.ClassLoader");
> java.lang.reflect.Method method =
> cl.getDeclaredMethod("defineClass",
> new Class[] { String.class, byte[].class,
> int.class, int.class, ProtectionDomain.class });
> method.setAccessible(true);
> Object[] args = new Object[] { ct.getName(), b, new Integer(0),
> new Integer(b.length), this.getClass().getProtectionDomain()};
> Class clazz = (Class)method.invoke(loader, args);
> method.setAccessible(false);
> return clazz;
> }
> catch (RuntimeException e) {
> throw e;
> }
> catch (java.lang.reflect.InvocationTargetException e) {
> throw new CannotCompileException(e.getTargetException());
> }
> catch (Exception e) {
> throw new CannotCompileException(e);
> }
> }
--
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
[jira] Commented: (HIVEMIND-192) Using tapestry 4.0 with java 2
security enabled prevents the application from starting on several
application servers (solution proposed)
Posted by "lionel gomez (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-192?page=comments#action_12449892 ]
lionel gomez commented on HIVEMIND-192:
---------------------------------------
Proposed Solution:
1. Modifyng the HivemindClassPool class to assign the ProtectionDomain of the classloader or the HivemindClassPool to all the enhanced classes.
2. Rebuild the hivemind.jar
3. Modify the security policy file that grants the required permision for the application. (start by granting all permisions to test and then replace with the fine grained ones)
This makes all enhaced class to have a ProtectionDomain with permisions granted on the policy file. Non enhaced classes will still have the fine grained permisions specified in the policy file, but enhaced class will have the same permision granted to the HivemindClassPool.
In file org.apache.hivemind.service.impl.HiveMindClassPool replace the following :
public Class toClass(CtClass ctClass) throws CannotCompileException
{
return ctClass.toClass(_loader);
}
with the following:
It uses the other method of ClassLoader and pass the ProtectionDomain of the HivemindClassPool.
public Class toClass(CtClass ctClass) throws CannotCompileException
{
return toClass(ctClass, _loader);
}
public Class toClass(CtClass ct, ClassLoader loader)
throws CannotCompileException
{
try {
byte[] b = ct.toBytecode();
Class cl = Class.forName("java.lang.ClassLoader");
java.lang.reflect.Method method =
cl.getDeclaredMethod("defineClass",
new Class[] { String.class, byte[].class,
int.class, int.class, ProtectionDomain.class });
method.setAccessible(true);
Object[] args = new Object[] { ct.getName(), b, new Integer(0),
new Integer(b.length), this.getClass().getProtectionDomain()};
Class clazz = (Class)method.invoke(loader, args);
method.setAccessible(false);
return clazz;
}
catch (RuntimeException e) {
throw e;
}
catch (java.lang.reflect.InvocationTargetException e) {
throw new CannotCompileException(e.getTargetException());
}
catch (Exception e) {
throw new CannotCompileException(e);
}
}
> Using tapestry 4.0 with java 2 security enabled prevents the application from starting on several application servers (solution proposed)
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HIVEMIND-192
> URL: http://issues.apache.org/jira/browse/HIVEMIND-192
> Project: HiveMind
> Issue Type: Bug
> Affects Versions: 1.1
> Environment: java version 1.4.1_07 , apache tomcat server, 5.0 IBM Websphere server 5.0
> Reporter: lionel gomez
>
> problem: Using tapestry 4.0 with java 2 security enabled on several application servers prevents the application from starting
> Cause:
> The SecurityManager do security checks for sensitive operation based on context of the current execution thread and its execution stack. The AccessControlContext obtains a stack of ProtectionDomains of all objects in the execution stack and checks if all these ProtectionDomain have all the permision required to perform the operation.
> Tapestry/Hivemind uses javassist library to create enhaced pages and components using bytecode manipulation and generates a ctClass object, then use HivemindPool wich ends up in a call to ClassPool.toClass(CtClass).
> Javassist uses reflection to make a call to ClassLoader.defineClass(String name, byte[] b, int off, int len) wich generates an object with a default ProtectionDomain. So pages and componentes will have the default ProtectionDomain.
> copied from java API:
> This method assigns a default ProtectionDomain to the newly defined class. The ProtectionDomain is effectively granted the same set of permissions returned when Policy.getPolicy().getPermissions(new CodeSource(null, null)) is invoked.
> When the AccessControlContext do the security checks on the ProtectionDomain of these enhaced classes it fails to find the required permisions, because they dont have any permision (or protectiondomain is null cant remember for sure any way fails to find required permisions).
> The solution is to instead use the method ClassLoader.defineClass(String name, byte[] b, int off, int len, ProtectionDomain protectionDomain) this way we can assign a ProtectionDomain that has the defined permisions in the policy.
> So this is really a javassist problem not a Tapestry/Hivemind problem.
> But fixing this in javassist is not easy. The ctClass class deal with bytecode manipulation only, and the ProtectionDomain is a responsability of the ClassLoader. Should javassist also take over the ClassLoader responsibility of assigning ProtectionDomains and get the assigned permisions from policy. What ProtectionDomain should a new set of bytecode have if made with makeClass() ?
> Until javassist solves this in another realease and this realease is included in another tapestry release, a solution is to modify the class HivemindPool. We have used this and work fine. it works without modifying javassist.
> Proposed Solution:
> 1. Modifyng the HivemindClassPool class to assign the ProtectionDomain of the classloader or the HivemindClassPool to all the enhanced classes.
> 2. Rebuild the hivemind.jar
> 3. Modify the security policy file that grants the required permision for the application. (start by granting all permisions to test and then replace with the fine grained ones)
> This makes all enhaced class to have a ProtectionDomain with permisions granted on the policy file. Non enhaced classes will still have the fine grained permisions specified in the policy file, but enhaced class will have the same permision granted to the HivemindClassPool.
> In file org.apache.hivemind.service.impl.HiveMindClassPool replace the following :
> public Class toClass(CtClass ctClass) throws CannotCompileException
> {
> return ctClass.toClass(_loader);
> }
> with the following:
> It uses the other method of ClassLoader and pass the ProtectionDomain of the HivemindClassPool.
> public Class toClass(CtClass ctClass) throws CannotCompileException
> {
> return toClass(ctClass, _loader);
> }
>
> public Class toClass(CtClass ct, ClassLoader loader)
> throws CannotCompileException
> {
> try {
> byte[] b = ct.toBytecode();
> Class cl = Class.forName("java.lang.ClassLoader");
> java.lang.reflect.Method method =
> cl.getDeclaredMethod("defineClass",
> new Class[] { String.class, byte[].class,
> int.class, int.class, ProtectionDomain.class });
> method.setAccessible(true);
> Object[] args = new Object[] { ct.getName(), b, new Integer(0),
> new Integer(b.length), this.getClass().getProtectionDomain()};
> Class clazz = (Class)method.invoke(loader, args);
> method.setAccessible(false);
> return clazz;
> }
> catch (RuntimeException e) {
> throw e;
> }
> catch (java.lang.reflect.InvocationTargetException e) {
> throw new CannotCompileException(e.getTargetException());
> }
> catch (Exception e) {
> throw new CannotCompileException(e);
> }
> }
--
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