[JBoss JIRA] (WFLY-4487) Unable to inject Web Service Context into CDI Interceptor
by Mustafa Musaji (JIRA)
Mustafa Musaji created WFLY-4487:
------------------------------------
Summary: Unable to inject Web Service Context into CDI Interceptor
Key: WFLY-4487
URL: https://issues.jboss.org/browse/WFLY-4487
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Affects Versions: 9.0.0.Alpha1
Reporter: Mustafa Musaji
Assignee: Stuart Douglas
Fix For: 9.0.0.Beta1
CDI Interceptor cannot inject EJB session context.
If the Interceptor is changed to EJB interceptor by removing the @Interceptor on the interceptor and removing it from the beans.xml, and adding @Interceptors(...) to the EJB, then it is able to inject.
See attached reproducer with source and log file.
private @Resource SessionContext sessionContext;
Caused by: javax.naming.NameNotFoundException: env/test.ServiceLoggedInterceptor/sessionContext -- service jboss.naming.context.java.comp.inject-ejb-context-into-cdi-interceptor.inject-ejb-context-into-cdi-interceptor.HelloEJB.env."test.ServiceLoggedInterceptor".sessionContext
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51]
at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51]
at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:185)
... 127 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4423) ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4423?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4423:
-----------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1201358|https://bugzilla.redhat.com/show_bug.cgi?id=1201358] from NEW to POST
> ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory
> ----------------------------------------------------------------------------
>
> Key: WFLY-4423
> URL: https://issues.jboss.org/browse/WFLY-4423
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 9.0.0.Alpha1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Beta1
>
>
> To reproduce this issue follow the steps:
> - setup JMS bridge between two WildFly instances
> - once JMS bridge is running, login into jboss-cli and stop the bridge
> - restart the bridge fro jboss-cli
> The following exception appears in the serve log file.
> 10:12:59,414 INFO [org.hornetq.jms.server] (pool-9-thread-1) HQ121000: Failed to set up JMS bridge connections. Most probably the source or target servers are unavailable. Will retry after a pause of 60,000 ms
> 10:13:59,416 WARN [org.hornetq.jms.server] (pool-9-thread-1) HQ122010: Failed to connect JMS Bridge: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.jboss.naming.remote.client.InitialContextFactory from classloader ModuleClassLoader for Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory from [Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base))]]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:126)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:107)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_75]
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:98)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:44)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_75]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_75]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_75]
> at javax.naming.InitialContext.<init>(InitialContext.java:216) [rt.jar:1.7.0_75]
> at org.hornetq.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:55)
> at org.hornetq.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:40)
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1236)
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1474)
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl.access$2200(JMSBridgeImpl.java:79)
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:2082)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]
> Caused by: java.lang.ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory from [Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_75]
> at java.lang.Class.forName(Class.java:274) [rt.jar:1.7.0_75]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:121)
> ... 17 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (SECURITY-878) Container-provided security role "**" (EJB 3.2) not working
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/SECURITY-878?page=com.atlassian.jira.plug... ]
Stuart Douglas reassigned SECURITY-878:
---------------------------------------
Assignee: Stefan Guilhen (was: Stuart Douglas)
EJB authentication support is now provided by PicketBox, it is not actually part of the Wildfly code base.
> Container-provided security role "**" (EJB 3.2) not working
> -----------------------------------------------------------
>
> Key: SECURITY-878
> URL: https://issues.jboss.org/browse/SECURITY-878
> Project: PicketBox
> Issue Type: Bug
> Affects Versions: PicketBox_4_0_21.Final
> Reporter: Jan Martiska
> Assignee: Stefan Guilhen
>
> EJB 3.2 12.3.1 Security Roles:
> {quote}
> A security role with the name “**” is defined by the Container, and is intended to be used by the Bean
> Provider, Application Assembler, or Deployer to indicate that the caller must log on or authenticate to
> invoke a method or to perform some processing requiring membership in this container role. This con-
> tainer security role indicates that authentication, without consideration of role membership, is required.
> {quote}
> This doesn't seem to work in WildFly 9.0.0.Beta1. An authenticated user trying to invoke methods annotated @PermitAll("**") gets an EJBAccessException.
> I started preparing tests for this behavior at https://github.com/jmartisk/wildfly/commits/master-ejb32tests-starrole
> It causes failures in:
> InherritanceAnnSFSBTestCase.testSingleMethodAnnotationsUser1
> InherritanceAnnSLSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSFSBtoSFSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSFSBtoSLSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSLSBtoSFSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSLSBtoSLSBTestCase.testSingleMethodAnnotationsUser1
> SingleMethodsAnnSFSBTestCase.testSingleMethodAnnotationsUser1
> SingleMethodsAnnSLSBTestCase.testSingleMethodAnnotationsUser1
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (SECURITY-878) Container-provided security role "**" (EJB 3.2) not working
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/SECURITY-878?page=com.atlassian.jira.plug... ]
Stuart Douglas moved WFLY-4474 to SECURITY-878:
-----------------------------------------------
Project: PicketBox (was: WildFly)
Key: SECURITY-878 (was: WFLY-4474)
Workflow: classic default workflow (was: GIT Pull Request workflow )
Affects Version/s: PicketBox_4_0_21.Final
(was: 9.0.0.Beta1)
> Container-provided security role "**" (EJB 3.2) not working
> -----------------------------------------------------------
>
> Key: SECURITY-878
> URL: https://issues.jboss.org/browse/SECURITY-878
> Project: PicketBox
> Issue Type: Bug
> Affects Versions: PicketBox_4_0_21.Final
> Reporter: Jan Martiska
> Assignee: Stuart Douglas
>
> EJB 3.2 12.3.1 Security Roles:
> {quote}
> A security role with the name “**” is defined by the Container, and is intended to be used by the Bean
> Provider, Application Assembler, or Deployer to indicate that the caller must log on or authenticate to
> invoke a method or to perform some processing requiring membership in this container role. This con-
> tainer security role indicates that authentication, without consideration of role membership, is required.
> {quote}
> This doesn't seem to work in WildFly 9.0.0.Beta1. An authenticated user trying to invoke methods annotated @PermitAll("**") gets an EJBAccessException.
> I started preparing tests for this behavior at https://github.com/jmartisk/wildfly/commits/master-ejb32tests-starrole
> It causes failures in:
> InherritanceAnnSFSBTestCase.testSingleMethodAnnotationsUser1
> InherritanceAnnSLSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSFSBtoSFSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSFSBtoSLSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSLSBtoSFSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSLSBtoSLSBTestCase.testSingleMethodAnnotationsUser1
> SingleMethodsAnnSFSBTestCase.testSingleMethodAnnotationsUser1
> SingleMethodsAnnSLSBTestCase.testSingleMethodAnnotationsUser1
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-627) Response headers do not propagate through the domain
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-627:
---------------------------------------
Summary: Response headers do not propagate through the domain
Key: WFCORE-627
URL: https://issues.jboss.org/browse/WFCORE-627
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 1.0.0.Beta2
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 1.0.0.CR1
There's no access-control response header here:
{code}
[domain@localhost:9999 /] /host=master/server=server-one/subsystem=datasources/data-source=ExampleDS:read-resource{roles=Monitor}
{
"outcome" => "success",
"result" => {
....
}
}
{code}
ProxyStepHandler needs to pass through response-header data.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-626) Global list-get operation can inadvertently create list elements
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFCORE-626?page=com.atlassian.jira.plugin... ]
Paul Ferraro updated WFCORE-626:
--------------------------------
Summary: Global list-get operation can inadvertently create list elements (was: Global list-get operation can inadvertently create list elements.)
> Global list-get operation can inadvertently create list elements
> ----------------------------------------------------------------
>
> Key: WFCORE-626
> URL: https://issues.jboss.org/browse/WFCORE-626
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 1.0.0.CR1
>
>
> Consider the following sequence of operations:
> # :list-clear(name=attribute)
> # :list-get(name=attribute, index=0)
> # :list-add(name=attribute, value=test)
> # :list-get(name=attribute, index=0)
> #2 will return <undefined> as expected. The expected result of #4 is "test". However, it returns <undefined>. This is because #2 will create the missing element at index 0 causing #3 to operate on index 1.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-626) Global list-get operation can inadvertently create list elements.
by Paul Ferraro (JIRA)
Paul Ferraro created WFCORE-626:
-----------------------------------
Summary: Global list-get operation can inadvertently create list elements.
Key: WFCORE-626
URL: https://issues.jboss.org/browse/WFCORE-626
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 1.0.0.Beta2
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 1.0.0.CR1
Consider the following sequence of operations:
# :list-clear(name=attribute)
# :list-get(name=attribute, index=0)
# :list-add(name=attribute, value=test)
# :list-get(name=attribute, index=0)
#2 will return <undefined> as expected. The expected result of #4 is "test". However, it returns <undefined>. This is because #2 will create the missing element at index 0 causing #3 to operate on index 1.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (JBJCA-1259) Tracer improvements
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1259?page=com.atlassian.jira.plugin... ]
Jesper Pedersen updated JBJCA-1259:
-----------------------------------
Description:
Add the following events:
* PUSH_CCM_CONTEXT
* POP_CCM_CONTEXT
* REGISTER_CCM_CONNECTION
* UNREGISTER_CCM_CONNECTION
* CCM_USER_TRANSACTION
* UNKNOWN_CCM_CONNECTION
* CLOSE_CCM_CONNECTION
* VERSION
Add 2nd payload field
Create reports for CCM interaction
Add -ignore-tracking command line option
Reference guides for connections, connection listeners and managed connection pools
was:
Add the following events:
* PUSH_CCM_CONTEXT
* POP_CCM_CONTEXT
* REGISTER_CCM_CONNECTION
* UNREGISTER_CCM_CONNECTION
* CCM_USER_TRANSACTION
* UNKNOWN_CCM_CONNECTION
* CLOSE_CCM_CONNECTION
* VERSION
Add 2nd payload field
Create reports for CCM interaction
Add -ignore-tracking command line option
> Tracer improvements
> -------------------
>
> Key: JBJCA-1259
> URL: https://issues.jboss.org/browse/JBJCA-1259
> Project: IronJacamar
> Issue Type: Task
> Components: Core
> Reporter: Jesper Pedersen
> Assignee: Jesper Pedersen
> Fix For: 1.2.4.Final
>
>
> Add the following events:
> * PUSH_CCM_CONTEXT
> * POP_CCM_CONTEXT
> * REGISTER_CCM_CONNECTION
> * UNREGISTER_CCM_CONNECTION
> * CCM_USER_TRANSACTION
> * UNKNOWN_CCM_CONNECTION
> * CLOSE_CCM_CONNECTION
> * VERSION
> Add 2nd payload field
> Create reports for CCM interaction
> Add -ignore-tracking command line option
> Reference guides for connections, connection listeners and managed connection pools
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4486) When i try to stop the wildfly server using services its not stopping, status is always in stopping state.
by masthan shaik (JIRA)
masthan shaik created WFLY-4486:
-----------------------------------
Summary: When i try to stop the wildfly server using services its not stopping, status is always in stopping state.
Key: WFLY-4486
URL: https://issues.jboss.org/browse/WFLY-4486
Project: WildFly
Issue Type: Bug
Components: Server
Affects Versions: 8.1.0.Final, 8.0.0.Final
Environment: windows 7 operating system,(64bit),Java,web services,jsp,servlets,flex,ejb
Reporter: masthan shaik
Assignee: Jason Greene
Hi ,
i have installed wildfly server (version 8.1.0) as a service on win7 64 bit machine.
When try to stop the service , it is not stopping properly , always status is in stopping state.
manually i am killing the java .exe and wildfly-server.exe from task manager and then starting server again.
please let me know how to resolve this isssue.
Thanks
mastan
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4485) Don't Expose JDT Compiler to Web Applications
by Philippe Marschall (JIRA)
[ https://issues.jboss.org/browse/WFLY-4485?page=com.atlassian.jira.plugin.... ]
Philippe Marschall commented on WFLY-4485:
------------------------------------------
Is a regression
> Don't Expose JDT Compiler to Web Applications
> ---------------------------------------------
>
> Key: WFLY-4485
> URL: https://issues.jboss.org/browse/WFLY-4485
> Project: WildFly
> Issue Type: Enhancement
> Components: Web (Undertow)
> Affects Versions: 9.0.0.Beta2
> Reporter: Philippe Marschall
> Assignee: Stuart Douglas
> Labels: classloading, jsp
>
> Currently the Eclipse JDT compiler is exposed to web applications because the undertow servlet module exposes all its dependencies.
> This can break applications that ship their own version of the Eclipse JDT compiler like the Cocoon web framework.
> This seems to be a regression. It was already fixed once in WFLY-1770 but seems to be an issue again since undertow JSP is now once again one instead of two modules.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months