[JBoss JIRA] (WFLY-3830) Use external-context for remote TIBCO ems lookup
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-3830?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-3830:
------------------------------
Comment: was deleted
(was: As explained in the PR, the TIBCO JNDI provider accepts only CompoundName in its lookup(Name) method.
With the PR, it is possible to use the external-context with TIBCO EMS by using the StringOnlyInitialContext wrapper that convert the lookup(Name) call to the corresponding lookup(String) call.
{noformat}
<external-context name="java:global/tibco" module="com.tibco" class="org.jboss.as.naming.StringOnlyInitialContext">
<environment>
<property name="java.naming.factory.initial" value="com.tibco.tibjms.naming.TibjmsInitialContextFactory"/>
<property name="java.naming.provider.url" value="tcp:/<server>:<port>"/>
<property name="java.naming.factory.url.pkgs" value="com.tibco.tibjms.naming"/>
</environment>
</external-context>
{noformat}
Note that the com.tibco module *must* have a dependency on the org.jboss.as.naming module to access this wrapper.
)
> Use external-context for remote TIBCO ems lookup
> ------------------------------------------------
>
> Key: WFLY-3830
> URL: https://issues.jboss.org/browse/WFLY-3830
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.1.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> If an users uses the generic JMS RA with the TIBCO EMS messaging server, he has to duplicate all the JNDI parameters in the MDB annotations.
> Instead, he should be able to use a naming's external-context to connect to the Remote TIBCO server with the following configuration:
> {noformat}
> <bindings>
> <external-context name="java:global/tibco" module="com.tibco" class="javax.naming.InitialContext">
> <environment>
> <property name="java.naming.factory.initial" value="com.tibco.tibjms.naming.TibjmsInitialContextFactory"/>
> <property name="java.naming.provider.url" value="tcp://<tibco_server>:<tibco_port>"/>
> <property name="java.naming.factory.url.pkgs" value="com.tibco.tibjms.naming"/>
> </environment>
> </external-context>
> </bindings>
> {noformat}
> With these settings, the user only needs to pass the expected connection factory and destination lookup in the MDB:
> {noformat}
> @ActivationConfigProperty(propertyName = "connectionFactory", propertyValue = "java:global/tibco/XACF"),
> @ActivationConfigProperty(propertyName = "destination", propertyValue = "java:global/tibco/Q1"),
> {noformat}
> The local JNDI lookup "java:global/tibco/Q1" will then use the external context (bound to "java:global/tibco") to lookup the "Q1" name on the TIBCO EMS.
> There are a few bugs in the ExternalObjectFactory that prevents to use this configuration with a regular javax.naming.InitialContext to build the external context.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (WFLY-4037) Error 500 accessing png, css, rest
by Marcial Atiénzar Navarro (JIRA)
[ https://issues.jboss.org/browse/WFLY-4037?page=com.atlassian.jira.plugin.... ]
Marcial Atiénzar Navarro commented on WFLY-4037:
------------------------------------------------
I've try this:
{code}
/subsystem=infinispan/cache-container=web:remove
{
"outcome" => "failed",
"failure-description" => "JBAS014762: Removing services has lead to unsatisfied dependencies:
Service jboss.infinispan.affinity.web was depended upon by service jboss.undertow.server.default-server.default-host.single-sign-on.manager.factory.distributable
Service jboss.infinispan.web.global-component-registry was depended upon by service jboss.infinispan.web.default-host
Service jboss.infinispan.web was depended upon by service jboss.infinispan.web.default-host.config, service jboss.infinispan.web.default-host",
"rolled-back" => true
}
{code}
I can't remove cache of web container because I use SSO, and seems that I depends of this cache also.
> Error 500 accessing png,css, rest
> ---------------------------------
>
> Key: WFLY-4037
> URL: https://issues.jboss.org/browse/WFLY-4037
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Reporter: Marcial Atiénzar Navarro
> Assignee: Stuart Douglas
> Priority: Critical
>
> I've this error:
> {code}
> 09:37:41,261 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /common/publico/auth/isUsarioAutenticado: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=146}, status=1} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275)
> at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.CacheImpl.get(CacheImpl.java:377)
> at org.infinispan.CacheImpl.get(CacheImpl.java:369)
> at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271)
> at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54)
> at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
> at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
> at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:77)
> at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:38)
> at org.wildfly.clustering.web.infinispan.sso.InfinispanSSOManager.findSSO(InfinispanSSOManager.java:50)
> at org.wildfly.clustering.web.undertow.sso.DistributableSingleSignOnManager.findSingleSignOn(DistributableSingleSignOnManager.java:77)
> at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:53) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (WFLY-4037) Error 500 accessing png, css, rest
by Marcial Atiénzar Navarro (JIRA)
Marcial Atiénzar Navarro created WFLY-4037:
----------------------------------------------
Summary: Error 500 accessing png,css, rest
Key: WFLY-4037
URL: https://issues.jboss.org/browse/WFLY-4037
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.1.0.Final
Reporter: Marcial Atiénzar Navarro
Assignee: Stuart Douglas
Priority: Critical
I've this error:
{code}
09:37:41,261 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /common/publico/auth/isUsarioAutenticado: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=146}, status=1} is not in a valid state to be invoking cache operations on.
at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275)
at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231)
at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225)
at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
at org.infinispan.CacheImpl.get(CacheImpl.java:377)
at org.infinispan.CacheImpl.get(CacheImpl.java:369)
at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271)
at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54)
at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:77)
at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:38)
at org.wildfly.clustering.web.infinispan.sso.InfinispanSSOManager.findSSO(InfinispanSSOManager.java:50)
at org.wildfly.clustering.web.undertow.sso.DistributableSingleSignOnManager.findSingleSignOn(DistributableSingleSignOnManager.java:77)
at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:53) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (WFLY-4030) wildfly-javaee7-webapp-blank-archetype using old namespaces for beans.xml and faces-config.xml
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/WFLY-4030?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on WFLY-4030:
-------------------------------------------
Hi [~rafabene]!
Thanks for the hint!
I noticed that there are some files in those archetypes, but as you mentioned - they are replaced while syncing with Quickstarts. Maybe it would be a good idea to remove all those files and add some readme note that everything is downloaded from Quickstarts and all changes should be implemented there?
I have also a small question - how to release those updated archetypes (after https://github.com/wildfly/quickstart/pull/45 is merged) to Maven repository?
> wildfly-javaee7-webapp-blank-archetype using old namespaces for beans.xml and faces-config.xml
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-4030
> URL: https://issues.jboss.org/browse/WFLY-4030
> Project: WildFly
> Issue Type: Bug
> Reporter: Arun Gupta
> Assignee: Sebastian Łaskawiec
> Priority: Minor
> Labels: archetypes, maven, wildfly
>
> mvn archetype:generate -DgroupId=test -DartifactId=test -DarchetypeGroupId=org.wildfly.archetype -DarchetypeArtifactId=wildfly-javaee7-webapp-blank-archetype -DarchetypeVersion=8.1.0.Final
> The app has the following files:
> ./src/main/webapp/WEB-INF/beans.xml
> ./src/main/webapp/WEB-INF/faces-config.xml
> beans.xml and faces-config.xml are using java.sun.com-style namespaces instead of xmlns.jcp.org-style namespaces.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (WFLY-4036) update EclipseLink/OpenJPA test case to filter out javax.persistence classes
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-4036?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-4036:
-------------------------------
Attachment: stacktrace.txt
> update EclipseLink/OpenJPA test case to filter out javax.persistence classes
> ----------------------------------------------------------------------------
>
> Key: WFLY-4036
> URL: https://issues.jboss.org/browse/WFLY-4036
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 9.0.0.Beta1
>
> Attachments: module.xml, module.xml, stacktrace.txt
>
>
> WildFly-core upgrade is improving the case when two deployments have bi-directional dependencies (a depends on b and b depends on a). Part of this is ensuring that application level classes are used over classes from dependencies.
> This introduces an issue for application that include api jars or other jars that previlously used to be overriden by dependency level classes.
> This jira is about fixing this for two of our unit tests that willl have this problem (an EclipseLink + OpenJPA test).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (WFLY-3900) Unable to inject EJB Context into CDI Interceptor
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3900?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3900:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1149644, https://bugzilla.redhat.com/show_bug.cgi?id=1149646 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1149644)
> Unable to inject EJB Context into CDI Interceptor
> -------------------------------------------------
>
> Key: WFLY-3900
> URL: https://issues.jboss.org/browse/WFLY-3900
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brad Maxwell
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
> Attachments: inject-ejb-context-into-cdi-interceptor.jar, server.log
>
>
> 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.1#6329)
11 years, 6 months
[JBoss JIRA] (ELY-102) MD5 Compatibility tests failing on Windows
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-102?page=com.atlassian.jira.plugin.sy... ]
David Lloyd resolved ELY-102.
-----------------------------
Fix Version/s: 1.0.0.Beta1
Resolution: Done
Seems fixed.
> MD5 Compatibility tests failing on Windows
> ------------------------------------------
>
> Key: ELY-102
> URL: https://issues.jboss.org/browse/ELY-102
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Reporter: David Lloyd
> Assignee: Peter Skopek
> Fix For: 1.0.0.Beta1
>
>
> The following tests fail on Windows or any platform which does not have UTF-8 as its default encoding:
> * CompatibilityClientTest.testUtf8Charset
> * CompatibilityServerTest.testUtf8Charset
> Can be reproduced on Linux on the command line by setting the LANG environment variable to something other than UTF_8, like ISO-8859-1.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (ELY-101) GSSAPI failures on Windows
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-101?page=com.atlassian.jira.plugin.sy... ]
David Lloyd resolved ELY-101.
-----------------------------
Resolution: Done
Seems fixed.
> GSSAPI failures on Windows
> --------------------------
>
> Key: ELY-101
> URL: https://issues.jboss.org/browse/ELY-101
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Environment: Windows
> Reporter: David Lloyd
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> The following GSSAPI tests fail on Windows for reasons unknown (probably not character encoding though):
> * BasicAuthTest.testAuth
> * BasicConfidenceTest.testAuthConf
> * BasicIntegrityTest.testAuthInt
> * NoServerAuthTest.testAuth
>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months