June 2014 - jboss-jira - Jboss List Archives

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2964?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2964: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1067024|https://bugzilla.redhat.com/show_bug.cgi?id=1067024] from NEW to ASSIGNED > Missing i18n > ------------ > > Key: WFLY-2964 > URL: https://issues.jboss.org/browse/WFLY-2964 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB, JMX, Patching > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 9.0.0.Alpha1 > > > system-jmx/src/main/java/org/jboss/system/ServiceMBeanSupport.java > 379 log.error(e); > patching/src/main/java/org/jboss/as/patching/validation/PatchArtifact.java > 102 ctx.getErrorHandler().error("Failed to load identity info for patch " + patch.getPatchId(), e); > 116 ctx.getErrorHandler().error("Failed to load previous patch", e); > patching/src/main/java/org/jboss/as/patching/validation/XmlFileState.java > 51 ctx.getErrorHandler().error("File doesn't exist: " + file.getAbsolutePath()); > 56 ctx.getErrorHandler().error("Failed to parse file: " + file.getAbsolutePath(), e); > patching/src/main/java/org/jboss/as/patching/validation/PatchElementProviderArtifact.java > 84 ctx.getErrorHandler().error("Layer not found: " + metadata.getName()); > patching/src/main/java/org/jboss/as/patching/runner/IdentityPatchContext.java > 435 PatchLogger.ROOT_LOGGER.warnf(e, "failed to undo change (%s)", modification); > ejb3/src/main/java/org/jboss/as/ejb3/tx/CMTTxInterceptor.java > 169 EjbLogger.ROOT_LOGGER.error(t); -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2964) Missing i18n

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2964?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2964: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1067024 > Missing i18n > ------------ > > Key: WFLY-2964 > URL: https://issues.jboss.org/browse/WFLY-2964 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB, JMX, Patching > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 9.0.0.Alpha1 > > > system-jmx/src/main/java/org/jboss/system/ServiceMBeanSupport.java > 379 log.error(e); > patching/src/main/java/org/jboss/as/patching/validation/PatchArtifact.java > 102 ctx.getErrorHandler().error("Failed to load identity info for patch " + patch.getPatchId(), e); > 116 ctx.getErrorHandler().error("Failed to load previous patch", e); > patching/src/main/java/org/jboss/as/patching/validation/XmlFileState.java > 51 ctx.getErrorHandler().error("File doesn't exist: " + file.getAbsolutePath()); > 56 ctx.getErrorHandler().error("Failed to parse file: " + file.getAbsolutePath(), e); > patching/src/main/java/org/jboss/as/patching/validation/PatchElementProviderArtifact.java > 84 ctx.getErrorHandler().error("Layer not found: " + metadata.getName()); > patching/src/main/java/org/jboss/as/patching/runner/IdentityPatchContext.java > 435 PatchLogger.ROOT_LOGGER.warnf(e, "failed to undo change (%s)", modification); > ejb3/src/main/java/org/jboss/as/ejb3/tx/CMTTxInterceptor.java > 169 EjbLogger.ROOT_LOGGER.error(t); -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-4175) Deployment content is not always removed from data/content

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-4175?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-4175: ---------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1035345|https://bugzilla.redhat.com/show_bug.cgi?id=1035345] from NEW to CLOSED > Deployment content is not always removed from data/content > ---------------------------------------------------------- > > Key: AS7-4175 > URL: https://issues.jboss.org/browse/AS7-4175 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.0.Final, 7.1.1.Final > Reporter: Brian Stansberry > Assignee: Kabir Khan > Priority: Critical > Fix For: 7.1.2.Final (EAP) > > Attachments: test-ds.xml > > > The AS7-341 fix doesn't seem to be working in some use cases. > I'll attach a test-ds.xml that can be used to manual reproduce this. Using a -ds.xml is useful since it's trivial to modify the deployment file to create a new hash. > From the CLI, this works (i.e. when both steps are done there are zero additional subdirectories in data/content, i.e. zero total directories on a fresh install): > [standalone@localhost:9999 /] deploy /home/me/test-ds.xml > [standalone@localhost:9999 /] undeploy test-ds.xml > However, this does not work (i.e. when both steps are done there is one additional subdirectories in data/content, i.e. one total directory on a fresh install): > [standalone@localhost:9999 /] deploy /home/me/test-ds.xml > manually modify /home/me/test-ds.xml > [standalone@localhost:9999 /] deploy --force /home/me/test-ds.xml > There may be other permutations of the of deploy/redeploy/undeploy that also leave file behind. In particular, the forum thread references using the jboss maven plugin, so whatever ops it is invoking should be checked. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3565) Incorrect use of ReloadRequiredWriteAttributeHandler for host resources

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3565?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3565: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1085228 > Incorrect use of ReloadRequiredWriteAttributeHandler for host resources > ----------------------------------------------------------------------- > > Key: WFLY-3565 > URL: https://issues.jboss.org/browse/WFLY-3565 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.1.0.Final > Reporter: Brian Stansberry > Priority: Critical > Fix For: 8.2.0.CR1, 9.0.0.Alpha1 > > > ReloadRequiredWriteAttributeHandler inherits the default behavior of AbstractWriteAttributeHandler.requiresRuntime(), which is to only process Stage.RUNTIME if context.isNormalServer(). So any use in host resources needs to override that behavior. This isn't done in at least some places. See https://bugzilla.redhat.com/show_bug.cgi?id=1085228 for an example. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3565) Incorrect use of ReloadRequiredWriteAttributeHandler for host resources

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-3565: -------------------------------------- Summary: Incorrect use of ReloadRequiredWriteAttributeHandler for host resources Key: WFLY-3565 URL: https://issues.jboss.org/browse/WFLY-3565 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Domain Management Affects Versions: 8.1.0.Final Reporter: Brian Stansberry Priority: Critical Fix For: 8.2.0.CR1, 9.0.0.Alpha1 ReloadRequiredWriteAttributeHandler inherits the default behavior of AbstractWriteAttributeHandler.requiresRuntime(), which is to only process Stage.RUNTIME if context.isNormalServer(). So any use in host resources needs to override that behavior. This isn't done in at least some places. See https://bugzilla.redhat.com/show_bug.cgi?id=1085228 for an example. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3564) Remove support for mixed-domain transforming to 7.1.x versions

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-3564: -------------------------------------- Summary: Remove support for mixed-domain transforming to 7.1.x versions Key: WFLY-3564 URL: https://issues.jboss.org/browse/WFLY-3564 Project: WildFly Issue Type: Task Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry (Deliberately currently unscheduled as I don't want this to become a priority unless there is clear need.) We will not support WF 9 mixed domains with slaves running releases prior to 7.2 (and maybe later) so we should remove the various transformer logic meant to deal with the fact that slaves in those early releases did not provide information about the version of subsystems they are running. KnownVersions can go, as can bits of logic that logged warns or errors instead of failing the transformation because the master could not know if the slave was going to ignore the resource. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3531) JPA persistence unit services should start completly before sub-deployments reach the next deployment phase

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3531?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3531: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1114726 > JPA persistence unit services should start completly before sub-deployments reach the next deployment phase > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-3531 > URL: https://issues.jboss.org/browse/WFLY-3531 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 9.0.0.Alpha1 > > > This is about EAR deployments that contain multiple sub-deployments. Currently, EJB jar sub-deployments may still be starting their JPA persistence units while other sub-deployments move ahead (in parallel) to other deployment phases (which can cause the entity classes to be loaded before the persistence provider has been registered with the class file transformer for the persistence unit). > Each deployment/sub-deployment should set the NEXT_PHASE_DEP on the persistence unit service (see current phaseContext.addToAttachmentList(Attachments.NEXT_PHASE_DEPS, puServiceName) in PersistenceUnitServiceHandler). For this to work, each deployment/subdeployment should set NEXT_PHASE_DEPS during the FIRST_MODULE_USE phase for each pre-determine persistence unit service name). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3563) Handle mixed-domain transformation use cases involving splitting out new subsystems

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-3563: -------------------------------------- Summary: Handle mixed-domain transformation use cases involving splitting out new subsystems Key: WFLY-3563 URL: https://issues.jboss.org/browse/WFLY-3563 Project: WildFly Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Fix For: 9.0.0.CR1 This may end up needing subtasks. We need to be able to handle the mixed-domain transformation issues that arise when a subsystem is split out from a previously existing subsystem. 1) The registering slave will have no version info for the new subsystem. The new subsystem needs to be able to register a transformer for the logical equivalent of the 'null' version. 2) It needs to be possible to register a discard for the root resource of a subsystem. For example, when jsf was split out, the presence of the subsystem was equivalent to the default behavior of the legacy 'web' subsystem, so jsf could just be discarded. 3) It needs to be possible for one subsystem to issue a reject transformation if the another subsystem is not configured. For example, when jsf was split out it would have been valid for a reject transformation to have been applied by web if the jsf subsystem was not present, since the legacy slave will have jsf. (It's ok this reject wasn't done; I'm just using jsf/web as an example.) -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-226) automatical modification of class and method Annotation

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-226?page=com.atlassian.jira.plugi... ] Shigeru Chiba commented on JASSIST-226: --------------------------------------- That's a different problem. Maybe a Signature attribute is missing or broken in your class file. > automatical modification of class and method Annotation > ------------------------------------------------------- > > Key: JASSIST-226 > URL: https://issues.jboss.org/browse/JASSIST-226 > Project: Javassist > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.18.0-GA > Environment: JavaSE-1.7, Eclipse Kepler > Reporter: Paolo Paolo > Assignee: Shigeru Chiba > Labels: annotations > > I'm using Javassist to create .class file at runtime. Every method of the created class must have a Java Annotation ("@annotation example") with an URI. The problem is that the Annotation class modifies automatically the URI by substituting slashes with dots. > //the Annotation String that I need > @RDFBean('http://www.semanticweb.org/pi/2014/5/test#Test') > //the resulting String > @RDFBean('http:..www.semanticweb.org.pi.2014.5.test#Test') > Is there a way to prevent this String modification? > I suppose it's related to the different notation between a file path and a Java package. > This is the code: > ClassPool pool = ClassPool.getDefault(); > CtClass cc = pool.makeClass(className); > > ClassFile ccFile = cc.getClassFile(); > ConstPool constpool = ccFile.getConstPool(); > // create the annotation > AnnotationsAttribute attr = new AnnotationsAttribute(constpool, AnnotationsAttribute.visibleTag); > // classLocalName contains: http://www.semanticweb.org/pi/2014/5/test#Test > Annotation annot = new Annotation("RDFBean('" + classLocalName + "')", constpool); > attr.addAnnotation(annot); > ccFile.addAttribute(attr); -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1182) Add SemaphoreConcurrentLinkedQueueManagedConnectionPool implementation

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1182?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBJCA-1182. ------------------------------------ Resolution: Done > Add SemaphoreConcurrentLinkedQueueManagedConnectionPool implementation > ---------------------------------------------------------------------- > > Key: JBJCA-1182 > URL: https://issues.jboss.org/browse/JBJCA-1182 > Project: IronJacamar > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core > Reporter: John O'Hara > Assignee: John O'Hara > Fix For: 1.2.0.Beta4 > > > An alternative implementation to SemaphoreArrayListManagedConnectionPool that does not require extensive intrinsic locking on key data structures within the connection pool to eliminate the thread contention we see withing the SemaphoreArrayListManagedConnectionPool under high load -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 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 June 2014