February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2908) The formatter attribute is changed every time it's processed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2908?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2908: ----------------------------------------------- James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1066602|https://bugzilla.redhat.com/show_bug.cgi?id=1066602] from NEW to CLOSED > The formatter attribute is changed every time it's processed > ------------------------------------------------------------ > > Key: WFLY-2908 > URL: https://issues.jboss.org/browse/WFLY-2908 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > Fix For: 8.0.1.Final > > > The {{HandlerOperations.equalValue()}} method uses the incorrect property name when comparing values resulting in the method always returning {{false}}. > This does not harm anything, but just changes the format pattern each time a resource is processed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2983) Update to HAL 2.2.0.Beta1

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-2983?page=com.atlassian.jira.plugin.... ] Harald Pehl updated WFLY-2983: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/5806) > Update to HAL 2.2.0.Beta1 > ------------------------- > > Key: WFLY-2983 > URL: https://issues.jboss.org/browse/WFLY-2983 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Priority: Blocker > Fix For: 8.0.0.Final > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2983) Update to HAL 2.2.0.Beta1

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-2983?page=com.atlassian.jira.plugin.... ] Harald Pehl updated WFLY-2983: ------------------------------ Fix Version/s: 8.0.1.Final (was: 8.0.0.Final) > Update to HAL 2.2.0.Beta1 > ------------------------- > > Key: WFLY-2983 > URL: https://issues.jboss.org/browse/WFLY-2983 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Priority: Blocker > Fix For: 8.0.1.Final > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2983) Update to HAL 2.2.0.Beta1

by Harald Pehl (JIRA)

Harald Pehl created WFLY-2983: --------------------------------- Summary: Update to HAL 2.2.0.Beta1 Key: WFLY-2983 URL: https://issues.jboss.org/browse/WFLY-2983 Project: WildFly Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Priority: Blocker Fix For: 8.0.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer + PropertyResolver is broken for vault expressions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBMETA-371: ------------------------------------------------ Jimmy Wilson <jawilson(a)redhat.com> changed the Status of [bug 1058959|https://bugzilla.redhat.com/show_bug.cgi?id=1058959] from ASSIGNED to POST > DefaultPropertyReplacer + PropertyResolver is broken for vault expressions > -------------------------------------------------------------------------- > > Key: JBMETA-371 > URL: https://issues.jboss.org/browse/JBMETA-371 > Project: JBoss Metadata > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: common > Affects Versions: 7.0.4.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.0.Final > > > The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname". > This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default value". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-430) Fails to parse DSL variable definition with single dot regex

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-430?page=com.atlassian.jira.plugin... ] Edson Tirelli closed DROOLS-430. -------------------------------- > Fails to parse DSL variable definition with single dot regex > ------------------------------------------------------------ > > Key: DROOLS-430 > URL: https://issues.jboss.org/browse/DROOLS-430 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.1.Final > Reporter: Toshiya Kobayashi > Assignee: Edson Tirelli > Fix For: 6.1.0.Beta1 > > > Drools fails to parse DSL variable definition with single dot regex, where I want one any character. > {noformat} > [then]Log {message:.}=list.add(\"{message}\"); > {noformat} > Error message: > {noformat} > [1,19]: DSL parser error > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-430) Fails to parse DSL variable definition with single dot regex

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-430?page=com.atlassian.jira.plugin... ] Edson Tirelli resolved DROOLS-430. ---------------------------------- Assignee: Edson Tirelli (was: Mark Proctor) Fix Version/s: 6.1.0.Beta1 Resolution: Done Fixed. Thanks for the test case. > Fails to parse DSL variable definition with single dot regex > ------------------------------------------------------------ > > Key: DROOLS-430 > URL: https://issues.jboss.org/browse/DROOLS-430 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.1.Final > Reporter: Toshiya Kobayashi > Assignee: Edson Tirelli > Fix For: 6.1.0.Beta1 > > > Drools fails to parse DSL variable definition with single dot regex, where I want one any character. > {noformat} > [then]Log {message:.}=list.add(\"{message}\"); > {noformat} > Error message: > {noformat} > [1,19]: DSL parser error > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2976) The default of remote-outbound connections should be the same (http-remoting) as it is used in general for all other connections

by Wolf-Dieter Fink (JIRA)

