January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3865) java:jboss/exported is not available in @PreDestroy methods during shutdown

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-3865?page=com.atlassian.jira.plugin.... ] Brad Maxwell edited comment on WFLY-3865 at 1/2/15 2:05 PM: ------------------------------------------------------------ @Resource / resource-ref is what a component would use to inject the JNDI resource. The component that binds the JNDI resource would not want @Resource ... as that jndi value would not exist and result in the deployment failing to deploy (chicken & the egg problem). The only workaround I've seen is to do a try / catch in the @PreDestory and log warning if it does not exist. The workaround would have PreDestroy remove the jndi value if the deployment is undeployed when the app server is still running, and when the app server is shutdown it would either unbind it or the app server would unbind it and a warning would be logged. It would be good to allow the component that binds it into jndi to attempt to unbind it at shutdown before the app server binds it down. was (Author: bmaxwell): @Resource / resource-ref is what a component would use to inject the JNDI resource. The component that binds the JNDI resource would not want @Resource ... as that jndi value would not exist and result in the deployment failing to deploy (chicken & the egg problem). The only workaround I've seen is to do a try / catch in the @PreDestory and log warning if it does not exist. The workaround would have PreDestroy remove the jndi value if the deployment is undeployed when the app server is still running, and when the app server is shutdown it would either unbind it or the app server would unbind it and a warning would be logged. > java:jboss/exported is not available in @PreDestroy methods during shutdown > --------------------------------------------------------------------------- > > Key: WFLY-3865 > URL: https://issues.jboss.org/browse/WFLY-3865 > Project: WildFly > Issue Type: Feature Request > Components: Naming > Affects Versions: 8.1.0.Final > Reporter: Kyle Lape > Assignee: Eduardo Martins > > With the following code in a class named e.g. {{JNDIBinderBean.java}} > {code:java} > private static final String name = "java:jboss/exported/JNDIBinderBean"; > private static final String value = "JNDIBinderBean instantiated at " + new Date(); > @PostConstruct > public void start() { > new InitialContext().rebind(name, value); > } > @PreDestroy > public void stop() { > new InitialContext().unbind(name); > } > {code} > When Wildfly shuts down, I get an error saying that the MSC service isn't available: > {noformat} > javax.naming.NamingException: JBAS011836: Could not resolve service > service jboss.naming.context.java.jboss.exported.JNDIBinderBean > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3865) java:jboss/exported is not available in @PreDestroy methods during shutdown

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-3865?page=com.atlassian.jira.plugin.... ] Brad Maxwell commented on WFLY-3865: ------------------------------------ @Resource / resource-ref is what a component would use to inject the JNDI resource. The component that binds the JNDI resource would not want @Resource ... as that jndi value would not exist and result in the deployment failing to deploy (chicken & the egg problem). The only workaround I've seen is to do a try / catch in the @PreDestory and log warning if it does not exist. The workaround would have PreDestroy remove the jndi value if the deployment is undeployed when the app server is still running, and when the app server is shutdown it would either unbind it or the app server would unbind it and a warning would be logged. > java:jboss/exported is not available in @PreDestroy methods during shutdown > --------------------------------------------------------------------------- > > Key: WFLY-3865 > URL: https://issues.jboss.org/browse/WFLY-3865 > Project: WildFly > Issue Type: Feature Request > Components: Naming > Affects Versions: 8.1.0.Final > Reporter: Kyle Lape > Assignee: Eduardo Martins > > With the following code in a class named e.g. {{JNDIBinderBean.java}} > {code:java} > private static final String name = "java:jboss/exported/JNDIBinderBean"; > private static final String value = "JNDIBinderBean instantiated at " + new Date(); > @PostConstruct > public void start() { > new InitialContext().rebind(name, value); > } > @PreDestroy > public void stop() { > new InitialContext().unbind(name); > } > {code} > When Wildfly shuts down, I get an error saying that the MSC service isn't available: > {noformat} > javax.naming.NamingException: JBAS011836: Could not resolve service > service jboss.naming.context.java.jboss.exported.JNDIBinderBean > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1160) Adding config files to AS7 is inconvenient.

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-1160?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-1160: ----------------------------------- One easy and clean way we could support managing dependencies for global libraries would be to simply support Dependency: and Class-Path: just like we do for other filesystem JARs. > Adding config files to AS7 is inconvenient. > ------------------------------------------- > > Key: WFLY-1160 > URL: https://issues.jboss.org/browse/WFLY-1160 > Project: WildFly > Issue Type: Feature Request > Components: Class Loading > Environment: All > Reporter: Paul Hinds > Assignee: David Lloyd > Priority: Minor > Labels: regression > > This page https://community.jboss.org/wiki/HowToPutAnExternalFileInTheClasspath details how to put a directory on the AS7 classpath which is inconvenient and could easily be done by default. > If AS7 out of the box came with /standalone/classes or /standalone/conf (conf would introduce a bit of backwards compatability) and perhaps /standalone/lib/*.jar added to the classpath it would be as good as previous JBoss versions. > This could be implemented as a module as in the above documents and automatically added to classpaths if the dirs exists in the same way other modules are automatically added to the CP if certain criteria are met. > Ideally is should be possible to make these symlinks on win7 and nix. Since it is natural to put config in /etc per Linux file system standards. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3723) setting the local to english in CLI commands on non-english systems does not produce english output

