[JBoss JIRA] (AS7-4265) cli command to add/remove AS modules
by Brian Riehman (JIRA)
[ https://issues.jboss.org/browse/AS7-4265?page=com.atlassian.jira.plugin.s... ]
Brian Riehman commented on AS7-4265:
------------------------------------
A note for [~davidj] and [~madhu.garimilla]: I had the same requirement to add a file to my deployment's classpath and provide it using a module. The only solution I found was to manually specify the module XML to be used via the {{--module-xml}} argument to {{module add}}. This isn't ideal since it requires you to generate the module file, but at least it can be scripted instead of being done by hand.
> cli command to add/remove AS modules
> ------------------------------------
>
> Key: AS7-4265
> URL: https://issues.jboss.org/browse/AS7-4265
> Project: Application Server 7
> Issue Type: Task
> Components: CLI
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
> Fix For: 7.1.2.Final (EAP)
>
>
> I think it'd be useful to have a command to add modules to the AS which given the jars, dependencies, etc would generate the structure in the modules dir, copy the jars and generate the xml.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (DROOLS-537) Use maven plugins (animal-sniffer?) to ensure that code and dependencies conform to the supported minimum version
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-537?page=com.atlassian.jira.plugin... ]
Petr Široký commented on DROOLS-537:
------------------------------------
I checked that all the repos (master branch) can be successfully built with the animal-sniffer plugin enabled. Tried with Oracle JDKs 6,7,8. Still need to measure the impact on the build speed.
> Use maven plugins (animal-sniffer?) to ensure that code and dependencies conform to the supported minimum version
> -----------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-537
> URL: https://issues.jboss.org/browse/DROOLS-537
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.1.0.CR1
> Reporter: Marco Rietveld
> Assignee: Petr Široký
>
> Every now and then, one of us uses syntax or a class from a higher version of Java than what we use.
> Or otherwise, one of us will use a dependency that's been compiled in Java X+1 while the build is based on Java X.
> Can we prevent discovering these mistakes too late by using the animal-sniffer plugin?
> One of the more important points here is that using the animal-sniffer (or another plugin that can be used for this) must *not* significantly delay or prolong the build!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 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 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)
10 years, 8 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)
10 years, 8 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)
10 years, 8 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)
10 years, 8 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)
10 years, 8 months