September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3600) TransactionRolledbackException doesn't reference the originating runtime-exception

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3600?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3600: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1140705|https://bugzilla.redhat.com/show_bug.cgi?id=1140705] from NEW to POST > TransactionRolledbackException doesn't reference the originating runtime-exception > ---------------------------------------------------------------------------------- > > Key: WFLY-3600 > URL: https://issues.jboss.org/browse/WFLY-3600 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > > If a RuntimeException is thrown by a business method this gets lost during propagation to the client. > The client is not able in this case to react appropriate to the cause. > Similar issue was fixed for the Local invocation, see AS7-5432 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3149) Windows service on 64 bit systems cannot be stopped

by Julius Mensing (JIRA)

[ https://issues.jboss.org/browse/WFLY-3149?page=com.atlassian.jira.plugin.... ] Julius Mensing commented on WFLY-3149: -------------------------------------- @Claudio Illanes: I also have the %CREDENTIALS% removed from line 178. It looks like this for me: set STOPPARAM="/c \"set NOPAUSE=Y ^^^&^^^& jboss-cli.bat --controller=%CONTROLLER% --connect --command=:shutdown\"" > Windows service on 64 bit systems cannot be stopped > --------------------------------------------------- > > Key: WFLY-3149 > URL: https://issues.jboss.org/browse/WFLY-3149 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.0.0.Final > Environment: Windows 2008 Server, Windows 7 professional - both 64 bit systems using JDK 1.7.0_09 > Reporter: Mohan Potturi > Assignee: Mladen Turk > > The Windows service cannot be stopped. It says 'stopping' in the windows service user interface window. The only way to stop it is ti actually kill the java process. It works flawlessly on 32 bit systems though. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3149) Windows service on 64 bit systems cannot be stopped

by Julius Mensing (JIRA)

[ https://issues.jboss.org/browse/WFLY-3149?page=com.atlassian.jira.plugin.... ] Julius Mensing commented on WFLY-3149: -------------------------------------- Thank you Otmar and Abhinav, adding the JAVA_HOME to the jboss-cli.bat made it work finally: I added this line at the beginning of the script: set JAVA_HOME=c:\jdk1.8.0_05 > Windows service on 64 bit systems cannot be stopped > --------------------------------------------------- > > Key: WFLY-3149 > URL: https://issues.jboss.org/browse/WFLY-3149 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.0.0.Final > Environment: Windows 2008 Server, Windows 7 professional - both 64 bit systems using JDK 1.7.0_09 > Reporter: Mohan Potturi > Assignee: Mladen Turk > > The Windows service cannot be stopped. It says 'stopping' in the windows service user interface window. The only way to stop it is ti actually kill the java process. It works flawlessly on 32 bit systems though. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-998) run-as does not work for Servlet.init()

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-998?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar resolved WFLY-998. ------------------------------ Resolution: Done > run-as does not work for Servlet.init() > --------------------------------------- > > Key: WFLY-998 > URL: https://issues.jboss.org/browse/WFLY-998 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Derek Horton > Assignee: Stuart Douglas > Fix For: 9.0.0.Alpha1 > > > According to the servlet 2.4 spec, the run-as should be used for Servlet.init() > page 285: > " Clarification: run-as identity must apply to all calls from a servlet including init() and destroy() (12.7)" > This isn't working. > In JBoss 5.x, it looks like this functionality was implemented by a RunAsListener. However, that listener does not appear to exist in the EAP 6 code base. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-998) run-as does not work for Servlet.init()

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-998?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration updated WFLY-998: ----------------------------------------- Bugzilla Update: (was: Perform) Bugzilla References: (was: https://bugzilla.redhat.com/show_bug.cgi?id=952518) > run-as does not work for Servlet.init() > --------------------------------------- > > Key: WFLY-998 > URL: https://issues.jboss.org/browse/WFLY-998 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Derek Horton > Assignee: Stuart Douglas > Fix For: 9.0.0.Alpha1 > > > According to the servlet 2.4 spec, the run-as should be used for Servlet.init() > page 285: > " Clarification: run-as identity must apply to all calls from a servlet including init() and destroy() (12.7)" > This isn't working. > In JBoss 5.x, it looks like this functionality was implemented by a RunAsListener. However, that listener does not appear to exist in the EAP 6 code base. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3189) Error validating jboss-ejb3.xml.

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/WFLY-3189?page=com.atlassian.jira.plugin.... ] Rob Stryker commented on WFLY-3189: ----------------------------------- With the patch in the above pull request, I've found validation generally works. The following example jboss-ejb3.xml validates with 0 errors: {code} <?xml version="1.0" encoding="UTF-8"?> <jboss:ejb-jar version="3.1" impl-version="2.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:jboss="http://www.jboss.com/xml/ns/javaee" xmlns:s="urn:security:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <assembly-descriptor> <s:security> <ejb-name>*</ejb-name> <s:security-domain>testsd</s:security-domain> <s:run-as-principal>SomeUser</s:run-as-principal> <s:missing-method-permissions-deny-access>true</s:missing-method-permissions-deny-access> </s:security> </assembly-descriptor> </jboss:ejb-jar> {code} Missing any of the elements inside 'security' shows validation errors, as required elements are missing. I would like to note that the example file used in this JIRA still does *not* validate. I'll re-paste the non-validating example here: {code} <?xml version="1.0" encoding="UTF-8"?> <jboss:ejb-jar version="3.1" impl-version="2.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:jboss="http://www.jboss.com/xml/ns/javaee" xmlns:s="urn:security:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd"> <assembly-descriptor> <s:security> <ejb-name>*</ejb-name> <s:security-domain>testsd</s:security-domain> </s:security> </assembly-descriptor> </jboss:ejb-jar> {code} The reason this does NOT validate is this line here: {code} xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd"> {code} As far as I can tell, the reason this is failing to validate is because while we have updated the schema in the wildfly and metadata repos, we still have not yet updated the schema at the various web locations, and so specifying the remote addresses is still confusing the catalog. > Error validating jboss-ejb3.xml. > -------------------------------- > > Key: WFLY-3189 > URL: https://issues.jboss.org/browse/WFLY-3189 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.Final > Environment: WildFly 8.0.0.Final > Reporter: shinzey shinzey > Assignee: David Lloyd > Attachments: p.patch > > > I'm trying to configure code completion for jboss-ejb3.xml with schema, but fail to do that due to the following validation error: > {noformat} > src-resolve: Cannot resolve the name 'javaee:jboss-ejb-beanType' to a(n) 'type definition' component. [33] > src-resolve: Cannot resolve the name 'javaee:jboss-ejb-jarType' to a(n) 'type definition' component. [35] > src-resolve: Cannot resolve the name 'javaee:jboss-enterprise-beansType' to a(n) 'type definition' component. [37] > src-resolve: Cannot resolve the name 'javaee:assembly-descriptor-entry' to a(n) 'element declaration' component. [35] > src-resolve: Cannot resolve the name 'javaee:jboss-assembly-descriptor-bean-entryType' to a(n) 'type definition' component. [39] > {noformat} > The jboss-ejb3.xml is quite simple: > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <jboss:ejb-jar version="3.1" impl-version="2.0" > xmlns="http://java.sun.com/xml/ns/javaee" > xmlns:jboss="http://www.jboss.com/xml/ns/javaee" > xmlns:s="urn:security:1.1" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd > http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd"> > <assembly-descriptor> > <s:security> > <ejb-name>*</ejb-name> > <s:security-domain>testsd</s:security-domain> > </s:security> > </assembly-descriptor> > </jboss:ejb-jar> > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGMGR-111) ClassLoaderLogContextSelector should optionally include parent CL for context scanning

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-111?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on LOGMGR-111: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1031448|https://bugzilla.redhat.com/show_bug.cgi?id=1031448] from MODIFIED to ON_QA > ClassLoaderLogContextSelector should optionally include parent CL for context scanning > -------------------------------------------------------------------------------------- > > Key: LOGMGR-111 > URL: https://issues.jboss.org/browse/LOGMGR-111 > Project: JBoss Log Manager > Issue Type: Feature Request > Affects Versions: 1.5.2.Final > Reporter: Dominik Pospisil > Assignee: James Perkins > Fix For: 1.5.3.Final, 2.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-101) logging-profile works for a servlet, but doesn't for a JSP

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-101?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-101: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1031448|https://bugzilla.redhat.com/show_bug.cgi?id=1031448] from MODIFIED to ON_QA > logging-profile works for a servlet, but doesn't for a JSP > ---------------------------------------------------------- > > Key: WFCORE-101 > URL: https://issues.jboss.org/browse/WFCORE-101 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Osamu Nagano > Assignee: James Perkins > Fix For: 1.0.0.Alpha9 > > Attachments: logone.zip > > > Suppose the following logging-profile has been set in logging subsystem, and a web app has a proper entry in its MANIFEST.MF ({{Logging-Profile: logone}}). Then all messages via "com.example.logone" logger should go into a file, logone.log. It does so with a logger got in a servlet, but it doesn't work a logger got in a JSP. > {code} > <logging-profiles> > <logging-profile name="logone"> > <file-handler name="logone"> > <level name="INFO"/> > <file relative-to="jboss.server.log.dir" path="logone.log"/> > </file-handler> > <logger category="com.example.logone"> > <level name="INFO"/> > </logger> > <root-logger> > <level name="INFO"/> > <handlers> > <handler name="logone"/> > </handlers> > </root-logger> > </logging-profile> > </logging-profiles> > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3846) JMS resources allows duplicate JNDI entries

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3846?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3846: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1140537|https://bugzilla.redhat.com/show_bug.cgi?id=1140537] from MODIFIED to ON_QA > JMS resources allows duplicate JNDI entries > ------------------------------------------- > > Key: WFLY-3846 > URL: https://issues.jboss.org/browse/WFLY-3846 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > > The JMS resources that can be stored in JNDI (connection-factory, pooled-connection-factory, jms-queue, jms-topic) does not check whether their list of JNDI entries contains duplicates. > At runtime, duplicates are eliminated but this introduces a difference between the resource model with duplicate entries and its runtime state (without duplicates). > The attribute definitions for their JNDI entries should validate at the MODEL stage that their value does not contain duplicate elements. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGMGR-104) SyslogHandler doesn't handle multi-byte characters correctly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on LOGMGR-104: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1096053|https://bugzilla.redhat.com/show_bug.cgi?id=1096053] from MODIFIED to ON_QA > 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 > 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: James Perkins > Fix For: 1.5.3.Final, 2.0.0.Beta1 > > Attachments: corrupted.png, corrupted2.png, corrupted3.png > > > 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 was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2014