May 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4509) Update to console 2.6.8.Final

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFLY-4509?page=com.atlassian.jira.plugin.... ] Heiko Braun updated WFLY-4509: ------------------------------ Summary: Update to console 2.6.8.Final (was: Update to console 2.6.7.Final) > Update to console 2.6.8.Final > ----------------------------- > > Key: WFLY-4509 > URL: https://issues.jboss.org/browse/WFLY-4509 > Project: WildFly > Issue Type: Feature Request > Components: Web Console > Reporter: Heiko Braun > Assignee: Heiko Braun > Priority: Blocker > Fix For: 9.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4572) wildfly-arquillian uses slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/WFLY-4572?page=com.atlassian.jira.plugin.... ] Jozef Hartinger commented on WFLY-4572: --------------------------------------- There is this simple premise: If a maven artifact M is available in repository R then all its dependencies should be available in the same repository. Otherwise, someone using repository R will see the artifact M in the repository but will be unable to use it is its dependencies are absent. My understanding is that WF currently violates the aforementioned premise as not all of its dependencies are available in central. > wildfly-arquillian uses slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-4572 > URL: https://issues.jboss.org/browse/WFLY-4572 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 8.2.0.Final, 9.0.0.Beta2 > Reporter: Martin Kouba > Assignee: Paul Gier > > GAV: {{org.slf4j:slf4j-api:1.7.7.jbossorg-1}} > As a result, it's not possible to build a project which depends on some referencing module, e.g. {{wildfly-arquillian-common}}, and does not define JBoss repository at the same time. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4415) RemotingContext should be copied for async EJB calls

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4415?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4415: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1201439|https://bugzilla.redhat.com/show_bug.cgi?id=1201439] from POST to MODIFIED > RemotingContext should be copied for async EJB calls > ---------------------------------------------------- > > Key: WFLY-4415 > URL: https://issues.jboss.org/browse/WFLY-4415 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-505) Fix double redeployment due to .failed file and a artifact with newer timestamp.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-505?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-505: ------------------------------------------------ baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1169239|https://bugzilla.redhat.com/show_bug.cgi?id=1169239] from POST to MODIFIED > Fix double redeployment due to .failed file and a artifact with newer timestamp. > -------------------------------------------------------------------------------- > > Key: WFCORE-505 > URL: https://issues.jboss.org/browse/WFCORE-505 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha15 > Reporter: Chao Wang > Assignee: Chao Wang > Fix For: 1.0.0.Beta5 > > > Issue found and described in https://bugzilla.redhat.com/show_bug.cgi?id=1169239 > steps to reproduce: > 1. deploy a "Test.war" > 2. Change something in "Test.war" to fail it. > 3. "Test.war.failed" file will be created. > 4. stop JBoss EAP. > 5. Revert the changes done in "Test.war" so that it will deploy successfully. > 6. Now there are two files ("Test.war.failed" and "Test.war", due to correction, Test.war must have a newer timestamp than Test.war.failed)in deployment directory. > 7. Restart JBoss EAP, it will fail with below Error : > The problem happens as a result of redundant redeployment in next reboot. During servert reboot, it will try to redeploy the application due to found .failed file, it also will try to redeploy same application because Test.war has a newer timestamp to see the problem. This will cause server startup failure as: > {noformat} > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 18) JBAS014613: Operation ("add") failed - address: ([("deployment" => "Test.war")]) - failure description: "JBAS014803: Duplicate resource [(\"deployment\" => \"Test.war\")] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4303) Allow expressions in jboss-ejb-client.xml if configuration jboss-descriptor-property-replacement=true

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4303?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4303: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1194381|https://bugzilla.redhat.com/show_bug.cgi?id=1194381] from POST to MODIFIED > Allow expressions in jboss-ejb-client.xml if configuration jboss-descriptor-property-replacement=true > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-4303 > URL: https://issues.jboss.org/browse/WFLY-4303 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Wolf-Dieter Fink > Assignee: Tomasz Adamski > Fix For: 9.0.0.Beta1 > > > Applications need to have a jboss-ejb-client.xml configuration to use connections to other WildFly servers. > The remote-outbound-connection allow expressions, i.e. for user-name. > But if a cluster come into play the related <cluster> element inside the jboss-ejb-client.xml must have the same username and this can be only hardcoded. > So the jboss-ejb-client.xml parsing should allow expressions for > outbound-connection-ref, username, security-realm etc. > See https://github.com/wildfly/quickstart/blob/master/ejb-multi-server/app-ma... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-234) Inconsistent synchronization in ConfigurationFile

