April 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3283) Upgrade Generic JMS RA to 1.0.5.Final

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-3283: --------------------------------- Summary: Upgrade Generic JMS RA to 1.0.5.Final Key: WFLY-3283 URL: https://issues.jboss.org/browse/WFLY-3283 Project: WildFly Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: JMS Affects Versions: 8.1.0.CR1 Reporter: Jeff Mesnil Assignee: Jeff Mesnil -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3283) Upgrade Generic JMS RA to 1.0.5.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3283?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3283: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1090961 > Upgrade Generic JMS RA to 1.0.5.Final > ------------------------------------- > > Key: WFLY-3283 > URL: https://issues.jboss.org/browse/WFLY-3283 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: JMS > Affects Versions: 8.1.0.CR1 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-460) Eval does not behave as intended

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-460?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-460: ------------------------------------------------ Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1089285|https://bugzilla.redhat.com/show_bug.cgi?id=1089285] from MODIFIED to ON_QA > Eval does not behave as intended > -------------------------------- > > Key: DROOLS-460 > URL: https://issues.jboss.org/browse/DROOLS-460 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Final > Reporter: Fabian Meyer > Assignee: Mario Fusco > Fix For: 6.1.0.Beta3 > > > Under certain conditions, eval does not behave as intended, when nested in a sub-network. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3197) ExternalContextFactory cuts context from deployment context/requires dependency on module

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-3197?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski edited comment on WFLY-3197 at 4/24/14 6:38 AM: ------------------------------------------------------------------- Ok. I finally got a moment to try it out. Well, workaround wont work in 100% cases - I'm actually facing one. Condition that must be met, is that there are no class versions classhes - for instance SecurityContextFactory and JBossSecurityContext. If there are, Proxy ( created from JNDI Ref ) must run in proper CL, in this case, factory module CL which will isolate it from AS7 env - keep all the factory module classes scoped and isolated. Possibly application could create fake module (jboss-deployment-structure->module ) which would contain required classes from deployment and have dependency on factory module to bring all those classes required for lookup. Just before call/lookup application would have to switch TCCL to this fake module. However this is wrong: - it moves CL magic into application - this is bad and this is the original reason I've started to dig ExternalContextFactory.module - ( I think ) it will make impossible to translate between classes that have two different versions( one in AS7 space second in factory module ) - for instance security packages suffer from this - iirc static methods - org.jboss.security.SecurityContextFactory.createSecurityContext and SecurityContextAssociation.* was (Author: baranowb): Ok. I finally got a moment to try it out. Well, workaround wont work in 100% cases - I'm actually facing one. Condition that must be met, is that there are no class versions classhes - for instance SecurityContextFactory and JBossSecurityContext. If there are, Proxy ( created from JNDI Ref ) must run in proper CL, in this case, factory module CL which will isolate it from AS7 env - keep all the factory module classes scoped and isolated. Possibly application could create fake module (jboss-deployment-structure->module ) which would contain required classes from deployment and have dependency on factory module to bring all those classes required for lookup. Just before call/lookup application would have to switch TCCL to this fake module. However this is wrong: - it moves CL magic into application - this is the original reason I've started to dig ExternalContextFactory.module - ( I think ) it will make impossible to translate between classes that have two different versions( one in AS7 space second in factory module ) - for instance security packages suffer from this - iirc static methods - org.jboss.security.SecurityContextFactory.createSecurityContext and SecurityContextAssociation.* > ExternalContextFactory cuts context from deployment context/requires dependency on module > ----------------------------------------------------------------------------------------- > > Key: WFLY-3197 > URL: https://issues.jboss.org/browse/WFLY-3197 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: 8.0.0.Final, 8.1.0.CR1 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 8.1.0.Final > > > WFLY-2777 changed CCL for context creation(if module is set in external context factory). This essentially cuts context from deployment classes during creation time. This can cause problems when external-context-factory.module classes (ObjectFactories, etc) require deployment classes to be visible from classloader which created context( external-context.module ) and are not found. > Steps to reproduce: > 1. define isolated module IM ( with classloader IM_CL ) > 2. create external-context-factory with module set to IM > 3. create some deployment with interface, for which proxies should be looked up via external-context ( with classloader D_CL ) - deployment has no dependency on IM, since it may contain legacy classes or unwanted dependencies > 4. lookup and invoke proxy > Now what will happen is during deployment external-context will be spawned just fine. However, the runtime outcome wont be pleasing. > Case 1: application and custom context dont do CCL magic > - invocation happen in deployment CCL, hence IM_CL classes are not visible and no classes required for deserialization can be loaded, this will fail ( return javax.naming.Reference instance, since ObjectFactory from IM_CL cant be found ) > Case 2: application or custom context switch CCL to IM_CL for lookup > - CCL is set to IM_CL, ObjectFactory can be found, but D_CL classes cant, hence some naming error probably > Neither of above will work, unless IM_CL and D_CL have some sort of dependency on each other, which just makes module CL configured in external-context-factory irrelevant, since D_CL will require dependency on IM_CL. > Workaround: > yes, store IM_CL in context wrapper and upon first invocation obtain CCL( hopefuly D_CL), create agregating CL and set it as CCL for each context invocation. > Possible fix: > 1. pass D_CL and IM_CL as part of env to factory, to allow context/context-wrapper to do some magic > 2. alter ExternalContextFactory and create agregating/delegating CL, which will just iterate over IM_CL and D_CL if present to load proper classes -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3282) Remote EJB invocations needs corrected ports and protocol

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3282?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-3282: ---------------------------------------- [~pbenedict] Do you see an edit link on that page? If so feel free to make some changes if you see errors in the documentation. > Remote EJB invocations needs corrected ports and protocol > --------------------------------------------------------- > > Key: WFLY-3282 > URL: https://issues.jboss.org/browse/WFLY-3282 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Documentation > Affects Versions: 8.1.0.CR1 > Reporter: Paul Benedict > Assignee: Tom Wells > Priority: Minor > Labels: jndi, remoting > > This page needs updating. > 1) It refers to old "remote" protocol but WildFly only supports "http-remoting" through HTTP Upgrade. > 2) All links to other pages point to AS71 not WFLY8. > https://docs.jboss.org/author/display/WFLY8/Remote+EJB+invocations+via+JN... -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3197) ExternalContextFactory cuts context from deployment context/requires dependency on module

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-3197?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski commented on WFLY-3197: ------------------------------------------ Ok. I finally got a moment to try it out. Well, workaround wont work in 100% cases - I'm actually facing one. Condition that must be met, is that there are no class versions classhes - for instance SecurityContextFactory and JBossSecurityContext. If there are, Proxy ( created from JNDI Ref ) must run in proper CL, in this case, factory module CL which will isolate it from AS7 env - keep all the factory module classes scoped and isolated. Possibly application could create fake module (jboss-deployment-structure->module ) which would contain required classes from deployment and have dependency on factory module to bring all those classes required for lookup. Just before call/lookup application would have to switch TCCL to this fake module. However this is wrong: - it moves CL magic into application - this is the original reason I've started to dig ExternalContextFactory.module - ( I think ) it will make impossible to translate between classes that have two different versions( one in AS7 space second in factory module ) - for instance security packages suffer from this - iirc static methods - org.jboss.security.SecurityContextFactory.createSecurityContext and SecurityContextAssociation.* > ExternalContextFactory cuts context from deployment context/requires dependency on module > ----------------------------------------------------------------------------------------- > > Key: WFLY-3197 > URL: https://issues.jboss.org/browse/WFLY-3197 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: 8.0.0.Final, 8.1.0.CR1 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 8.1.0.Final > > > WFLY-2777 changed CCL for context creation(if module is set in external context factory). This essentially cuts context from deployment classes during creation time. This can cause problems when external-context-factory.module classes (ObjectFactories, etc) require deployment classes to be visible from classloader which created context( external-context.module ) and are not found. > Steps to reproduce: > 1. define isolated module IM ( with classloader IM_CL ) > 2. create external-context-factory with module set to IM > 3. create some deployment with interface, for which proxies should be looked up via external-context ( with classloader D_CL ) - deployment has no dependency on IM, since it may contain legacy classes or unwanted dependencies > 4. lookup and invoke proxy > Now what will happen is during deployment external-context will be spawned just fine. However, the runtime outcome wont be pleasing. > Case 1: application and custom context dont do CCL magic > - invocation happen in deployment CCL, hence IM_CL classes are not visible and no classes required for deserialization can be loaded, this will fail ( return javax.naming.Reference instance, since ObjectFactory from IM_CL cant be found ) > Case 2: application or custom context switch CCL to IM_CL for lookup > - CCL is set to IM_CL, ObjectFactory can be found, but D_CL classes cant, hence some naming error probably > Neither of above will work, unless IM_CL and D_CL have some sort of dependency on each other, which just makes module CL configured in external-context-factory irrelevant, since D_CL will require dependency on IM_CL. > Workaround: > yes, store IM_CL in context wrapper and upon first invocation obtain CCL( hopefuly D_CL), create agregating CL and set it as CCL for each context invocation. > Possible fix: > 1. pass D_CL and IM_CL as part of env to factory, to allow context/context-wrapper to do some magic > 2. alter ExternalContextFactory and create agregating/delegating CL, which will just iterate over IM_CL and D_CL if present to load proper classes -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3230) StackOverflowError when trying to access non existing page/servlet in WildFly 8.0.0

