[JBoss JIRA] (WFLY-3974) Move 'Channel end notification received, closing channel' to DEBUG
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3974?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3974:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1153281|https://bugzilla.redhat.com/show_bug.cgi?id=1153281] from MODIFIED to ON_QA
> Move 'Channel end notification received, closing channel' to DEBUG
> ------------------------------------------------------------------
>
> Key: WFLY-3974
> URL: https://issues.jboss.org/browse/WFLY-3974
> Project: WildFly
> Issue Type: Enhancement
> Components: Naming
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: 9.0.0.Beta1
>
>
> When a remote jms queue is located the following is seen:
> 2014-09-25 16:48:29,327 INFO [org.jboss.as.naming] (Remoting "jeev6dev01_200" task-1) JBAS011806: Notification de fin de canal reçue, fermeture du canal Channel ID 0cb79bd5 (inbound) of Remoting connection 53a1933a to /10.23.132.245:57733
> This is due to org.jboss.as.naming.NamingLogger where the following is used:
> @LogMessage(level=Logger.Level.INFO)
> @Message(id=11806, value="Channel end notification received, closing channel %s")
> public abstract void closingChannelOnChannelEnd(Channel paramChannel);
> Changin this to
> @LogMessage(level=Logger.Level.DEBUG)
> Would ensure that an INFO log event is not seen every time a jms message is sent to the server.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-950) RESTEasy: Empty cfg. param javax.ws.rs.Application produces exception
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-950?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-950:
----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 899666|https://bugzilla.redhat.com/show_bug.cgi?id=899666] from MODIFIED to ON_QA
> RESTEasy: Empty cfg. param javax.ws.rs.Application produces exception
> ---------------------------------------------------------------------
>
> Key: WFLY-950
> URL: https://issues.jboss.org/browse/WFLY-950
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Reporter: Pavel Janousek
> Assignee: Weinan Li
>
> RESTEasy can be configured through several configuration options in WAR application deployment file WEB-INF/web.xml. The major one (also portable defined by JAX-RS standard) is _javax.ws.rs.Application_. When I set this parameter to empty content present behavior is raising exception "java.lang.StringIndexOutOfBoundsException: String index out of range: 0", it is not so good.
> I think, this is hard miss-configuration error and deployment description as this one should be rejected and a such application should not be deployed at all with appropriate error message, but not only by messed exception.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 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 commented on WFLY-3900:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1149644|https://bugzilla.redhat.com/show_bug.cgi?id=1149644] from MODIFIED to ON_QA
> 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, 8 months
[JBoss JIRA] (WFCORE-205) ManagedDMRContentTypeResource does not use a map with consistent ordering for storing content
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-205?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-205:
------------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1078062|https://bugzilla.redhat.com/show_bug.cgi?id=1078062] from MODIFIED to ON_QA
> ManagedDMRContentTypeResource does not use a map with consistent ordering for storing content
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-205
> URL: https://issues.jboss.org/browse/WFCORE-205
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha10
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Alpha11
>
>
> ManagedDMRContentTypeResource.content is used for generating an overall hash for the stored content, but it does not use consistent ordering (i.e. it needs to be a LinkedHashMap or perhaps a TreeMap.) The result is when another node in the domain receives an update it may calculate a different overall hash.
> This is surfacing as failures in https://bugzilla.redhat.com/show_bug.cgi?id=1078062 when the master and slave are running on different JVM releases. Different VM releases often have different ordering behavior when iterating over the unordered collections.
> I believe this is unlikely to result in real-world problems since any backup will persist its own version of the hash to its local copy of domain.xml, so there won't be any mismatch. The importance of the overall hash is that it allows the process to find the content in the repo when it is added.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFCORE-214) Missing jboss-threads in jboss-cli-client.jar
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-214?page=com.atlassian.jira.plugin... ]
Brian Stansberry closed WFCORE-214.
-----------------------------------
Resolution: Done
It's there. Never mind.
> Missing jboss-threads in jboss-cli-client.jar
> ---------------------------------------------
>
> Key: WFCORE-214
> URL: https://issues.jboss.org/browse/WFCORE-214
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> The client jar jboss-cli-client.jar is missing the org.jboss.threads classes, even though those are a dep of ModelControllerClient.
> Perhaps the CLI's call paths don't use those classes, but that's an accident waiting to happen, plus it prevents use of this jar as a general purpose management client, when otherwise it could be used that way.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months