[ https://issues.jboss.org/browse/WFLY-2976?page=com.atlassian.jira.plugin.... ] Wolf-Dieter Fink updated WFLY-2976: ----------------------------------- Forum Reference: https://community.jboss.org/thread/237304, https://community.jboss.org/thread/231412 > The default of remote-outbound connections should be the same (http-remoting) as it is used in general for all other connections > -------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-2976 > URL: https://issues.jboss.org/browse/WFLY-2976 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Remoting > Affects Versions: 8.0.0.Final > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Priority: Minor > Labels: remote-ejb-connection, remoting > > EJB-client and ScopedContext use the http-remoting protocoll by default. > It is confusing and not very handy to use a different default for the remote-outbound-connection configuration, here the native-remoting protocol is used. > The default for this configuration should be http-remoting as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-430) Fails to parse DSL variable definition with single dot regex

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-430?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-430: ------------------------------------------------ Edson Tirelli <etirelli(a)redhat.com> changed the Status of [bug 1065868|https://bugzilla.redhat.com/show_bug.cgi?id=1065868] from NEW to MODIFIED > Fails to parse DSL variable definition with single dot regex > ------------------------------------------------------------ > > Key: DROOLS-430 > URL: https://issues.jboss.org/browse/DROOLS-430 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.1.Final > Reporter: Toshiya Kobayashi > Assignee: Mark Proctor > > Drools fails to parse DSL variable definition with single dot regex, where I want one any character. > {noformat} > [then]Log {message:.}=list.add(\"{message}\"); > {noformat} > Error message: > {noformat} > [1,19]: DSL parser error > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2594) Undeploy of JSF application is throwing SEVERE messages, when there were deployed more JSF apps

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-2594?page=com.atlassian.jira.plugin.... ] Farah Juma commented on WFLY-2594: ---------------------------------- As a workaround for a GlassFish issue, the _com.sun.faces.config.FacesInitializer#onStartup_ method currently has the following code that adds the ConfigureListener to the ServletContext: {code} // The following line is temporary until we can solve an ordering // issue in V3. Right now the JSP container looks for a mapping // of the FacesServlet in the web.xml. If it's not present, then // it assumes that the application isn't a faces application. In this // case the JSP container will not register the ConfigureListener // definition from our TLD nor will it parse cause or JSP TLDs to // be parsed. servletContext.addListener(com.sun.faces.config.ConfigureListener.class); {code} When running with WildFly, this causes the ConfigureListener to erroneously get registered twice when deploying JSF applications that don't contain a mapping of the FacesServlet in their web.xml. The InjectionProvider is set properly in the InitFacesContext the first time ConfigureListener.contextInitialized() is called. However, when ConfigureListener.contextInitialized() is erroneously called a second time, the InjectionProvider won't get set again resulting in the SEVERE messages in the logs when undeploying. I've created a patch that fixes this issue by making the ConfigManager.hasBeenInitialized() checks happen earlier in ConfigureListener.contextInitialized() and ConfigureListener.contextDestroyed(). See https://java.net/jira/browse/JAVASERVERFACES-3189. > Undeploy of JSF application is throwing SEVERE messages, when there were deployed more JSF apps > ----------------------------------------------------------------------------------------------- > > Key: WFLY-2594 > URL: https://issues.jboss.org/browse/WFLY-2594 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JSF > Environment: WildFly Beta2-SNAPSHOT from 2013-12-02 > Reporter: Tomas Remes > Assignee: Farah Juma > > When you deploy more than one JSF application and then you undeploy one of them, you'll face following message in server log: > {noformat} > SEVERE [javax.faces] (MSC service thread 1-2) Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI? > SEVERE [javax.faces] (MSC service thread 1-2) Unable to call @PreDestroy annotated methods because no InjectionProvider can be found. Does this container implement the Mojarra Injection SPI? > {noformat} > I think javax.faces.FactoryFinder.FactoryManagerCache.getApplicationFactoryManager(ClassLoader) shouldn't try to create new instance of FactoryManager in this case. I am not really sure, what is special initialization case, but it seems to me that this should evaluate to true in this case (btw Does this javax.faces.FactoryFinder.FactoryManagerCache.detectSpecialInitializationCase(FacesContext) ever evaluate as true?). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

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 2014