[JBoss JIRA] (WFLY-2705) Unicode and Umlaut problems in Wildfly
by Andre Pankraz (JIRA)
[ https://issues.jboss.org/browse/WFLY-2705?page=com.atlassian.jira.plugin.... ]
Andre Pankraz updated WFLY-2705:
--------------------------------
Description:
I think I'm doing something wrong if this is really a CR1, but I cannot get UTF working properly on Wildfly. (It works fine in same environment and same settings/code in jboss-as-7.2.0.Final.)
* If i have an JSF inputText in a form (hence POST)
* and I enter "TestÜÖÄ"
* I get "TestÃ?Ã?Ã" as result.
If I provide a <f:ajax render...> on this field, the ajax rendering creates the proper response, but if I submit the data I always get the wrong encoded result.
I created a minimalistic web app without any additional libs with just one JSF test page (see below). It works in jboss as 7.2 final but not in Wildfly CR1.
I have set in the environment:
-Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8
An encoding filter didn't help either.
May be I'm doing something wrong here, but I have seen quite some other bugs that don't really speak for a "Release-Candidate" so it might really be an issue? Have you really tried to deploy at least 2 or 3 bigger JSF apps onto this new version? Will add some more reports.
Example page for quick test:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<f:view encoding="UTF-8" xmlns:f="http://java.sun.com/jsf/core">
<html lang="de" xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets">
<h:head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Test</title>
</h:head>
<h:body>
<h1>Test ÜÄÖ</h1>
<h:form id="test">
<h:inputText label="Test: " value="#{test.test}">
<f:ajax render=":test" />
</h:inputText>
AJAX: #{test.test}
<br />
<h:commandButton action="#{test.print()}" value="Print" />
</h:form>
</h:body>
</html>
</f:view>
package test;
import javax.enterprise.context.RequestScoped;
import javax.inject.Named;
@Named
@RequestScoped
public class Test {
private String test;
public String getTest() {
return test;
}
public void setTest(String test) {
this.test = test;
}
public String print() {
System.out.println("TEST: " + getTest());
return "success";
}
}
Environment:
CentOS
java version "1.7.0_45"
OpenJDK Runtime Environment (rhel-2.4.3.2.el6_4-x86_64 u45-b15)
> Unicode and Umlaut problems in Wildfly
> --------------------------------------
>
> Key: WFLY-2705
> URL: https://issues.jboss.org/browse/WFLY-2705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: CentOS
> java version "1.7.0_45"
> OpenJDK Runtime Environment (rhel-2.4.3.2.el6_4-x86_64 u45-b15)
> Reporter: Andre Pankraz
> Assignee: Stuart Douglas
>
> I think I'm doing something wrong if this is really a CR1, but I cannot get UTF working properly on Wildfly. (It works fine in same environment and same settings/code in jboss-as-7.2.0.Final.)
> * If i have an JSF inputText in a form (hence POST)
> * and I enter "TestÜÖÄ"
> * I get "TestÃ?Ã?Ã" as result.
> If I provide a <f:ajax render...> on this field, the ajax rendering creates the proper response, but if I submit the data I always get the wrong encoded result.
> I created a minimalistic web app without any additional libs with just one JSF test page (see below). It works in jboss as 7.2 final but not in Wildfly CR1.
> I have set in the environment:
> -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8
> An encoding filter didn't help either.
> May be I'm doing something wrong here, but I have seen quite some other bugs that don't really speak for a "Release-Candidate" so it might really be an issue? Have you really tried to deploy at least 2 or 3 bigger JSF apps onto this new version? Will add some more reports.
> Example page for quick test:
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <f:view encoding="UTF-8" xmlns:f="http://java.sun.com/jsf/core">
> <html lang="de" xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:ui="http://java.sun.com/jsf/facelets">
> <h:head>
> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
> <title>Test</title>
> </h:head>
> <h:body>
> <h1>Test ÜÄÖ</h1>
> <h:form id="test">
> <h:inputText label="Test: " value="#{test.test}">
> <f:ajax render=":test" />
> </h:inputText>
> AJAX: #{test.test}
> <br />
> <h:commandButton action="#{test.print()}" value="Print" />
> </h:form>
> </h:body>
> </html>
> </f:view>
> package test;
> import javax.enterprise.context.RequestScoped;
> import javax.inject.Named;
> @Named
> @RequestScoped
> public class Test {
> private String test;
> public String getTest() {
> return test;
> }
> public void setTest(String test) {
> this.test = test;
> }
> public String print() {
> System.out.println("TEST: " + getTest());
> return "success";
> }
> }
--
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, 4 months
[JBoss JIRA] (AS7-4990) Cannot embed Jersey 1.13-b01 with error: UnsupportedOperationException: JBAS011859: Naming context is read-only
by SBS JIRA Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-4990?page=com.atlassian.jira.plugin.s... ]
SBS JIRA Integration updated AS7-4990:
--------------------------------------
Forum Reference: https://community.jboss.org/message/851434#851434
> Cannot embed Jersey 1.13-b01 with error: UnsupportedOperationException: JBAS011859: Naming context is read-only
> ---------------------------------------------------------------------------------------------------------------
>
> Key: AS7-4990
> URL: https://issues.jboss.org/browse/AS7-4990
> Project: Application Server 7
> Issue Type: Bug
> Components: Naming
> Affects Versions: 7.1.1.Final
> Environment: JBoss AS 7.1.1.Final (removing the jaxrs subsystem)
> java version "1.6.0_31"
> Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
> Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
> Linux annafi.dev 3.0.0-21-generic #35-Ubuntu SMP Fri May 25 17:57:41 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Hendy Irawan
> Assignee: Stuart Douglas
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
> Attachments: jerseyissue.zip
>
>
> {code}
> 03:47:22,356 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"thread-inmem-jerseywar.war\".WeldService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"thread-inmem-jerseywar.war\".WeldService: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
> Exception 0 :
> java.lang.UnsupportedOperationException: JBAS011859: Naming context is read-only
> at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:126)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.createSubcontext(WritableServiceBasedNamingStore.java:116)
> at org.jboss.as.naming.NamingContext.createSubcontext(NamingContext.java:338)
> at org.jboss.as.naming.InitialContext.createSubcontext(InitialContext.java:229)
> at org.jboss.as.naming.NamingContext.createSubcontext(NamingContext.java:346)
> at javax.naming.InitialContext.createSubcontext(InitialContext.java:483)
> at com.sun.jersey.server.impl.cdi.CDIExtension$1.stepInto(CDIExtension.java:280)
> at com.sun.jersey.server.impl.cdi.CDIExtension.diveIntoJNDIContext(CDIExtension.java:267)
> at com.sun.jersey.server.impl.cdi.CDIExtension.createJerseyConfigJNDIContext(CDIExtension.java:273)
> at com.sun.jersey.server.impl.cdi.CDIExtension.initialize(CDIExtension.java:192)
> at com.sun.jersey.server.impl.cdi.CDIExtension.beforeBeanDiscovery(CDIExtension.java:297)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:264)
> at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
> at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
> at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:260)
> at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170)
> at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51)
> at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:241)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:229)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:207)
> at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:75)
> at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:46)
> at org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:46)
> at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:322)
> at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81)
> at org.jboss.as.weld.services.WeldService.start(WeldService.java:76)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> "}}}}
> {code}
> Sample project to reproduce:
> https://github.com/ceefour/odata-sandbox/tarball/jboss-jndi-readonly-jersey
> in folder: thread-inmem-jerseywar
> The JBoss AS 7.1.1 configuration is in: thread-inmem-jerseywar/jboss/standalone-no-jaxrs.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, 4 months
[JBoss JIRA] (JBAS-9554) for the jboss4.0.5 ,how to download the jar-version.xml??
by daisishu daisishu (JIRA)
daisishu daisishu created JBAS-9554:
---------------------------------------
Summary: for the jboss4.0.5 ,how to download the jar-version.xml??
Key: JBAS-9554
URL: https://issues.jboss.org/browse/JBAS-9554
Project: Application Server 3 4 5 and 6
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Spring integration
Affects Versions: JBossAS-4.0.5.GA
Environment: linux
Reporter: daisishu daisishu
Assignee: Ales Justin
Fix For: JBossAS-4.0.5.GA
for the jboss4.0.5 ,how to download the jar-version.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, 4 months
[JBoss JIRA] (WFLY-260) Error
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-260?page=com.atlassian.jira.plugin.s... ]
David Lloyd resolved WFLY-260.
------------------------------
Fix Version/s: (was: 8.0.0.CR1)
(was: 8.0.0.Final)
Resolution: Incomplete Description
Closing due to lack of updates
> Error
> -----
>
> Key: WFLY-260
> URL: https://issues.jboss.org/browse/WFLY-260
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Class Loading
> Reporter: Pablo Ochoa
> Assignee: David Lloyd
>
> Buenos Días,
> Tengo problema con la version 7.1.1 de Jboss por defecto viene creado un Selector y yo intento crea uno nuevo para el manejo de mi classes me arroja el siguiente error
> Preferred repository selector not installed because one has already exists. No problem, using existing selector...
> Estado investigando de verdad no conseguido algo para poder solventar este problema el la ultima version de Jboss 6 no ocurre este mismo problema agradezco toda la colaboración que me puedan brindar
> Te anexo el codigo que utilizo
> import java.util.*;
> import javax.naming.*;
> import org.apache.log4j.Hierarchy;
> import org.apache.log4j.Level;
> import org.apache.log4j.spi.*;
> public class Log4jContextJNDISelector
> implements RepositorySelector
> {
> public Log4jContextJNDISelector(){
> defaultHierarchy = new Hierarchy(new RootLogger(Level.DEBUG));
> }
> public LoggerRepository getLoggerRepository()
> {
> String loggingContextName = null;
> try
> {
> Context ctx = new InitialContext();
> loggingContextName = (String)ctx.lookup("java:comp/env/log4j/logging-context");
> }
> catch(NamingException ne) { }
> if(loggingContextName == null)
> return defaultHierarchy;
> Hierarchy hierarchy = (Hierarchy)hierMap.get(loggingContextName);
> if(hierarchy == null)
> {
> hierarchy = new Hierarchy(new RootLogger(Level.DEBUG));
> hierMap.put(loggingContextName, hierarchy);
> }
> return hierarchy;
> }
> Archivo web.xml esta configuración
> <context-param>
> <param-name>log4j-selector</param-name>
> <param-value>ve.com.prueba.gdis.cia.config.logging.Log4jContextJNDISelector</param-value>
> <description> Selector de repositorios basado en JNDI desde donde se
> configurar el repositorio de logs para esta aplicación
> </description>
> </context-param>
--
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, 4 months