February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1399) CLI: failure when adding a JNDI entry with default value containing a '$' at the end

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1399?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet updated WFCORE-1399: -------------------------------------- Affects Version/s: 2.1.0.CR1 > CLI: failure when adding a JNDI entry with default value containing a '$' at the end > ------------------------------------------------------------------------------------ > > Key: WFCORE-1399 > URL: https://issues.jboss.org/browse/WFCORE-1399 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.CR1 > Reporter: Valentin Maechler > Assignee: ehsavoie Hugonnet > Attachments: ExpressionResolver.java, ExpressionResolverUnitTestCase.java > > > Can not add a JNDI / naming entry which contains a "$" sign at the end of its default value. > e.g. {code} > value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}" > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5537) Singleton EJBs with multiple views does not honor Lock semantics

by Martin Kamp Jensen (JIRA)

[ https://issues.jboss.org/browse/WFLY-5537?page=com.atlassian.jira.plugin.... ] Martin Kamp Jensen commented on WFLY-5537: ------------------------------------------ I can reproduce this on WildFly 10.0.0.Final. > Singleton EJBs with multiple views does not honor Lock semantics > ---------------------------------------------------------------- > > Key: WFLY-5537 > URL: https://issues.jboss.org/browse/WFLY-5537 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.CR2 > Environment: 10.0.0.CR2 > Reporter: Nicky Mølholm > Labels: ejb, interceptor, singleton > > Upon method invocations to Singleton EJBs with multiple views... the *ContainerManagedConcurrencyInterceptor* randomly selects a wrong Lock (READ / WRITE). > Here is an example: > {code:java} > @Singleton > @Lock(LockType.READ) > @Local({ GreeterSayMyName.class, GreeterSayHello.class }) > public class GreeterBean implements GreeterSayMyName, GreeterSayHello { > @EJB > GreeterSayMyName myself; > @Override > public String sayHello() { > return "hello from " + myself.sayMyName(); > } > @Override > public String sayMyName() { > return "The Greeter"; > } > } > public interface GreeterSayHello { > > String sayHello(); > > } > public interface GreeterSayMyName { > String sayMyName(); > } > {code} > Sometimes (randomly) invoking the 'sayHello' method on this example EJB causes lock upgrade exceptions. They look like this: > {noformat} > 13:14:10,436 ERROR [f2PtkwmdRgaoHCdnZ7Vurg] [anonymous] [org.jboss.as.ejb3.invocation] (default task-5 f2PtkwmdRgaoHCdnZ7Vurg) WFLYEJB0034: EJB Invocation failed on component GreeterBean for method public abstract java.lang.String hello.world.GreeterSayHello.sayHello(): javax.ejb.IllegalLoopbackException: WFLYEJB0238: EJB 3.1 PFD2 4.8.5.1.1 upgrading from read to write lock is not allowed > at org.jboss.as.ejb3.concurrency.EJBReadWriteLock.checkLoopback(EJBReadWriteLock.java:232) > at org.jboss.as.ejb3.concurrency.EJBReadWriteLock.access$300(EJBReadWriteLock.java:40) > {noformat} > This happens completely randomly. > The problem is that the interceptor only knows about one of the views' methods. At deployment time the ViewService will start the views concurrently - and the interceptorfactory only adds an interceptor instance to the interceptor context if one does not already exist. > When the exception does NOT occur -then there is still a problem (although not visible from the code): A WRITE lock is selected - even though , given the above code, it should never ever be possible. So in fact - the issue , in that case, does not cause an exception because .... it already has the WRITE lock. > ( When the exception occurs ...then it is because the sayHello() invocation resulted in a READ lock ... and the reentrant invocation caused a WRITE lock to be selected by the interceptor ... but as this is not allowed, it results in a horrible exception ) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1065) ClasspathKieProject should not deal ".jar" always like a file

by Petr Široký (JIRA)

Petr Široký created DROOLS-1065: ----------------------------------- Summary: ClasspathKieProject should not deal ".jar" always like a file Key: DROOLS-1065 URL: https://issues.jboss.org/browse/DROOLS-1065 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.4.0.Beta1 Reporter: Petr Široký Assignee: Petr Široký Originally reported and fixed by David Santos (thanks!) via https://github.com/droolsjbpm/drools/pull/511 Description: Some containers allow deployments of artifacts in "expanded" mode (instead of a unique jar/ear/war/... file, al artifacts are deployed full decompressed, so they are directories). This is default with last JBoss Tools and Wildfly (unless you use compressed option for deployments). In that case drools fails to load jar contents. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2948) Welcome file does not work for *.jsf

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2948?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2948: ----------------------------------------------- Dominik Pospisil <dpospisi(a)redhat.com> changed the Status of [bug 1256325|https://bugzilla.redhat.com/show_bug.cgi?id=1256325] from ASSIGNED to MODIFIED > Welcome file does not work for *.jsf > -------------------------------------- > > Key: WFLY-2948 > URL: https://issues.jboss.org/browse/WFLY-2948 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Reporter: Gulam Samdani > Assignee: Remy Maucherat > Priority: Minor > Fix For: 8.1.0.CR1, 8.1.0.Final > > > Welcome file does not work for *.jsf > -------------------------------------------------------- > same problem not exists in Wildfly Beta but wildfly 8 final /cr1 gives this error ... > > problem : > > http://localhost:8080/hello ------------------------------ NO works*** > @http://localhost:8080/hello/index.jsf ------------- it works fine > ======================================= > <welcome-file-list> > > <welcome-file>index.jsf</welcome-file> > > </welcome-file-list> > <servlet> > <servlet-name>Faces Servlet</servlet-name> > <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> > <load-on-startup>1</load-on-startup> > </servlet> > <servlet-mapping> > <servlet-name>Faces Servlet</servlet-name> > <url-pattern>*.jsf</url-pattern> > </servlet-mapping> > </web-app> > ------------------------------------------------- > Reproduce this error : > https://community.jboss.org/message/857300 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6243) TCP Syslog handler cannot log some messages after reconnect

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6243?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-6243: ------------------------------- Attachment: logging-deployment.war > TCP Syslog handler cannot log some messages after reconnect > ----------------------------------------------------------- > > Key: WFLY-6243 > URL: https://issues.jboss.org/browse/WFLY-6243 > Project: WildFly > Issue Type: Bug > Components: Logging > Reporter: Ondrej Lukas > Assignee: James Perkins > Attachments: logging-deployment.war > > > In case when logging to syslog through TCP protocol is configured and syslog port becomes unreachable then after syslog restart some messages can be thrown away. > It seems syslog handler needs to another two logs for correct closing original TCP connection. In case when syslog is restarted and > * no message is logged during syslog is unreachable then the first two messages will not be logged to syslog after syslog is running again > * one message is attempted to be logged during syslog is unreachable then the first message will not be logged to syslog after syslog is running again > * two and more messages are attempted to be logged during syslog is unreachable then everything is logged correctly after syslog is running again -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6243) TCP Syslog handler cannot log some messages after reconnect

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-6243: ---------------------------------- Summary: TCP Syslog handler cannot log some messages after reconnect Key: WFLY-6243 URL: https://issues.jboss.org/browse/WFLY-6243 Project: WildFly Issue Type: Bug Components: Logging Reporter: Ondrej Lukas Assignee: James Perkins In case when logging to syslog through TCP protocol is configured and syslog port becomes unreachable then after syslog restart some messages can be thrown away. It seems syslog handler needs to another two logs for correct closing original TCP connection. In case when syslog is restarted and * no message is logged during syslog is unreachable then the first two messages will not be logged to syslog after syslog is running again * one message is attempted to be logged during syslog is unreachable then the first message will not be logged to syslog after syslog is running again * two and more messages are attempted to be logged during syslog is unreachable then everything is logged correctly after syslog is running again -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6242) UDP Syslog handler cannot log first message after reconnect

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6242?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-6242: ------------------------------- Attachment: logging-deployment.war > UDP Syslog handler cannot log first message after reconnect > ----------------------------------------------------------- > > Key: WFLY-6242 > URL: https://issues.jboss.org/browse/WFLY-6242 > Project: WildFly > Issue Type: Bug > Components: Logging > Reporter: Ondrej Lukas > Assignee: James Perkins > Attachments: logging-deployment.war > > > In case when logging to syslog through UDP protocol is configured and syslog port becomes unreachable then after syslog restart first message can be thrown away. It happens when odd number of messages is attempted to be logged during syslog is unreachable. It is caused when port unreachable is returned during logging attempt, then another log attempt automatically fail even if syslog server has been started meanwhile. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6242) UDP Syslog handler cannot log first message after reconnect

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-6242: ---------------------------------- Summary: UDP Syslog handler cannot log first message after reconnect Key: WFLY-6242 URL: https://issues.jboss.org/browse/WFLY-6242 Project: WildFly Issue Type: Bug Components: Logging Reporter: Ondrej Lukas Assignee: James Perkins In case when logging to syslog through UDP protocol is configured and syslog port becomes unreachable then after syslog restart first message can be thrown away. It happens when odd number of messages is attempted to be logged during syslog is unreachable. It is caused when port unreachable is returned during logging attempt, then another log attempt automatically fail even if syslog server has been started meanwhile. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6239) CLI: failure when adding a JNDI entry with default value containing a '$' at the end

by Valentin Maechler (JIRA)

[ https://issues.jboss.org/browse/WFLY-6239?page=com.atlassian.jira.plugin.... ] Valentin Maechler edited comment on WFLY-6239 at 2/18/16 4:31 AM: ------------------------------------------------------------------ Added test case "sysPropertyWithNormalDefaultValue" and "sysPropertyWithSpecialDefaultValue" to the test class{{ ExpressionResolverUnitTestCase}} and fixed the class {{ExpressionResolver}} (!) There's code duplication in the fixed class which needs to be cleaned up !!! was (Author: vmae): Added test case "sysPropertyWithNormalDefaultValue" and "sysPropertyWithSpecialDefaultValue" to the test class and fixed the class (!) There's code duplication in the fixed class which needs to be cleaned up !!! > CLI: failure when adding a JNDI entry with default value containing a '$' at the end > ------------------------------------------------------------------------------------ > > Key: WFLY-6239 > URL: https://issues.jboss.org/browse/WFLY-6239 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 10.0.0.Final > Reporter: Valentin Maechler > Assignee: Alexey Loubyansky > Attachments: ExpressionResolver.java, ExpressionResolverUnitTestCase.java > > > Can not add a JNDI / naming entry which contains a "$" sign at the end of its default value. > e.g. {code} > value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}" > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6239) CLI: failure when adding a JNDI entry with default value containing a '$' at the end

by Valentin Maechler (JIRA)

[ https://issues.jboss.org/browse/WFLY-6239?page=com.atlassian.jira.plugin.... ] Valentin Maechler edited comment on WFLY-6239 at 2/18/16 4:31 AM: ------------------------------------------------------------------ Added test case "sysPropertyWithNormalDefaultValue" and "sysPropertyWithSpecialDefaultValue" to the test class {{ExpressionResolverUnitTestCase}} and fixed the class {{ExpressionResolver}} (!) There's code duplication in the fixed class which needs to be cleaned up !!! was (Author: vmae): Added test case "sysPropertyWithNormalDefaultValue" and "sysPropertyWithSpecialDefaultValue" to the test class{{ ExpressionResolverUnitTestCase}} and fixed the class {{ExpressionResolver}} (!) There's code duplication in the fixed class which needs to be cleaned up !!! > CLI: failure when adding a JNDI entry with default value containing a '$' at the end > ------------------------------------------------------------------------------------ > > Key: WFLY-6239 > URL: https://issues.jboss.org/browse/WFLY-6239 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 10.0.0.Final > Reporter: Valentin Maechler > Assignee: Alexey Loubyansky > Attachments: ExpressionResolver.java, ExpressionResolverUnitTestCase.java > > > Can not add a JNDI / naming entry which contains a "$" sign at the end of its default value. > e.g. {code} > value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}" > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2016