[JBoss JIRA] (WFLY-4296) remove _ds.xml deployment support
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4296?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-4296:
-----------------------------------
This is being removed as it cannot be properly supported/implemented in all scenarios in which server and its tooling operates, and as such is causing more problems that it solves.
Currently only scenario where it kinda works ok is in standalone mode when you are doing application developing.
And when you keep this in mind you can see that EE6+ feature http://docs.oracle.com/javaee/7/api/javax/annotation/sql/DataSourceDefini... more than satisfies it.
What it lacks is if nothing else full support for deployment in domain, runtime statistics & management operations.
This brings confusion to users as data sources behave differently depending how they are deployed.
When this was initially implemented it was only done to ease migration from AS < 7 to 7+ where this was only way to deploy datasources.
> remove _ds.xml deployment support
> ---------------------------------
>
> Key: WFLY-4296
> URL: https://issues.jboss.org/browse/WFLY-4296
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
> Fix For: No Release
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[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)
11 years
[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)
11 years
[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)
11 years
[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)
11 years
[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)
11 years