by SBS JIRA Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3230?page=com.atlassian.jira.plugin.... ] SBS JIRA Integration updated WFLY-3230: --------------------------------------- Forum Reference: https://community.jboss.org/message/867014#867014 > StackOverflowError when trying to access non existing page/servlet in WildFly 8.0.0 > ----------------------------------------------------------------------------------- > > Key: WFLY-3230 > URL: https://issues.jboss.org/browse/WFLY-3230 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Reporter: Yaniv Peleg > Assignee: Stuart Douglas > Labels: jboss > Fix For: 8.1.0.Final > > > I am using WildFly 8.0.0 (Final). > When sending Post request to non existing page/servlet I get StackOverflowError exception. > Looks like there is infinit loop in method calls when processing the request. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created DROOLS-471: --------------------------------------- Summary: Remove repository jboss-deprecated Key: DROOLS-471 URL: https://issues.jboss.org/browse/DROOLS-471 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 6.1.0.Beta2 Reporter: Geoffrey De Smet Assignee: Michael Biarnes Kiefer 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated: {code} <repository> <id>jboss-deprecated</id> <name>JBoss Deprecated</name> <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url> <releases> <enabled>true</enabled> <updatePolicy>never</updatePolicy> </releases> <snapshots> <enabled>false</enabled> </snapshots> </repository> {code} https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom.... 2) remove your local repository 3) Do a mvn-all -Dfull build If it works, commit the change. If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-471?page=com.atlassian.jira.plugin... ] Geoffrey De Smet updated DROOLS-471: ------------------------------------ Description: 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated: {code} <repository> <id>jboss-deprecated</id> <name>JBoss Deprecated</name> <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url> <releases> <enabled>true</enabled> <updatePolicy>never</updatePolicy> </releases> <snapshots> <enabled>false</enabled> </snapshots> </repository> {code} https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom.... 2) remove your local repository 3) Do a mvn-all.sh -Dfull clean install If it works, commit the change. If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency. was: 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated: {code} <repository> <id>jboss-deprecated</id> <name>JBoss Deprecated</name> <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url> <releases> <enabled>true</enabled> <updatePolicy>never</updatePolicy> </releases> <snapshots> <enabled>false</enabled> </snapshots> </repository> {code} https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom.... 2) remove your local repository 3) Do a mvn-all -Dfull build If it works, commit the change. If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency. > Remove repository jboss-deprecated > ---------------------------------- > > Key: DROOLS-471 > URL: https://issues.jboss.org/browse/DROOLS-471 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Beta2 > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated: > {code} > <repository> > <id>jboss-deprecated</id> > <name>JBoss Deprecated</name> > <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url> > <releases> > <enabled>true</enabled> > <updatePolicy>never</updatePolicy> > </releases> > <snapshots> > <enabled>false</enabled> > </snapshots> > </repository> > {code} > https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom.... > 2) remove your local repository > 3) Do a mvn-all.sh -Dfull clean install > If it works, commit the change. > If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3282) Remote EJB invocations needs corrected ports and protocol

