[JBoss JIRA] (WFLY-2977) Nullpointer when Checking role for anonymous caller
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-2977?page=com.atlassian.jira.plugin.... ]
Eduardo Martins reassigned WFLY-2977:
-------------------------------------
Assignee: Eduardo Martins (was: David Lloyd)
> Nullpointer when Checking role for anonymous caller
> ---------------------------------------------------
>
> Key: WFLY-2977
> URL: https://issues.jboss.org/browse/WFLY-2977
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Markus D
> Assignee: Eduardo Martins
>
> When calling a rest service without authentication i receive a nullpointer when doing:
> @Resource
> private SessionContext ctx;
> This is enough to produce a nullpointer as guest:
> ctx.isCallerInRole("ADMIN_ROLE")
> Should return false imho.
> greetings,
> m
> {noformat}
> 13:16:23,714 ERROR [org.jboss.as.ejb3.invocation] (default task-2) JBAS014134: EJB Invocation failed on component PlayerFacade for method public net.dice.dto.player.PlayerResponseDTO net.dice.facade.PlayerFacade.createIncognitoPlayer(net.dice.lang.Language): javax.ejb.EJBException: java.lang.NullPointerException
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> at net.dice.facade.PlayerFacade$$$view3.createIncognitoPlayer(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:401) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:99) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at net.dice.facade.PlayerFacade$Proxy$_$$_Weld$EnterpriseProxy$.createIncognitoPlayer(Unknown Source) [classes:]
> at net.dice.facade.TestResource.test(TestResource.java:17) [classes:]
> at net.dice.facade.TestResource$Proxy$_$$_WeldClientProxy.test(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.6.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.6.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.6.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.6.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.6.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.6.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.6.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.6.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.6.Final.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at net.dice.auth.BasicAuthFilter.doFilter(BasicAuthFilter.java:76) [classes:]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at net.dice.filter.DiceFilter.doFilter(DiceFilter.java:48) [classes:]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.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.0.Final.jar:1.0.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.security.service.SimpleSecurityManager.isCallerInRole(SimpleSecurityManager.java:209) [wildfly-security-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.ejb3.component.EJBComponent.isCallerInRole(EJBComponent.java:373) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.ejb3.context.EJBContextImpl.isCallerInRole(EJBContextImpl.java:114) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at net.dice.facade.PlayerFacade.createIncognitoPlayer(PlayerFacade.java:122) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> {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, 4 months
[JBoss JIRA] (LOGMGR-104) SyslogHandler doesn't handle multi-byte characters correctly
by Kyle Shanahan (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin... ]
Kyle Shanahan updated LOGMGR-104:
---------------------------------
Description:
SyslogHandler doesn't handle multi-byte characters correctly.
I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
Step to reproduce (It might need to define -Dfile.encoding=UTF-8 in _JAVA_OPTIONS):
1. define a facility local1 at localhost and make syslog accept UDP packets.
2. define a logger:
{noformat}
/subsystem=logging/logger=utf8mb4log:add(level=INFO)
{noformat}
3. define a SyslogHandler:
{noformat}
/subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
{noformat}
4. define a SyslogAppender:
{noformat}
/subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
{noformat}
5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
6. Access the servlet http://localhost:8080/utf8mb4log/
And you will get like this: (I can't put 4 byte UTF-8 characters here... because database error occured):
{noformat}
Mar 8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
{noformat}
I would send a pull request later.
was:
SyslogHandler doesn't handle multi-byte characters correctly.
I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
Step to reproduce (It might need to define -Dfile.encoding=UTF-8 in _JAVA_OPTS):
1. define a facility local1 at localhost and make syslog accept UDP packets.
2. define a logger:
{noformat}
/subsystem=logging/logger=utf8mb4log:add(level=INFO)
{noformat}
3. define a SyslogHandler:
{noformat}
/subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
{noformat}
4. define a SyslogAppender:
{noformat}
/subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
{noformat}
5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
6. Access the servlet http://localhost:8080/utf8mb4log/
And you will get like this: (I can't put 4 byte UTF-8 characters here... because database error occured):
{noformat}
Mar 8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
{noformat}
I would send a pull request later.
> SyslogHandler doesn't handle multi-byte characters correctly
> ------------------------------------------------------------
>
> Key: LOGMGR-104
> URL: https://issues.jboss.org/browse/LOGMGR-104
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 1.5.2.Final
> Environment: - WildFly 8.0.0.Final
> - Oracle JDK7u51
> - OS X 10.9.2
> Reporter: Kyle Shanahan
> Assignee: David Lloyd
>
> SyslogHandler doesn't handle multi-byte characters correctly.
> I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
> Step to reproduce (It might need to define -Dfile.encoding=UTF-8 in _JAVA_OPTIONS):
> 1. define a facility local1 at localhost and make syslog accept UDP packets.
> 2. define a logger:
> {noformat}
> /subsystem=logging/logger=utf8mb4log:add(level=INFO)
> {noformat}
> 3. define a SyslogHandler:
> {noformat}
> /subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
> {noformat}
> 4. define a SyslogAppender:
> {noformat}
> /subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
> {noformat}
> 5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
> 6. Access the servlet http://localhost:8080/utf8mb4log/
> And you will get like this: (I can't put 4 byte UTF-8 characters here... because database error occured):
> {noformat}
> Mar 8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
> {noformat}
> I would send a pull request later.
--
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] (LOGMGR-104) SyslogHandler doesn't handle multi-byte characters correctly
by Kyle Shanahan (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin... ]
Kyle Shanahan updated LOGMGR-104:
---------------------------------
Description:
SyslogHandler doesn't handle multi-byte characters correctly.
I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
Step to reproduce (It might need to define -Dfile.encoding=UTF-8 in _JAVA_OPTS):
1. define a facility local1 at localhost and make syslog accept UDP packets.
2. define a logger:
{noformat}
/subsystem=logging/logger=utf8mb4log:add(level=INFO)
{noformat}
3. define a SyslogHandler:
{noformat}
/subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
{noformat}
4. define a SyslogAppender:
{noformat}
/subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
{noformat}
5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
6. Access the servlet http://localhost:8080/utf8mb4log/
And you will get like this: (I can't put 4 byte UTF-8 characters here... because database error occured):
{noformat}
Mar 8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
{noformat}
I would send a pull request later.
was:
SyslogHandler doesn't handle multi-byte characters correctly.
I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
Step to reproduce:
1. define a facility local1 at localhost and make syslog accept UDP packets.
2. define a logger:
{noformat}
/subsystem=logging/logger=utf8mb4log:add(level=INFO)
{noformat}
3. define a SyslogHandler:
{noformat}
/subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
{noformat}
4. define a SyslogAppender:
{noformat}
/subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
{noformat}
5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
6. Access the servlet http://localhost:8080/utf8mb4log/
And you will get like this: (I can't put 4 byte UTF-8 characters here... because database error occured):
{noformat}
Mar 8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
{noformat}
I would send a pull request later.
Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/50
> SyslogHandler doesn't handle multi-byte characters correctly
> ------------------------------------------------------------
>
> Key: LOGMGR-104
> URL: https://issues.jboss.org/browse/LOGMGR-104
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 1.5.2.Final
> Environment: - WildFly 8.0.0.Final
> - Oracle JDK7u51
> - OS X 10.9.2
> Reporter: Kyle Shanahan
> Assignee: David Lloyd
>
> SyslogHandler doesn't handle multi-byte characters correctly.
> I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
> Step to reproduce (It might need to define -Dfile.encoding=UTF-8 in _JAVA_OPTS):
> 1. define a facility local1 at localhost and make syslog accept UDP packets.
> 2. define a logger:
> {noformat}
> /subsystem=logging/logger=utf8mb4log:add(level=INFO)
> {noformat}
> 3. define a SyslogHandler:
> {noformat}
> /subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
> {noformat}
> 4. define a SyslogAppender:
> {noformat}
> /subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
> {noformat}
> 5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
> 6. Access the servlet http://localhost:8080/utf8mb4log/
> And you will get like this: (I can't put 4 byte UTF-8 characters here... because database error occured):
> {noformat}
> Mar 8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
> {noformat}
> I would send a pull request later.
--
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-3051) http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
by Rituraj Sinha (JIRA)
[ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.... ]
Rituraj Sinha edited comment on WFLY-3051 at 3/8/14 6:17 AM:
-------------------------------------------------------------
Hi Darran,
we have a situation where we want to secure our JMX console as well...on the basis of roles ...there is a requirement where team wants to have access to JMX but it should only be Read Only...
As wildfly supports RBAC(i feel its only for management tasks) ...i have created a application user and password assigned a Monitoring group to it ...is it possible that it can take one of the roles predefined in RBAC and when it logs in with these credentials they can only monitor the stuff as it there on the web_management condole...?
can the user created in the application realm also get the privilege of predefined Roles (like Monitor) and access associated with it to connect to JMX..so that they can get the access but cant do anything there...?
Thanks
Rituraj
was (Author: rituraj):
Hi Darran,
we have a situation where we want to secure our JMX console as well...on the basis of roles ...there is a requirement where team wants to have access to JMX but it should only be Read Only...
As wildfly supports RBAC(i feel its only for management tasks) ...i have created a application user and password assigned a Monitoring group to it ...is it possible that it can take one of the roles predefined in RBAC and when it logs in with these credentials they can only monitor the stuff as it there on the web_management condole...?
can the user craeted in the application realm also get the privilege of predefined Roles (like Monitor) and access associated with it to connect to JMX..so that they can get the access but cant do anything there...?
Thanks
Rituraj
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3051
> URL: https://issues.jboss.org/browse/WFLY-3051
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMX, Remoting
> Affects Versions: 8.0.0.Final
> Reporter: Rituraj Sinha
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
> <expose-resolved-model/>
> <expose-expression-model/>
> <remoting-connector use-management-endpoint="false"/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
> <expose-resolved-model/>
> <expose-expression-model/>
> <remoting-connector use-management-endpoint="false"/>
> </subsystem>
> as per the jboss-as-jmx_1_3.xsd its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
> <xs:annotation>
> <xs:documentation>
> If true then this connector will use the management endpoint, otherwise it will use the
> remoting subsystem endpoint.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks
--
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-3051) http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
by Rituraj Sinha (JIRA)
[ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.... ]
Rituraj Sinha commented on WFLY-3051:
-------------------------------------
Hi Darran,
we have a situation where we want to secure our JMX console as well...on the basis of roles ...there is a requirement where team wants to have access to JMX but it should only be Read Only...
As wildfly supports RBAC(i feel its only for management tasks) ...i have created a application user and password assigned a Monitoring group to it ...is it possible that it can take one of the roles predefined in RBAC and when it logs in with these credentials they can only monitor the stuff as it there on the web_management condole...?
can the user craeted in the application realm also get the privilege of predefined Roles (like Monitor) and access associated with it to connect to JMX..so that they can get the access but cant do anything there...?
Thanks
Rituraj
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3051
> URL: https://issues.jboss.org/browse/WFLY-3051
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMX, Remoting
> Affects Versions: 8.0.0.Final
> Reporter: Rituraj Sinha
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
> <expose-resolved-model/>
> <expose-expression-model/>
> <remoting-connector use-management-endpoint="false"/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
> <expose-resolved-model/>
> <expose-expression-model/>
> <remoting-connector use-management-endpoint="false"/>
> </subsystem>
> as per the jboss-as-jmx_1_3.xsd its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
> <xs:annotation>
> <xs:documentation>
> If true then this connector will use the management endpoint, otherwise it will use the
> remoting subsystem endpoint.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks
--
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] (JBWEB-292) Http11Nio loaded, JBWEB002081: No cipher match
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/JBWEB-292?page=com.atlassian.jira.plugin.... ]
Jean-Frederic Clere closed JBWEB-292.
-------------------------------------
Resolution: Rejected
If you find in the doc that you can use the OpenSSL cipher-suite in JSSE, that could be a minor doc issue.
> Http11Nio loaded, JBWEB002081: No cipher match
> ----------------------------------------------
>
> Key: JBWEB-292
> URL: https://issues.jboss.org/browse/JBWEB-292
> Project: JBoss Web
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-7.4.0.GA
> Reporter: Michal Babacek
> Assignee: Remy Maucherat
> Priority: Critical
> Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys,
> I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config advertise-socket="modcluster" connector="https">
> <dynamic-load-provider>
> <load-metric type="busyness"/>
> </dynamic-load-provider>
> <ssl key-alias="javaclient"
> password="tomcat"
> certificate-key-file="/tmp/ews-eap6/client-cert-key.jks"
> cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL"
> ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
> />
> </mod-cluster-config>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
> <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
> <ssl name="https"
> key-alias="javaclient"
> password="tomcat"
> certificate-key-file="/tmp/ews-eap6/client-cert-key.jks"
> cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL"
> protocol="TLS" verify-client="false"
> certificate-file="/tmp/ews-eap6/client-cert-key.jks"
> ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
> </connector>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> {code}
> Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}}.
> This causes cipher suite errors.
> * EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
> * EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:
> {noformat}
> 06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
> at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.io.IOException: JBWEB002081: No cipher match
> at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> ... 9 more
> 06:18:26,663 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
> at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: LifecycleException: JBWEB000023: Protocol handler initialization failed
> at org.apache.catalina.connector.Connector.init(Connector.java:985)
> at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
> ... 5 more
> {noformat}
> Any ideas?
--
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] (LOGMGR-104) SyslogHandler doesn't handle multi-byte characters correctly
by Kyle Shanahan (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin... ]
Kyle Shanahan updated LOGMGR-104:
---------------------------------
Git Pull Request: (was: https://github.com/jboss-logging/jboss-logmanager/pull/49)
> SyslogHandler doesn't handle multi-byte characters correctly
> ------------------------------------------------------------
>
> Key: LOGMGR-104
> URL: https://issues.jboss.org/browse/LOGMGR-104
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 1.5.2.Final
> Environment: - WildFly 8.0.0.Final
> - Oracle JDK7u51
> - OS X 10.9.2
> Reporter: Kyle Shanahan
> Assignee: David Lloyd
>
> SyslogHandler doesn't handle multi-byte characters correctly.
> I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
> Step to reproduce:
> 1. define a facility local1 at localhost and make syslog accept UDP packets.
> 2. define a logger:
> {noformat}
> /subsystem=logging/logger=utf8mb4log:add(level=INFO)
> {noformat}
> 3. define a SyslogHandler:
> {noformat}
> /subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
> {noformat}
> 4. define a SyslogAppender:
> {noformat}
> /subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
> {noformat}
> 5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
> 6. Access the servlet http://localhost:8080/utf8mb4log/
> And you will get like this: (I can't put 4 byte UTF-8 characters here... because database error occured):
> {noformat}
> Mar 8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
> {noformat}
> I would send a pull request later.
--
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] (LOGMGR-104) SyslogHandler doesn't handle multi-byte characters correctly
by Kyle Shanahan (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin... ]
Kyle Shanahan updated LOGMGR-104:
---------------------------------
Issue Type: Bug (was: Feature Request)
Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/49
> SyslogHandler doesn't handle multi-byte characters correctly
> ------------------------------------------------------------
>
> Key: LOGMGR-104
> URL: https://issues.jboss.org/browse/LOGMGR-104
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 1.5.2.Final
> Environment: - WildFly 8.0.0.Final
> - Oracle JDK7u51
> - OS X 10.9.2
> Reporter: Kyle Shanahan
> Assignee: David Lloyd
>
> SyslogHandler doesn't handle multi-byte characters correctly.
> I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
> Step to reproduce:
> 1. define a facility local1 at localhost and make syslog accept UDP packets.
> 2. define a logger:
> {noformat}
> /subsystem=logging/logger=utf8mb4log:add(level=INFO)
> {noformat}
> 3. define a SyslogHandler:
> {noformat}
> /subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
> {noformat}
> 4. define a SyslogAppender:
> {noformat}
> /subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
> {noformat}
> 5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
> 6. Access the servlet http://localhost:8080/utf8mb4log/
> And you will get like this: (I can't put 4 byte UTF-8 characters here... because database error occured):
> {noformat}
> Mar 8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
> {noformat}
> I would send a pull request later.
--
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] (LOGMGR-104) SyslogHandler doesn't handle multi-byte characters correctly
by Kyle Shanahan (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin... ]
Kyle Shanahan updated LOGMGR-104:
---------------------------------
Description:
SyslogHandler doesn't handle multi-byte characters correctly.
I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
Step to reproduce:
1. define a facility local1 at localhost and make syslog accept UDP packets.
2. define a logger:
{noformat}
/subsystem=logging/logger=utf8mb4log:add(level=INFO)
{noformat}
3. define a SyslogHandler:
{noformat}
/subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
{noformat}
4. define a SyslogAppender:
{noformat}
/subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
{noformat}
5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
6. Access the servlet http://localhost:8080/utf8mb4log/
And you will get like this: (I can't put 4 byte UTF-8 characters here... because database error occured):
{noformat}
Mar 8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
{noformat}
I would send a pull request later.
was:
SyslogHandler doesn't handle multi-byte characters correctly.
I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
Step to reproduce:
1. define a facility local1 at localhost and make syslog accept UDP packets.
2. define a logger:
{noformat}
/subsystem=logging/logger=utf8mb4log:add(level=INFO)
{noformat}
3. define a SyslogHandler:
{noformat}
/subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
{noformat}
4. define a SyslogAppender:
{noformat}
/subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
{noformat}
5. get and run example project at https://github.com/lbtc-xxx/utf8mb4log
And you will get like this: (I can't put 4 byte UTF-8 characters here... because database error occured):
{noformat}
Mar 8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
{noformat}
I would send a pull request later.
> SyslogHandler doesn't handle multi-byte characters correctly
> ------------------------------------------------------------
>
> Key: LOGMGR-104
> URL: https://issues.jboss.org/browse/LOGMGR-104
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 1.5.2.Final
> Environment: - WildFly 8.0.0.Final
> - Oracle JDK7u51
> - OS X 10.9.2
> Reporter: Kyle Shanahan
> Assignee: David Lloyd
>
> SyslogHandler doesn't handle multi-byte characters correctly.
> I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
> Step to reproduce:
> 1. define a facility local1 at localhost and make syslog accept UDP packets.
> 2. define a logger:
> {noformat}
> /subsystem=logging/logger=utf8mb4log:add(level=INFO)
> {noformat}
> 3. define a SyslogHandler:
> {noformat}
> /subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
> {noformat}
> 4. define a SyslogAppender:
> {noformat}
> /subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
> {noformat}
> 5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
> 6. Access the servlet http://localhost:8080/utf8mb4log/
> And you will get like this: (I can't put 4 byte UTF-8 characters here... because database error occured):
> {noformat}
> Mar 8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
> {noformat}
> I would send a pull request later.
--
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] (LOGMGR-104) SyslogHandler doesn't handle multi-byte characters correctly
by Kyle Shanahan (JIRA)
Kyle Shanahan created LOGMGR-104:
------------------------------------
Summary: SyslogHandler doesn't handle multi-byte characters correctly
Key: LOGMGR-104
URL: https://issues.jboss.org/browse/LOGMGR-104
Project: JBoss Log Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: core
Affects Versions: 1.5.2.Final
Environment: - WildFly 8.0.0.Final
- Oracle JDK7u51
- OS X 10.9.2
Reporter: Kyle Shanahan
Assignee: David Lloyd
SyslogHandler doesn't handle multi-byte characters correctly.
I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
Step to reproduce:
1. define a facility local1 at localhost and make syslog accept UDP packets.
2. define a logger:
{noformat}
/subsystem=logging/logger=utf8mb4log:add(level=INFO)
{noformat}
3. define a SyslogHandler:
{noformat}
/subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
{noformat}
4. define a SyslogAppender:
{noformat}
/subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
{noformat}
5. get and run example project at https://github.com/lbtc-xxx/utf8mb4log
And you will get like this: (I can't put 4 byte UTF-8 characters here... because database error occured):
{noformat}
Mar 8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
{noformat}
I would send a pull request later.
--
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