by Eduardo Silva (JIRA)

[ https://issues.jboss.org/browse/WFCORE-234?page=com.atlassian.jira.plugin... ] Eduardo Silva commented on WFCORE-234: -------------------------------------- This should not be closed as his duplicate is? (WFCORE-235) > Inconsistent synchronization in ConfigurationFile > ------------------------------------------------- > > Key: WFCORE-234 > URL: https://issues.jboss.org/browse/WFCORE-234 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Brian Stansberry > Fix For: 2.0.0.CR1 > > > ConfigurationFile synchronizes on itself in some places and not in others. This may cause problems, particularly with the history dir. > The one that comes to mind is successfulBoot is synchronized, but all the methods called by ConfigurationFilePersistenceResource are not. The latter is called with the controller lock held, but the former is not. So there's a possibility of two threads interacting with the files concurrently if an operation executes immediately after boot. > The deployment scanner schedules such an op, so it's possible. Currently the schedule is for 200 ms after deployment-scanner add runs during boot. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-870) Spring dev & migration guide JBoss AS 7.0 wrong matching tag for persistence-context-ref-name

by Eduardo Silva (JIRA)

[ https://issues.jboss.org/browse/WFLY-870?page=com.atlassian.jira.plugin.s... ] Eduardo Silva commented on WFLY-870: ------------------------------------ I've mande the change on the page: https://docs.jboss.org/author/display/AS7/Spring+applications+development... > Spring dev & migration guide JBoss AS 7.0 wrong matching tag for persistence-context-ref-name > --------------------------------------------------------------------------------------------- > > Key: WFLY-870 > URL: https://issues.jboss.org/browse/WFLY-870 > Project: WildFly > Issue Type: Bug > Components: Documentation > Reporter: Beth Boose > > The Spring applications development and migration guide at https://docs.jboss.org/author/display/AS7/Spring+applications+development... under Using server-deployed persistence units > Has the web.xml entry below: > <persistence-context-ref> > <persistence-context-ref-name>persistence/petclinic-em</persistence-unit-ref-name> > <persistence-unit-name>petclinic</persistence-unit-name> > </persistence-context-ref> > The line <persistence-context-ref-name>persistence/petclinic-em</persistence-unit-ref-name> has an incorrect matching tag. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3068) could fail more gracefully when wrong Java version used

by Eduardo Silva (JIRA)

[ https://issues.jboss.org/browse/WFLY-3068?page=com.atlassian.jira.plugin.... ] Eduardo Silva commented on WFLY-3068: ------------------------------------- This is a common error that happens when you try to load/run classes with a previous runtime version. This is an known issue that is easy to figure out what you are doing wrong. Anyway, PluggableMBeanServerBuilder belongs to the WildFly Core. (WFCORE) > could fail more gracefully when wrong Java version used > ------------------------------------------------------- > > Key: WFLY-3068 > URL: https://issues.jboss.org/browse/WFLY-3068 > Project: WildFly > Issue Type: Bug > Components: Class Loading, Server > Affects Versions: 8.0.0.Final > Environment: Java version < 7 > Reporter: dpocock > Priority: Minor > > If I try to start Wildfly with Java 6 (which is no longer support of course) it just fails with a stack: > 09:51:00,536 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final > 09:51:00,543 WARN [org.jboss.modules] (main) Failed to define class org.jboss.as.jmx.PluggableMBeanServerBuilder in Module "org.jboss.as.jmx:main" from local module loader @36b60b93 (finder: local module finder @69b1fbf4 ()): java.lang.UnsupportedClassVersionError: org/jboss/as/jmx/PluggableMBeanServerBuilder : Unsupported major.minor version 51.0 > at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_26] > at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [rt.jar:1.6.0_26] > at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [rt.jar:1.6.0_26] > at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.Module.loadModuleClass(Module.java:548) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final] > at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:423) [rt.jar:1.6.0_26] > at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:465) [rt.jar:1.6.0_26] > at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:511) [rt.jar:1.6.0_26] > at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:298) [rt.jar:1.6.0_26] > at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:213) [rt.jar:1.6.0_26] > at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:174) [rt.jar:1.6.0_26] > at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302) [rt.jar:1.6.0_26] > at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504) [rt.jar:1.6.0_26] > at org.jboss.modules.Main.main(Main.java:449) [jboss-modules.jar:1.3.0.Final] > Exception in thread "main" java.lang.UnsupportedClassVersionError: org/jboss/as/jmx/PluggableMBeanServerBuilder : Unsupported major.minor version 51.0 > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) > at java.lang.ClassLoader.defineClass(ClassLoader.java:615) > at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) > at org.jboss.modules.Module.loadModuleClass(Module.java:548) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) > at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:423) > at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:465) > at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:511) > at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:298) > at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:213) > at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:174) > at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302) > at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504) > at org.jboss.modules.Main.main(Main.java:449) > It would be more friendly if it checked the Java version in the main() function and stopped gracefully. The stack trace is not hard to understand but may not be obvious to everybody. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4232) Update the structure for Hibernate Search modules

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/WFLY-4232?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated WFLY-4232: ---------------------------------- Fix Version/s: 9.0.0.CR1 (was: 9.0.0.CR2) > Update the structure for Hibernate Search modules > ------------------------------------------------- > > Key: WFLY-4232 > URL: https://issues.jboss.org/browse/WFLY-4232 > Project: WildFly > Issue Type: Enhancement > Components: JPA / Hibernate > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Critical > Fix For: 9.0.0.CR1 > > > In Hibernate Search 5 we fixed some classloading issues and highly improved the overall modules structure to avoid leaking any unrequested dependency and minimize classloader exposure to each sub-component as needed. > I expect this to also improve performance - for example - of Hibernate classpath scanning. > The modules built in WildFly for Hibernate Search still mimick the structure we had in Hibernate Search 4, we should improve this to get the same shape as the modules we build during a release of Hibernate Search 5. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4200) WAR MDB cannot obtain superclass on module classpath

by Eduardo Silva (JIRA)

[ https://issues.jboss.org/browse/WFLY-4200?page=com.atlassian.jira.plugin.... ] Eduardo Silva commented on WFLY-4200: ------------------------------------- I believe that the problem is because AnnotatedEJBComponentDescriptionDeploymentUnitProcessor executes in the parse phase: Phase.PARSE,Phase.PARSE_CREATE_COMPONENT_DESCRIPTIONS Since the dependencies will be resolved at Phase.DEPENDENCIES, your build will not work. Regarding WFLY, my suggestion is not throw the EjbLogger.ROOT_LOGGER.mdbDoesNotImplementNorSpecifyMessageListener(beanClass) only bring up some flag that the required interfaces were not yet resolved, some attachment could be useful, just to retain the super class name. When the dependencies were solved, the class will be present on the class index and the test against the annotation should be performed again. Since that work will be done twice, to verify the required interfaces, this requires some experts advice. > WAR MDB cannot obtain superclass on module classpath > ---------------------------------------------------- > > Key: WFLY-4200 > URL: https://issues.jboss.org/browse/WFLY-4200 > Project: WildFly > Issue Type: Bug > Components: Class Loading, EJB > Affects Versions: 8.2.0.Final > Reporter: John Mazzitelli > Priority: Minor > Attachments: mdb-test.zip > > > see the forum post for details: > https://developer.jboss.org/message/914355 > but suffice it to say this is similar to https://issues.jboss.org/browse/AS7-2638 which appears to have come back again. > In my WAR, I have an MDB which extends a class (in which that superclass implements MessageListener) and that superclass is in a module that my WAR depends on; the MDB fails to deploy. I have to explicitly add an annotation attribute to workaround the problem. > Again, see the forum for the very easy steps to replicate with a small zip file that contains the replication code. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 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 May 2015