[JBoss JIRA] (WFCORE-519) Xalan Linkage error : TransformerConfigurationException
by Barnabas Bodnar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-519?page=com.atlassian.jira.plugin... ]
Barnabas Bodnar edited comment on WFCORE-519 at 4/29/15 10:26 AM:
------------------------------------------------------------------
An other workaround, if the application must not be changed: insert the following elements (java-packages) into <Widlfly installation directory>/modules/system/layers/base/sun/jdk/main/modules.xml:
<path name="com/sun/org/apache/xml/internal/serializer"/>
<path name="com/sun/org/apache/xml/internal/dtm"/>
<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"/>
was (Author: bbodnar):
An other workaround: insert the following elements (java-packages) into <Widlfly installation directory>/modules/system/layers/base/sun/jdk/main/modules.xml:
<path name="com/sun/org/apache/xml/internal/serializer"/>
<path name="com/sun/org/apache/xml/internal/dtm"/>
<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"/>
> 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.3.15#6346)
9 years, 3 months
[JBoss JIRA] (WFCORE-519) Xalan Linkage error : TransformerConfigurationException
by Barnabas Bodnar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-519?page=com.atlassian.jira.plugin... ]
Barnabas Bodnar commented on WFCORE-519:
----------------------------------------
An other workaround: insert the following elements (java-packages) into <Widlfly installation directory>/modules/system/layers/base/sun/jdk/main/modules.xml:
<path name="com/sun/org/apache/xml/internal/serializer"/>
<path name="com/sun/org/apache/xml/internal/dtm"/>
<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"/>
> 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.3.15#6346)
9 years, 3 months
[JBoss JIRA] (WFLY-3590) Option to disable processing of authentication tokens on unsecured resources.
by Joachim Klausner (JIRA)
[ https://issues.jboss.org/browse/WFLY-3590?page=com.atlassian.jira.plugin.... ]
Joachim Klausner edited comment on WFLY-3590 at 4/29/15 7:15 AM:
-----------------------------------------------------------------
Here's a scenario which may justify the addition of such an option:
My application simulates "logout" with Basic Authentification by sending invalid credentials (logout/logout) to an unsecured servlet, which only accepts logout/logout and replies with 401 otherwise. This clears the credential cache of the browser, so the user is prompted to enter new credentials when he redirects to other (secured) URLs of the application.
Works with JBoss AS 7.x but does not work anymore with WildFly 8.2.
was (Author: klausjac):
Here's a scenario which may justify the addition of such an option:
My application simulates "logout" with Basic Authentification by sending invalid credentials (logout/logout) to an unsecured servlet, which only accepts logout/logout and replies with 401 otherwise. This clears the credential cache of the browser, so the user is prompted to enter new credentials when he redirects to other (secured) URLs of the application.
Works with JBoss AS 7.x but does not anymore with WildFly 8.2.
> Option to disable processing of authentication tokens on unsecured resources.
> -----------------------------------------------------------------------------
>
> Key: WFLY-3590
> URL: https://issues.jboss.org/browse/WFLY-3590
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Oracle Java 1.8.0_05, Ubuntu 14.04
> Reporter: Harald Wellmann
> Assignee: Darran Lofthouse
> Fix For: 10.0.0.Alpha1
>
>
> WildFly sends a basic authentication challenge and denies access when it shouldn't in the following simple setup:
> {code:xml}
> <login-config>
> <auth-method>BASIC</auth-method>
> <realm-name>test</realm-name>
> </login-config>
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>all</web-resource-name>
> <url-pattern>/hello</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>USER</role-name>
> </auth-constraint>
> </security-constraint>
>
> <security-role>
> <role-name>USER</role-name>
> </security-role>
> {code}
> {{/hello}} is the only protected URL (mapped to a servlet), other URLs like {{/index.html}} are public.
> When GETting /index.html with an (unneeded) basic authentication header, access is denied:
> {noformat}
> $ curl -v -u foo:bar http://localhost:8080/auth-basic/index.html
> * Hostname was NOT found in DNS cache
> * Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 8080 (#0)
> * Server auth using Basic with user 'foo'
> > GET /auth-basic/index.html HTTP/1.1
> > Authorization: Basic Zm9vOmJhcg==
> > User-Agent: curl/7.35.0
> > Host: localhost:8080
> > Accept: */*
> >
> < HTTP/1.1 401 Unauthorized
> < Connection: keep-alive
> * Authentication problem. Ignoring this.
> < WWW-Authenticate: Basic realm="test"
> < X-Powered-By: Undertow/1
> * Server WildFly/8 is not blacklisted
> < Server: WildFly/8
> < Content-Type: text/html;charset=ISO-8859-1
> < Content-Length: 71
> < Date: Mon, 07 Jul 2014 17:28:25 GMT
> <
> * Connection #0 to host localhost left intact
> <html><head><title>Error</title></head><body>Unauthorized</body></html>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 3 months
[JBoss JIRA] (WFLY-3590) Option to disable processing of authentication tokens on unsecured resources.
by Joachim Klausner (JIRA)
[ https://issues.jboss.org/browse/WFLY-3590?page=com.atlassian.jira.plugin.... ]
Joachim Klausner commented on WFLY-3590:
----------------------------------------
Here's a scenario which may justify the addition of such an option:
My application simulates "logout" with Basic Authentification by sending invalid credentials (logout/logout) to an unsecured servlet, which only accepts logout/logout and replies with 401 otherwise. This clears the credential cache of the browser, so the user is prompted to enter new credentials when he redirects to other (secured) URLs of the application.
Works with JBoss AS 7.x but does not anymore with WildFly 8.2.
> Option to disable processing of authentication tokens on unsecured resources.
> -----------------------------------------------------------------------------
>
> Key: WFLY-3590
> URL: https://issues.jboss.org/browse/WFLY-3590
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Oracle Java 1.8.0_05, Ubuntu 14.04
> Reporter: Harald Wellmann
> Assignee: Darran Lofthouse
> Fix For: 10.0.0.Alpha1
>
>
> WildFly sends a basic authentication challenge and denies access when it shouldn't in the following simple setup:
> {code:xml}
> <login-config>
> <auth-method>BASIC</auth-method>
> <realm-name>test</realm-name>
> </login-config>
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>all</web-resource-name>
> <url-pattern>/hello</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>USER</role-name>
> </auth-constraint>
> </security-constraint>
>
> <security-role>
> <role-name>USER</role-name>
> </security-role>
> {code}
> {{/hello}} is the only protected URL (mapped to a servlet), other URLs like {{/index.html}} are public.
> When GETting /index.html with an (unneeded) basic authentication header, access is denied:
> {noformat}
> $ curl -v -u foo:bar http://localhost:8080/auth-basic/index.html
> * Hostname was NOT found in DNS cache
> * Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 8080 (#0)
> * Server auth using Basic with user 'foo'
> > GET /auth-basic/index.html HTTP/1.1
> > Authorization: Basic Zm9vOmJhcg==
> > User-Agent: curl/7.35.0
> > Host: localhost:8080
> > Accept: */*
> >
> < HTTP/1.1 401 Unauthorized
> < Connection: keep-alive
> * Authentication problem. Ignoring this.
> < WWW-Authenticate: Basic realm="test"
> < X-Powered-By: Undertow/1
> * Server WildFly/8 is not blacklisted
> < Server: WildFly/8
> < Content-Type: text/html;charset=ISO-8859-1
> < Content-Length: 71
> < Date: Mon, 07 Jul 2014 17:28:25 GMT
> <
> * Connection #0 to host localhost left intact
> <html><head><title>Error</title></head><body>Unauthorized</body></html>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 3 months
[JBoss JIRA] (DROOLS-775) Performance degradation with objects with many properties in working memory.
by Federico Bertola (JIRA)
[ https://issues.jboss.org/browse/DROOLS-775?page=com.atlassian.jira.plugin... ]
Federico Bertola commented on DROOLS-775:
-----------------------------------------
With the changes in the PR, I'm able to reach this sweet performance peak:
-- Meters ----------------------------------------------------------------------
org.acme.test.drools6.DroolsPerformance.analized
count = 100000
mean rate = 1475.60 events/second
> Performance degradation with objects with many properties in working memory.
> ----------------------------------------------------------------------------
>
> Key: DROOLS-775
> URL: https://issues.jboss.org/browse/DROOLS-775
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.Final
> Environment: Ubuntu 14.10 x64, jdk 8
> Reporter: Federico Bertola
> Assignee: Mario Fusco
> Labels: regression
> Attachments: drools-test.zip
>
>
> I experience some major performance degradation while migrating from drools 5.0.1 to 6.x. I'm inserting objects with many properties into the working memory and firing some very basic rules which will match against a very small subset of those properties. I expected that the older version of Drools, which uses pure reflection, to be somewhat slower than the newer, which uses some clever ASM optimization., but this is not the case. I've also noticed that if the required properties are scattered across multiple level of hierarchy, the performance issue will aggravate.
> For example, after 100k iterations:
> droosl 5.0.1
> -- Meters ----------------------------------------------------------------------
> org.acme.test.drools5.DroolsPerformance.analized
> count = 100000
> mean rate = 549.27 events/second
> ...
> drools 6.2.0.Final
> -- Meters ----------------------------------------------------------------------
> org.acme.test.drools6.DroolsPerformance.analized
> count = 100000
> mean rate = 198.58 events/second
> ...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 3 months
[JBoss JIRA] (WFLY-4570) wildfly-init-debian.sh fails on Ubuntu 15.04
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-4570?page=com.atlassian.jira.plugin.... ]
Thomas Diesler reassigned WFLY-4570:
------------------------------------
Assignee: Jason Greene (was: Thomas Diesler)
Component/s: (was: ConfigAdmin)
> wildfly-init-debian.sh fails on Ubuntu 15.04
> --------------------------------------------
>
> Key: WFLY-4570
> URL: https://issues.jboss.org/browse/WFLY-4570
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.0.Beta2, 9.0.0.CR1
> Environment: Ubuntu 15.04, Oracle JDK_1.8.0_45-b14
> Reporter: Dennis Gesker
> Assignee: Jason Greene
> Priority: Minor
> Fix For: 9.0.0.CR1
>
>
> Init script "wildfly-init-debian.sh" fails on Ubuntu 15.04 but standalone.sh works fine. Env is jdk_1.8.0_45-b14 and wildfly_9.0.0.Beta2. The error returned is:
> Failed to start wildfly.service: Unit wildfly.service failed to load: No such file or directory.
> Had no issue with the above script on Ubuntu 14.04 so guessing a change in Ubuntu ("Upstart" Maybe?) But, I'm far from an upstart or bash expert. bash -x seems to at least create the pid.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 3 months
[JBoss JIRA] (WFCORE-668) Make the INFO logging from deprecated attributes configurable, also improve the message
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-668?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated WFCORE-668:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1213421
> Make the INFO logging from deprecated attributes configurable, also improve the message
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-668
> URL: https://issues.jboss.org/browse/WFCORE-668
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.CR1
>
>
> The INFO logging that AttributeDefinition generates when a deprecated attribute is used needs to be configurable, i.e. with a boolean flag so a dev can turn it off for attributes where it serves no purpose.
> The logging only serves a purpose if an admin can take action to use some alternative config. If an attribute is deprecated only because in some future release it will go away, but there's no replacement now, the logging is just noise.
> The log message itself should be improved:
> 1) Get rid of the ! at the end. It's not that exciting. ;)
> 2) Include the address of the resource
> 3) Point the user at the read-resource-description output from which they can learn more about the deprecation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 3 months
[JBoss JIRA] (WFCORE-668) Make the INFO logging from deprecated attributes configurable, also improve the message
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-668:
---------------------------------------
Summary: Make the INFO logging from deprecated attributes configurable, also improve the message
Key: WFCORE-668
URL: https://issues.jboss.org/browse/WFCORE-668
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 1.0.0.CR1
The INFO logging that AttributeDefinition generates when a deprecated attribute is used needs to be configurable, i.e. with a boolean flag so a dev can turn it off for attributes where it serves no purpose.
The logging only serves a purpose if an admin can take action to use some alternative config. If an attribute is deprecated only because in some future release it will go away, but there's no replacement now, the logging is just noise.
The log message itself should be improved:
1) Get rid of the ! at the end. It's not that exciting. ;)
2) Include the address of the resource
3) Point the user at the read-resource-description output from which they can learn more about the deprecation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 3 months