April 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3284) Update add-user to automatically drop into silent mode if already non interactive and no console.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-3284: -------------------------------------- Summary: Update add-user to automatically drop into silent mode if already non interactive and no console. Key: WFLY-3284 URL: https://issues.jboss.org/browse/WFLY-3284 Project: WildFly Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Darran Lofthouse Assignee: Darran Lofthouse If we have enough information for add-user to run non-interactively and the console is not available we should drop into silent mode instead of reporting an error. -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3284) Update add-user to automatically drop into silent mode if already non interactive and no console.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3284?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-3284: ----------------------------------- Fix Version/s: 9.0.0.CR1 > Update add-user to automatically drop into silent mode if already non interactive and no console. > ------------------------------------------------------------------------------------------------- > > Key: WFLY-3284 > URL: https://issues.jboss.org/browse/WFLY-3284 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.CR1 > > > If we have enough information for add-user to run non-interactively and the console is not available we should drop into silent mode instead of reporting an error. -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3284) Update add-user to automatically drop into silent mode if already non interactive and no console.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3284?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-3284: ----------------------------------- Component/s: Domain Management Scripts > Update add-user to automatically drop into silent mode if already non interactive and no console. > ------------------------------------------------------------------------------------------------- > > Key: WFLY-3284 > URL: https://issues.jboss.org/browse/WFLY-3284 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Domain Management, Scripts > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.CR1 > > > If we have enough information for add-user to run non-interactively and the console is not available we should drop into silent mode instead of reporting an error. -- 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

12 years

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 reassigned WFLY-3282: -------------------------------------- Assignee: Darran Lofthouse (was: Tom Wells) > 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: Darran Lofthouse > 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

12 years

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 commented on WFLY-3282: ------------------------------------- My apologies. I did not realize your documentation is editable by end users. You can either close this as invalid or I can resolve it when finished editing -- your choice, please. > 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

12 years

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 commented on WFLY-3283: ----------------------------------------------- Jeff Mesnil <jmesnil(a)redhat.com> changed the Status of [bug 1090961|https://bugzilla.redhat.com/show_bug.cgi?id=1090961] from NEW to POST > 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

12 years

1
0
0 / 0

[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

12 years

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

12 years

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

12 years

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

12 years

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 April 2014