by Emmanuel Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFLY-3723?page=com.atlassian.jira.plugin.... ] Emmanuel Hugonnet commented on WFLY-3723: ----------------------------------------- The default locale is expected to be en_US, maybe we should have zanata produce the en properties file instead of 'just' a default one. > setting the local to english in CLI commands on non-english systems does not produce english output > --------------------------------------------------------------------------------------------------- > > Key: WFLY-3723 > URL: https://issues.jboss.org/browse/WFLY-3723 > Project: WildFly > Issue Type: Bug > Components: Localization > Affects Versions: 8.1.0.Final > Environment: Tested on MacOS running in German > Reporter: Tom Fonteyne > Assignee: Romain Pelisse > Priority: Minor > > A German (or french etc...) system must be used to reproduce. > It is likely this is not limited to MacOS, but I do not have a non-english Linux system available > An out of the box install of wildfly/EAP: > Without configuration, the log file is in German as expected. > Using these CLI comands: > :read-operation-description(name=stop-servers,locale=de_DE) -> german > :read-operation-description(name=stop-servers,locale=en_US) -> german > :read-operation-description(name=stop-servers,locale=fr_FR) -> french > So we cannot get the CLI to produce english output > when configuring JAVA_OPTS in domain.conf with: > JAVA_OPTS="$JAVA_OPTS -Duser.language=en -Duser.country=DE -Duser.encoding=utf-8 > The log is now in English -> works as expected; and: > :read-operation-description(name=stop-servers,locale=de_DE) -> german > :read-operation-description(name=stop-servers,locale=en_US) -> english > So it seems we have a bug where the locale set to start the domain takes precedence over the locale set in the CLI command (but only when English is asked) > I presume this is because English is the default locale. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4216) when ever i deploy my ear file, i get this error

by oma sung (JIRA)

oma sung created WFLY-4216: ------------------------------ Summary: when ever i deploy my ear file, i get this error Key: WFLY-4216 URL: https://issues.jboss.org/browse/WFLY-4216 Project: WildFly Issue Type: Feature Request Reporter: oma sung Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4215) Use archive.apache.org to download maven 3.2.3

by Kabir Khan (JIRA)

Kabir Khan created WFLY-4215: -------------------------------- Summary: Use archive.apache.org to download maven 3.2.3 Key: WFLY-4215 URL: https://issues.jboss.org/browse/WFLY-4215 Project: WildFly Issue Type: Feature Request Components: Build System Reporter: Kabir Khan Assignee: Kabir Khan Fix For: 9.0.0.Beta1 The existing http://www.apache.org/dist/maven/maven-3/ location seems to only contain the latest release 3.2.5 rather than 3.2.3 which we want so build.sh fails. http://archive.apache.org/dist/maven/maven-3/ contains the existing builds in the 3.x series, so I am changing the build to use that. However, long term we would probably need the maven version downloadable from some internal location, or include the maven jars as part of the build the way they used to be. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4214) Update Maven to latest version 2.3.5

