May 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4580) Lifecycle interceptors do not work

by Xavier Dury (JIRA)

[ https://issues.jboss.org/browse/WFLY-4580?page=com.atlassian.jira.plugin.... ] Xavier Dury commented on WFLY-4580: ----------------------------------- The problem is indeed coming from the way interceptors are declared (via {{@Interceptors}} they work; via {{beans.xml}} they don't). I opened an other issue for Weld (WELD-1945). This one can be closed. > Lifecycle interceptors do not work > ---------------------------------- > > Key: WFLY-4580 > URL: https://issues.jboss.org/browse/WFLY-4580 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: JBoss AS7 7.1.1.Final, 8.2.0.Final > Reporter: Xavier Dury > Assignee: Stuart Douglas > > I've been trying to use lifecycle interceptors (intercepting PostConstruct and PreDestroy, see https://issues.jboss.org/browse/WELD-1346 for reference) in my project and those do not seem to work at all (nor on enterprise managed beans nor on regular CDI managed beans). > I tried on both JBoss AS 7.1.1 and Wildfly 8.2.0 but lifecycle interceptors are never called while other interceptors (AroundInvoke) are. > I tested the same code on OpenEJB and it works. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-709) fuse-bxms-integ list of build/release issues

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-709?page=com.atlassian.jira.plugin... ] Geoffrey De Smet updated DROOLS-709: ------------------------------------ Fix Version/s: 6.3.0.Beta1 > fuse-bxms-integ list of build/release issues > -------------------------------------------- > > Key: DROOLS-709 > URL: https://issues.jboss.org/browse/DROOLS-709 > Project: Drools > Issue Type: Bug > Reporter: Geoffrey De Smet > Assignee: Edson Tirelli > Priority: Blocker > Fix For: 6.3.0.Beta1 > > > Here's a summary of the issues discussed in e-mail so we can track them. > 1) fuse-bxms-integ violates Red Hat naming: > We can't use a product name ("Fuse", "bxms") for community code. > The repository contains community glue code between camel and kie, > so for example "camel-kie-integ" would be better. > Is drools-camel open source? > If yes, then we want the community to be able to use it and report issues before we release the product version. > 2) The artifacts of fuse-bxms-integ all still use the groupId "org.kie", > but supposedly have their a different version numbering than org.kie's artifacts. > 2 artifacts in the same groupId must use the exact same version numbering and release lifecycle! > So the groupId must be changed before its released. > 3) fuse-bxms-integ will use it's own version numbering, so it should not use kie's "6.2.0.Final" > Either it uses a neutral number, such as "1.0.0.Final" > or it defines a pattern based on it's kie and it's camel dependency. For example "6.2.0.Final-2.14.1.Final" (bad example, violates OSGi guidelines). > Calling it "6.2.0.Final" is just asking for confusion and trouble, > because productization scripts will presume it's 100% equal to the kie version. > 4) Now one seems to have the faintest idea how we'll handle branching: think camel 2.14.x, camel 2.13.x, kie 6.2.x, camel 2.12.x, kie 6.1.x, ... > 5) // Not valid > 6) Renaming the java packages according to the new groupId/artifactId we will choose (as we did in the past with all other projects) and also fix the OSGi manifest and features.xml files accordingly. > 7) migrating the optaplanner-camel module in the new integration project. > Note: ge0ffrey will migrate optaplanner-camel after the other issues in this list are solved to avoid breaking users now. > 8) It's artifacts are currently: > - no longer extending droolsjbpm-parent(-with-dependencies) > - no longer in the kie-bom > and that the repo is no longer in our github organization or git-clone-others script, but it is part of our release. > So it's already quite different than in 6.1. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4580) Lifecycle interceptors do not work

by Xavier Dury (JIRA)