by Paul Benedict (JIRA)

[ https://issues.jboss.org/browse/WFLY-3282?page=com.atlassian.jira.plugin.... ] Paul Benedict updated WFLY-3282: -------------------------------- Description: This page needs updating. 1) It refers to old "remote" protocol but WildFly only supports "http-remoting" through HTTP Upgrade. 2) All links to other pages point to AS71 not WFLY8. https://docs.jboss.org/author/display/WFLY8/Remote+EJB+invocations+via+JN... was: This page needs updating. 1) It refers to old "remote" protocol but WildFly only supports "http-remoting" through HTTP Upgrade. 2) The link "EJB invocations from a remote client using JNDI" points to AS71 not WFLY8 https://docs.jboss.org/author/display/WFLY8/Remote+EJB+invocations+via+JN... > Remote EJB invocations needs corrected ports and protocol > --------------------------------------------------------- > > Key: WFLY-3282 > URL: https://issues.jboss.org/browse/WFLY-3282 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Documentation > Affects Versions: 8.1.0.CR1 > Reporter: Paul Benedict > Assignee: Tom Wells > Priority: Minor > Labels: jndi, remoting > > This page needs updating. > 1) It refers to old "remote" protocol but WildFly only supports "http-remoting" through HTTP Upgrade. > 2) All links to other pages point to AS71 not WFLY8. > https://docs.jboss.org/author/display/WFLY8/Remote+EJB+invocations+via+JN... -- 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

10 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2014