by Tom Jenkinson (JIRA)

Tom Jenkinson created WFLY-4214: ----------------------------------- Summary: Update Maven to latest version 2.3.5 Key: WFLY-4214 URL: https://issues.jboss.org/browse/WFLY-4214 Project: WildFly Issue Type: Component Upgrade Components: Build System Reporter: Tom Jenkinson Assignee: Tom Jenkinson {code} [tom@TOM-PC jboss-as](WFLY-4175)(11:08:43) $ ./tools/download-maven.sh % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 258 100 258 0 0 973 0 --:--:-- --:--:-- --:--:-- 973 Archive: maven.zip End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in maven.zip, and cannot find maven.zip.zip, period. mv: cannot stat `apache-maven*': No such file or directory {code} http://www.apache.org/dist/maven/maven-3/3.2.3/binaries/apache-maven-3.2.... is gone, it is now 3.2.5. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-674) Rules with bigdecimal comparison not matched for certain values

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-674?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-674. -------------------------------- Resolution: Rejected If you write 69.99 you're in reality saying that the value is a double with all the rounding issues it implies. Saying explicitly that it is a BigDecimal (writing it as 69.99B) fixes the problem. > Rules with bigdecimal comparison not matched for certain values > --------------------------------------------------------------- > > Key: DROOLS-674 > URL: https://issues.jboss.org/browse/DROOLS-674 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final, 6.2.0.CR3 > Reporter: Joseph Alex > Assignee: Mario Fusco > Priority: Minor > Attachments: BigDecimalTestFragment.java > > > For rules which compare BigDecimal inputs against a range considering 2 decimal place precision, match does not happen when the input equals certain upper bounds. Testcase attached. > The rules match when the upper bound is specified with a < condition instead of <= (i.e <70.00 instead of <=69.99) , which seem to indicate value seen by Drools is somewhere between the two. > Envrionment: > Drools : 5.5.0.Final > Java version : Java(TM) SE Runtime Environment (build 1.6.0_21-b06) > OS : CentOS release 6.1 (Final) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-674) Rules with bigdecimal comparison not matched for certain values

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-674?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-674: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Rules with bigdecimal comparison not matched for certain values > --------------------------------------------------------------- > > Key: DROOLS-674 > URL: https://issues.jboss.org/browse/DROOLS-674 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final, 6.2.0.CR3 > Reporter: Joseph Alex > Assignee: Mario Fusco > Priority: Minor > Attachments: BigDecimalTestFragment.java > > > For rules which compare BigDecimal inputs against a range considering 2 decimal place precision, match does not happen when the input equals certain upper bounds. Testcase attached. > The rules match when the upper bound is specified with a < condition instead of <= (i.e <70.00 instead of <=69.99) , which seem to indicate value seen by Drools is somewhere between the two. > Envrionment: > Drools : 5.5.0.Final > Java version : Java(TM) SE Runtime Environment (build 1.6.0_21-b06) > OS : CentOS release 6.1 (Final) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4164) New JTS record types are not showing up in the CLI

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4164?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4164: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1168973|https://bugzilla.redhat.com/show_bug.cgi?id=1168973] from POST to MODIFIED > New JTS record types are not showing up in the CLI > -------------------------------------------------- > > Key: WFLY-4164 > URL: https://issues.jboss.org/browse/WFLY-4164 > Project: WildFly > Issue Type: Enhancement > Components: CLI, Transactions > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > > We need to expose the new JTS record types in the tooling: > {code} > AssumedCompleteHeuristicTransaction > AssumedCompleteHeuristicServerTransaction > AssumedCompleteTransaction > AssumedCompleteServerTransaction > {code} > We need these because if a transaction ends up in a heuristic state we can't actually view this using the CLI even though the records are in the object store. This has the consequence that a transaction can remain in the object store indefinitely. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 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 January 2015