[JBoss JIRA] (JGRP-1758) UnknownFormatConversionException in UNICAST3 logging
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1758?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on JGRP-1758:
------------------------------------
You're right. Sorry about that.
> UnknownFormatConversionException in UNICAST3 logging
> ----------------------------------------------------
>
> Key: JGRP-1758
> URL: https://issues.jboss.org/browse/JGRP-1758
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.4.2, 3.5
>
>
> When UNICAST3 tries to log a "FailedToDeliverMsg", it translates to the following pattern from jg-messages.properties:
> "JGRP000039: %s: failed to deliver %s %s: %t"
> This causes the following exception (because %t is not a valid conversion token):
> {noformat}
> java.util.UnknownFormatConversionException: Conversion = 't'
> at java.util.Formatter$FormatSpecifier.<init>(Formatter.java:2690)
> at java.util.Formatter.parse(Formatter.java:2528)
> at java.util.Formatter.format(Formatter.java:2469)
> at java.util.Formatter.format(Formatter.java:2423)
> at java.lang.String.format(String.java:2797)
> at org.jboss.logmanager.ExtLogRecord.formatRecord(ExtLogRecord.java:434)
> at org.jboss.logmanager.ExtLogRecord.getFormattedMessage(ExtLogRecord.java:397)
> at org.jboss.logmanager.formatters.Formatters$10.renderRaw(Formatters.java:568)
> at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:225)
> at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86)
> at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35)
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:79)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:296)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:721)
> at org.jboss.logmanager.Logger.log(Logger.java:672)
> at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:50)
> at org.jboss.logging.Logger.errorf(Logger.java:1369)
> at org.jboss.as.clustering.jgroups.LogFactory$LogAdapter.error(LogFactory.java:104)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:697)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:381)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> at org.jgroups.protocols.FD.up(FD.java:255)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:209)
> at org.jgroups.protocols.Discovery.up(Discovery.java:379)
> at org.jgroups.protocols.MPING.up(MPING.java:181)
> at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2609)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1399)
> at org.jgroups.protocols.TP$MyHandler.run(TP.java:1585)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-2690) JSP/JSPX tags doesn't work with Wildfly CR1
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-2690?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger commented on WFLY-2690:
---------------------------------------
The proposed commit breaks the Identifier contract. We'll have to use a different solution.
> JSP/JSPX tags doesn't work with Wildfly CR1
> -------------------------------------------
>
> Key: WFLY-2690
> URL: https://issues.jboss.org/browse/WFLY-2690
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
> Reporter: Otávio Garcia
> Assignee: Jozef Hartinger
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
> <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
> some code
> <jsp:doBody />
> more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
> <jsp:output omit-xml-declaration="yes" />
> my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-2710) way (new command, extension of existing command) to display information about patch file
by Martin Simka (JIRA)
Martin Simka created WFLY-2710:
----------------------------------
Summary: way (new command, extension of existing command) to display information about patch file
Key: WFLY-2710
URL: https://issues.jboss.org/browse/WFLY-2710
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Patching
Affects Versions: 8.0.0.CR1
Reporter: Martin Simka
Assignee: Emanuel Muckenhuber
Fix For: 8.0.0.Final
It should be possible to view details (description, target version ... ) of a patch file. There is no other way to display this information except unziping patch file and opening patch.xml.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-2611) Support CDI injection in various JSF artifacts
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-2611?page=com.atlassian.jira.plugin.... ]
Tomas Remes commented on WFLY-2611:
-----------------------------------
In JSF spec there is also following sentence: "..the following JSF artifacts are also injectable." followed by the classes listed above. I am not sure, if I understand it correctly. Does it mean that when I create e.g my custom NavigationHandler (and specify it in faces-config), should it be available for injection? e.g like this:
{noformat}
@Inject
CustomNavigationHandler handler;
{noformat}
[~ssilvert] Can you please elaborate?
> Support CDI injection in various JSF artifacts
> ----------------------------------------------
>
> Key: WFLY-2611
> URL: https://issues.jboss.org/browse/WFLY-2611
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JSF
> Reporter: Tomas Remes
> Assignee: Stuart Douglas
>
> If I understand correctly to the subchapter "5.4.1
> JSF Managed Classes and Java EE Annotations" of JSF 2.2 specification, there should be opportunity to use a lot of (and not only) CDI annotations in various JSF artifacts (ActionListener, SystemEventListener, etc. - for full list, please see the spec).
> So far I tried locally this (will be filling the table during time):
> ||JSF artifact||CDI Injection||
> |javax.el.ELResolver|works|
> |javax.faces.application.ApplicationFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.application.NavigationHandler|works|
> |javax.faces.application.ResourceHandler|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.application.StateManager|works (however there is question about availability of injected instances in constructor of this custom delegating object|
> |javax.faces.component.visit.VisitContextFactory|works|
> |javax.faces.context.ExceptionHandlerFactory|works|
> |javax.faces.context.ExternalContextFactory|works|
> |javax.faces.context.FacesContextFactory|works|
> |javax.faces.context.FlashFactory|works|
> |javax.faces.context.PartialViewContextFactory|works|
> |javax.faces.event.ActionListener|works only when specified also in faces-config|
> |javax.faces.event.SystemEventListener|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.lifecycle.ClientWindowFactory|works|
> |javax.faces.lifecycle.LifecycleFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.lifecycle.PhaseListener|works|
> |javax.faces.render.RenderKitFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.view.ViewDeclarationLanguageFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.view.facelets.FaceletCacheFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.view.facelets.TagHandlerDelegateFactory|works|
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (JBWEB-287) Websocket application working with multiple clients (e.g. chat style applications) fails due NullPointerException
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/JBWEB-287?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka edited comment on JBWEB-287 at 1/6/14 7:23 AM:
----------------------------------------------------------------
The test websocket app
It is based on [http://www.byteslounge.com/tutorials/java-ee-html5-websockets-with-multip...] with added "descriptor" jar as lib for enabling websocket functionality [enable-websockets.jar|http://anonsvn.jboss.org/repos/jbossweb/branches/7....].
was (Author: rhatlapa):
The test websocket app
> Websocket application working with multiple clients (e.g. chat style applications) fails due NullPointerException
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JBWEB-287
> URL: https://issues.jboss.org/browse/JBWEB-287
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Reporter: Radim Hatlapatka
> Assignee: Remy Maucherat
> Priority: Critical
> Attachments: byteslounge.war
>
>
> When trying to run websocket application with jbossweb 7.4.0.Beta1 (with EAP 6.2.0), websocket connection is successfully established but upon a message sent NullPointerException is thrown:
> {noformat}
> 11:47:27,176 ERROR [org.apache.catalina.core.StandardWrapperValve] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB000374: IO listener processing for servlet default threw exception: java.lang.NullPointerException
> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:92) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsWriteListener.onWritePossible(WsHttpUpgradeHandler.java:232) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:603) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:228) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 11:47:27,177 ERROR [org.apache.tomcat.websocket.pojo.PojoEndpointBase] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB008809: No error handling configured for [com.byteslounge.websockets.WebSocketTest] and the following error occurred: java.io.EOFException
> at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:553) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:237) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 11:47:27,178 ERROR [org.apache.tomcat.websocket.pojo.PojoEndpointBase] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB008809: No error handling configured for [com.byteslounge.websockets.WebSocketTest] and the following error occurred: java.io.EOFException
> at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:553) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:237) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> The same application correctly works with Tomcat 7
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months