[JBoss JIRA] (WFCORE-519) Xalan Linkage error : TransformerConfigurationException
by Theo Cleminson (JIRA)
[ https://issues.jboss.org/browse/WFCORE-519?page=com.atlassian.jira.plugin... ]
Theo Cleminson edited comment on WFCORE-519 at 10/23/15 1:18 AM:
-----------------------------------------------------------------
This saved my bacon too.
Here's what is working for me (Wildfly 9.01 in domain mode using full-ha profile with xmlunit v1.6)
<!-- include JDK dependencies (rt.jar) for xalan -->
<system export="true">
<paths>
<path name="com/sun/org/apache/xml/internal/dtm"/>
_ <path name="com/sun/org/apache/xml/internal/dtm/ref"/>_
<path name="com/sun/org/apache/xml/internal/serializer"/>
<path name="com/sun/org/apache/xalan/internal/xsltc"/>
<path name="com/sun/org/apache/xalan/internal/xsltc/dom"/>
<path name="com/sun/org/apache/xalan/internal/xsltc/runtime"/>
</paths>
</system>
was (Author: tc7):
This saved my bacon too.
Here's what is working for me (Wildfly 9.01 in domain mode using full-ha profile with xmlunit v1.6)
<!-- include JDK dependencies (rt.jar) for xalan -->
<system export="true">
<paths>
<path name="com/sun/org/apache/xml/internal/dtm"/>
_ <path name="com/sun/org/apache/xml/internal/dtm/ref"/>_
<path name="com/sun/org/apache/xml/internal/serializer"/>
<path name="com/sun/org/apache/xalan/internal/xsltc"/>
<path name="com/sun/org/apache/xalan/internal/xsltc"/>
<path name="com/sun/org/apache/xalan/internal/xsltc/dom"/>
<path name="com/sun/org/apache/xalan/internal/xsltc/runtime"/>
</paths>
</system>
> Xalan Linkage error : TransformerConfigurationException
> -------------------------------------------------------
>
> Key: WFCORE-519
> URL: https://issues.jboss.org/browse/WFCORE-519
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Environment: Wildfly 8.1 & 8.2-Final
> JDK 1.7.0_45 & 1.7.0_71
> Windows & Linux
> Reporter: Stephen Kay
> Assignee: David Lloyd
> Priority: Critical
> Fix For: 1.0.0.Alpha16
>
>
> Please note that this bug wasn't present on JBoss 7.1 / same WAR artifact
> This is full staktrace from our applicaion.
> 11:13:32,130 SEVERE ch.mitsa.credoc.ui.views.messages.MessagesTable (default task-9) Error getting message payload: : javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:369) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:383) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:418) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:765) rt.jar:1.7.0_71
> at _redirected.TransformerFactory.newTransformer(_TransformerFactory.java:132) jboss-modules.jar:1.3.3.Final
> at ch.mitsa.credoc.format.swift.impl.SwiftFormatter.getPrettyPrintedPayload(SwiftFormatter.java:196)
> at ch.mitsa.credoc.engine.service.OutputService.getPrettyPrintedMessage(OutputService.java:54)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) rt.jar:1.7.0_71
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) rt.jar:1.7.0_71
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) rt.jar:1.7.0_71
> at java.lang.reflect.Method.invoke(Method.java:606) rt.jar:1.7.0_71
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) wildfly-weld-8.2.0.Final.jar:8.2.0.Final
> (...)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFCORE-519) Xalan Linkage error : TransformerConfigurationException
by Theo Cleminson (JIRA)
[ https://issues.jboss.org/browse/WFCORE-519?page=com.atlassian.jira.plugin... ]
Theo Cleminson commented on WFCORE-519:
---------------------------------------
This saved my bacon too.
Here's what is working for me (Wildfly 9.01 in domain mode using full-ha profile with xmlunit v1.6)
<!-- include JDK dependencies (rt.jar) for xalan -->
<system export="true">
<paths>
<path name="com/sun/org/apache/xml/internal/dtm"/>
_ <path name="com/sun/org/apache/xml/internal/dtm/ref"/>_
<path name="com/sun/org/apache/xml/internal/serializer"/>
<path name="com/sun/org/apache/xalan/internal/xsltc"/>
<path name="com/sun/org/apache/xalan/internal/xsltc"/>
<path name="com/sun/org/apache/xalan/internal/xsltc/dom"/>
<path name="com/sun/org/apache/xalan/internal/xsltc/runtime"/>
</paths>
</system>
> Xalan Linkage error : TransformerConfigurationException
> -------------------------------------------------------
>
> Key: WFCORE-519
> URL: https://issues.jboss.org/browse/WFCORE-519
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Environment: Wildfly 8.1 & 8.2-Final
> JDK 1.7.0_45 & 1.7.0_71
> Windows & Linux
> Reporter: Stephen Kay
> Assignee: David Lloyd
> Priority: Critical
> Fix For: 1.0.0.Alpha16
>
>
> Please note that this bug wasn't present on JBoss 7.1 / same WAR artifact
> This is full staktrace from our applicaion.
> 11:13:32,130 SEVERE ch.mitsa.credoc.ui.views.messages.MessagesTable (default task-9) Error getting message payload: : javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:369) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:383) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:418) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:765) rt.jar:1.7.0_71
> at _redirected.TransformerFactory.newTransformer(_TransformerFactory.java:132) jboss-modules.jar:1.3.3.Final
> at ch.mitsa.credoc.format.swift.impl.SwiftFormatter.getPrettyPrintedPayload(SwiftFormatter.java:196)
> at ch.mitsa.credoc.engine.service.OutputService.getPrettyPrintedMessage(OutputService.java:54)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) rt.jar:1.7.0_71
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) rt.jar:1.7.0_71
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) rt.jar:1.7.0_71
> at java.lang.reflect.Method.invoke(Method.java:606) rt.jar:1.7.0_71
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) wildfly-weld-8.2.0.Final.jar:8.2.0.Final
> (...)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-2880) DsXmlDeploymentInstallProcessor passes wrong ManagementResourceRegistration to DataSourceStatisticsListener
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2880?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2880:
-----------------------------------------------
Lin Gao <lgao(a)redhat.com> changed the Status of [bug 1245363|https://bugzilla.redhat.com/show_bug.cgi?id=1245363] from ASSIGNED to POST
> DsXmlDeploymentInstallProcessor passes wrong ManagementResourceRegistration to DataSourceStatisticsListener
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2880
> URL: https://issues.jboss.org/browse/WFLY-2880
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JCA
> Affects Versions: 8.0.0.CR1
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 8.0.0.Final
>
>
> Unlike AbstractDataSourceAdd, which passes an override registration into DataSourceStatisticsListener, DsXmlDeploymentInstallProcessor passes in the main registration.
> I believe this is the cause of the following stuff in the logs Tomaz Cerar saw when messing about with the WildFly quickstarts:
> {noformat}
> 22:50:05,945 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener@1281d4a" failed: java.lang.IllegalArgumentException:
> JBAS014809: A node is already registered at '(deployment => *)(subsystem => datasources)(data-source => *)(statistics => jdbc)'
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:145) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:90) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener.transition(DataSourceStatisticsListener.java:72) [wildfly-connector-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2099) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFCORE-1029) ManagedSocketFactory doesn't work for client sockets
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1029?page=com.atlassian.jira.plugi... ]
Dennis Reed edited comment on WFCORE-1029 at 10/22/15 10:46 PM:
----------------------------------------------------------------
The exception being triggered is:
java.lang.IllegalStateException
at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.registerBinding(SocketBindingManagerImpl.java:471)
at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.registerSocket(SocketBindingManagermpl.java:496)
at org.jboss.as.clustering.jgroups.ManagedSocketFactory.register(ManagedSocketFactory.java:77)
at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createSocket(ManagedSocketFactory.java:53)
The PR for WFLY-5449 removes the registerSocket call from ManagedSocketFactory, so this is no longer an issue for that use case. WFCORE-1033 registers the socket in a different spot, and skips the call if it's not bound, resolving this.
Unless .SocketBindingManagerImpl$UnnamedRegistryImpl registry is called from elsewhere in a similar way with unbound sockets, I consider this resolved.
was (Author: dereed):
The exception being triggered is:
java.lang.IllegalStateException
at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.registerBinding(SocketBindingManagerImpl.java:471)
at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.registerSocket(SocketBindingManagermpl.java:496)
at org.jboss.as.clustering.jgroups.ManagedSocketFactory.register(ManagedSocketFactory.java:77)
at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createSocket(ManagedSocketFactory.java:53)
The PR for WFLY-5449 removes the registerSocket call from ManagedSocketFactory, so this is no longer an issue for that use case. WFCORE-1033 registers the socket in a different spot, and skips the call if it's not bound, resolving this.
> ManagedSocketFactory doesn't work for client sockets
> ----------------------------------------------------
>
> Key: WFCORE-1029
> URL: https://issues.jboss.org/browse/WFCORE-1029
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR5
> Reporter: Dennis Reed
> Assignee: Brian Stansberry
>
> SocketBindingManagerImpl does not work with client sockets.
> It adds sockets to a map based on local address. Client sockets that have not been bound yet do not have a local address.
> This breaks the JGroups subsystem's ManagedSocketFactory, which uses SocketBindingManagerImpl for both server and client sockets.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFCORE-1029) ManagedSocketFactory doesn't work for client sockets
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1029?page=com.atlassian.jira.plugi... ]
Dennis Reed edited comment on WFCORE-1029 at 10/22/15 10:43 PM:
----------------------------------------------------------------
The exception being triggered is:
java.lang.IllegalStateException
at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.registerBinding(SocketBindingManagerImpl.java:471)
at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.registerSocket(SocketBindingManagermpl.java:496)
at org.jboss.as.clustering.jgroups.ManagedSocketFactory.register(ManagedSocketFactory.java:77)
at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createSocket(ManagedSocketFactory.java:53)
The PR for WFLY-5449 removes the registerSocket call from ManagedSocketFactory, so this is no longer an issue for that use case. WFCORE-1033 registers the socket in a different spot, and skips the call if it's not bound, resolving this.
was (Author: dereed):
The exception being triggered is:
java.lang.IllegalStateException
at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.registerBinding(SocketBindingManagerImpl.java:471)
at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.registerSocket(SocketBindingManagermpl.java:496)
at org.jboss.as.clustering.jgroups.ManagedSocketFactory.register(ManagedSocketFactory.java:77)
at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createSocket(ManagedSocketFactory.java:53)
The PR for WFLY-5449 removes the registerSocket call from ManagedSocketFactory, so this is no longer an issue for that use case.
> ManagedSocketFactory doesn't work for client sockets
> ----------------------------------------------------
>
> Key: WFCORE-1029
> URL: https://issues.jboss.org/browse/WFCORE-1029
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR5
> Reporter: Dennis Reed
> Assignee: Brian Stansberry
>
> SocketBindingManagerImpl does not work with client sockets.
> It adds sockets to a map based on local address. Client sockets that have not been bound yet do not have a local address.
> This breaks the JGroups subsystem's ManagedSocketFactory, which uses SocketBindingManagerImpl for both server and client sockets.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFCORE-1029) ManagedSocketFactory doesn't work for client sockets
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1029?page=com.atlassian.jira.plugi... ]
Dennis Reed commented on WFCORE-1029:
-------------------------------------
The exception being triggered is:
java.lang.IllegalStateException
at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.registerBinding(SocketBindingManagerImpl.java:471)
at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.registerSocket(SocketBindingManagermpl.java:496)
at org.jboss.as.clustering.jgroups.ManagedSocketFactory.register(ManagedSocketFactory.java:77)
at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createSocket(ManagedSocketFactory.java:53)
The PR for WFLY-5449 removes the registerSocket call, so this is no longer an issue for that use case.
> ManagedSocketFactory doesn't work for client sockets
> ----------------------------------------------------
>
> Key: WFCORE-1029
> URL: https://issues.jboss.org/browse/WFCORE-1029
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR5
> Reporter: Dennis Reed
> Assignee: Brian Stansberry
>
> SocketBindingManagerImpl does not work with client sockets.
> It adds sockets to a map based on local address. Client sockets that have not been bound yet do not have a local address.
> This breaks the JGroups subsystem's ManagedSocketFactory, which uses SocketBindingManagerImpl for both server and client sockets.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFCORE-1029) ManagedSocketFactory doesn't work for client sockets
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1029?page=com.atlassian.jira.plugi... ]
Dennis Reed edited comment on WFCORE-1029 at 10/22/15 10:31 PM:
----------------------------------------------------------------
The exception being triggered is:
java.lang.IllegalStateException
at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.registerBinding(SocketBindingManagerImpl.java:471)
at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.registerSocket(SocketBindingManagermpl.java:496)
at org.jboss.as.clustering.jgroups.ManagedSocketFactory.register(ManagedSocketFactory.java:77)
at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createSocket(ManagedSocketFactory.java:53)
The PR for WFLY-5449 removes the registerSocket call from ManagedSocketFactory, so this is no longer an issue for that use case.
was (Author: dereed):
The exception being triggered is:
java.lang.IllegalStateException
at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.registerBinding(SocketBindingManagerImpl.java:471)
at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.registerSocket(SocketBindingManagermpl.java:496)
at org.jboss.as.clustering.jgroups.ManagedSocketFactory.register(ManagedSocketFactory.java:77)
at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createSocket(ManagedSocketFactory.java:53)
The PR for WFLY-5449 removes the registerSocket call, so this is no longer an issue for that use case.
> ManagedSocketFactory doesn't work for client sockets
> ----------------------------------------------------
>
> Key: WFCORE-1029
> URL: https://issues.jboss.org/browse/WFCORE-1029
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR5
> Reporter: Dennis Reed
> Assignee: Brian Stansberry
>
> SocketBindingManagerImpl does not work with client sockets.
> It adds sockets to a map based on local address. Client sockets that have not been bound yet do not have a local address.
> This breaks the JGroups subsystem's ManagedSocketFactory, which uses SocketBindingManagerImpl for both server and client sockets.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5562) Simplify GC logging configuration in domain mode
by James Livingston (JIRA)
[ https://issues.jboss.org/browse/WFLY-5562?page=com.atlassian.jira.plugin.... ]
James Livingston resolved WFLY-5562.
------------------------------------
Resolution: Duplicate Issue
Ah, of course it should be WFCORE, and I filed this as WFCORE-494 at the start of the year - I don't know why it didn't show up when I searched. Sorry for the noise.
> Simplify GC logging configuration in domain mode
> ------------------------------------------------
>
> Key: WFLY-5562
> URL: https://issues.jboss.org/browse/WFLY-5562
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Livingston
> Assignee: Brian Stansberry
> Priority: Minor
>
> In standalone mode, you can turn on GC logging relatively easily by adding the set of options to standalone.conf or uncommenting the section in standalone.sh/bat.
> Turning it on for managed servers in domain mode is much more complex. The main options to control GC logging can be added to the <jvm-options> in <jvm>s, but the log location in "-Xloggc:" is server specific so they do not overwrite each other. As noted on https://developer.jboss.org/thread/237355 you cannot use a substitution like "${jboss.server.log.dir}" since they are done by the host controller once and not per-server, and that is not set at resolution time. This means that every individual server in host.xml needs a <jvm><jvm-options> configuration to set that, which is tedious and error prone.
> It would be good to provide a way of configuring GC logging for managed servers in domain mode which is simpler and less likely to cause mistakes. Two mechanisms that may be options would be the following, but there may be others:
> * Supporting per-server substitutions in domain.xml <jvm> definitions, so ${jboss.server.log.dir} could be used
> * a <gc-logging> option similar to <heap>, with a few options and WF knows how to add the correction options. This may require that WF knows more about which java implementation is being used
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months