[ https://issues.jboss.org/browse/WFLY-4580?page=com.atlassian.jira.plugin.... ] Xavier Dury commented on WFLY-4580: ----------------------------------- WELD-1391 is very similar to my issue (and seems to have been fixed before Weld 2.0 final) but there I see that interceptors are declared via {{@Interceptors}} whereas I'm declaring them in {{beans.xml}}. Maybe this issue should be transferred to WELD... > Lifecycle interceptors do not work > ---------------------------------- > > Key: WFLY-4580 > URL: https://issues.jboss.org/browse/WFLY-4580 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: JBoss AS7 7.1.1.Final, 8.2.0.Final > Reporter: Xavier Dury > Assignee: Stuart Douglas > > I've been trying to use lifecycle interceptors (intercepting PostConstruct and PreDestroy, see https://issues.jboss.org/browse/WELD-1346 for reference) in my project and those do not seem to work at all (nor on enterprise managed beans nor on regular CDI managed beans). > I tried on both JBoss AS 7.1.1 and Wildfly 8.2.0 but lifecycle interceptors are never called while other interceptors (AroundInvoke) are. > I tested the same code on OpenEJB and it works. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-493) Automatically index static modules as required

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFCORE-493?page=com.atlassian.jira.plugin... ] Tomasz Adamski closed WFCORE-493. --------------------------------- Resolution: Done > Automatically index static modules as required > ---------------------------------------------- > > Key: WFCORE-493 > URL: https://issues.jboss.org/browse/WFCORE-493 > Project: WildFly Core > Issue Type: Feature Request > Components: Server > Reporter: Stuart Douglas > Assignee: Tomasz Adamski > Fix For: 1.0.0.CR1 > > > If a static module has an annotation import it should be automatically indexed -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-493) Automatically index static modules as required

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFCORE-493?page=com.atlassian.jira.plugin... ] Tomasz Adamski updated WFCORE-493: ---------------------------------- Fix Version/s: 1.0.0.CR1 > Automatically index static modules as required > ---------------------------------------------- > > Key: WFCORE-493 > URL: https://issues.jboss.org/browse/WFCORE-493 > Project: WildFly Core > Issue Type: Feature Request > Components: Server > Reporter: Stuart Douglas > Assignee: Tomasz Adamski > Fix For: 1.0.0.CR1 > > > If a static module has an annotation import it should be automatically indexed -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1077) JDK ORB Subsystem

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-1077?page=com.atlassian.jira.plugin.... ] Tomasz Adamski updated WFLY-1077: --------------------------------- Fix Version/s: 9.0.0.CR1 > JDK ORB Subsystem > ----------------- > > Key: WFLY-1077 > URL: https://issues.jboss.org/browse/WFLY-1077 > Project: WildFly > Issue Type: Feature Request > Components: IIOP > Reporter: Dimitris Andreadis > Assignee: Tomasz Adamski > Fix For: 9.0.0.CR1 > > > Implement a JDK ORB subsystem that can act as a replacement for the JacORB subsystem. > AFAIK, most/all JDK ORBs are based on the Sun ORB. > Ideally the 2 ORBs (JDK & JacORB) would be both supported in case we need to go through a transition period, or we need to support a particular interop scenario for which interop communication has issues. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1077) JDK ORB Subsystem

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-1077?page=com.atlassian.jira.plugin.... ] Tomasz Adamski commented on WFLY-1077: -------------------------------------- OK. Will clean it then. > JDK ORB Subsystem > ----------------- > > Key: WFLY-1077 > URL: https://issues.jboss.org/browse/WFLY-1077 > Project: WildFly > Issue Type: Feature Request > Components: IIOP > Reporter: Dimitris Andreadis > Assignee: Tomasz Adamski > Fix For: 9.0.0.CR1 > > > Implement a JDK ORB subsystem that can act as a replacement for the JacORB subsystem. > AFAIK, most/all JDK ORBs are based on the Sun ORB. > Ideally the 2 ORBs (JDK & JacORB) would be both supported in case we need to go through a transition period, or we need to support a particular interop scenario for which interop communication has issues. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4306) IIOP Subsystem: Attribute groups refactor

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-4306?page=com.atlassian.jira.plugin.... ] Tomasz Adamski updated WFLY-4306: --------------------------------- Fix Version/s: 9.0.0.CR1 > IIOP Subsystem: Attribute groups refactor > ----------------------------------------- > > Key: WFLY-4306 > URL: https://issues.jboss.org/browse/WFLY-4306 > Project: WildFly > Issue Type: Enhancement > Components: IIOP > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > 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-1077) JDK ORB Subsystem

by Dimitris Andreadis (JIRA)

[ https://issues.jboss.org/browse/WFLY-1077?page=com.atlassian.jira.plugin.... ] Dimitris Andreadis commented on WFLY-1077: ------------------------------------------ A JIRA needs to record exactly the work done for for a particular milestone/release, otherwise, how do you know, e.g. when the JDK ORB subsystem was introduced in a release? Is it, or is it not part of WF 9 CR1? How else the release notes can be accurate for any release? If there is extra work, it has to be tracked separately. > JDK ORB Subsystem > ----------------- > > Key: WFLY-1077 > URL: https://issues.jboss.org/browse/WFLY-1077 > Project: WildFly > Issue Type: Feature Request > Components: IIOP > Reporter: Dimitris Andreadis > Assignee: Tomasz Adamski > > Implement a JDK ORB subsystem that can act as a replacement for the JacORB subsystem. > AFAIK, most/all JDK ORBs are based on the Sun ORB. > Ideally the 2 ORBs (JDK & JacORB) would be both supported in case we need to go through a transition period, or we need to support a particular interop scenario for which interop communication has issues. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1077) JDK ORB Subsystem

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-1077?page=com.atlassian.jira.plugin.... ] Tomasz Adamski commented on WFLY-1077: -------------------------------------- I decided to keep this issue open as there are still fixes to IIOP subsystem - like configuration refactor or now graceful shutdown. If they can be addressed only in their own JIRAs then I will close this one. > JDK ORB Subsystem > ----------------- > > Key: WFLY-1077 > URL: https://issues.jboss.org/browse/WFLY-1077 > Project: WildFly > Issue Type: Feature Request > Components: IIOP > Reporter: Dimitris Andreadis > Assignee: Tomasz Adamski > > Implement a JDK ORB subsystem that can act as a replacement for the JacORB subsystem. > AFAIK, most/all JDK ORBs are based on the Sun ORB. > Ideally the 2 ORBs (JDK & JacORB) would be both supported in case we need to go through a transition period, or we need to support a particular interop scenario for which interop communication has issues. -- 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