March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6121) Naming subsystem <lookup> could use LinkRef/Reference

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/AS7-6121?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on AS7-6121: ---------------------------------- Aha OK. So I was discussing this with [~emmartins] and I think the best path would be to add a "<link>" tag to the subsystem config. It is my opinion that "<lookup>" should behave equivalently to <env-entry>-with-<lookup>, which is how this appears to behave today. > Naming subsystem <lookup> could use LinkRef/Reference > ----------------------------------------------------- > > Key: AS7-6121 > URL: https://issues.jboss.org/browse/AS7-6121 > Project: Application Server 7 > Issue Type: Feature Request > Components: Naming > Affects Versions: 7.1.3.Final (EAP) > Reporter: James Livingston > Assignee: Eduardo Martins > Fix For: 7.2.0.Alpha1 > > > NameBindingAdd.installLookup() sets up the machinery so that when Context.lookup() is done it looks up the redirected name and returns it. > It should be possible to do that by binding a LinkRef, Reference or similar object into JNDI instead. > Where this could make a difference is when Context.lookupLink() is called instead. > Currently if you have > <simple name="java:/v" value="hello"/> > <lookup name="java:/a" lookup="java:/b"/> > lookupLink("java:/a") will return "hello" rather a LinkRef/Reference/whatever pointing to java:/b. > We need to decide whether a <lookup> should be considered a "link" for the purposes of lookup() or not. If it should be considered one, then we should change NameBindingAdd.installLookup() to make lookupLink() return the other value. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-6121) Naming subsystem <lookup> could use LinkRef/Reference

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6121?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-6121: --------------------------------------- David, that's from the naming subsystem config. > Naming subsystem <lookup> could use LinkRef/Reference > ----------------------------------------------------- > > Key: AS7-6121 > URL: https://issues.jboss.org/browse/AS7-6121 > Project: Application Server 7 > Issue Type: Feature Request > Components: Naming > Affects Versions: 7.1.3.Final (EAP) > Reporter: James Livingston > Assignee: Eduardo Martins > Fix For: 7.2.0.Alpha1 > > > NameBindingAdd.installLookup() sets up the machinery so that when Context.lookup() is done it looks up the redirected name and returns it. > It should be possible to do that by binding a LinkRef, Reference or similar object into JNDI instead. > Where this could make a difference is when Context.lookupLink() is called instead. > Currently if you have > <simple name="java:/v" value="hello"/> > <lookup name="java:/a" lookup="java:/b"/> > lookupLink("java:/a") will return "hello" rather a LinkRef/Reference/whatever pointing to java:/b. > We need to decide whether a <lookup> should be considered a "link" for the purposes of lookup() or not. If it should be considered one, then we should change NameBindingAdd.installLookup() to make lookupLink() return the other value. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-6121) Naming subsystem <lookup> could use LinkRef/Reference

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/AS7-6121?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on AS7-6121: ---------------------------------- [~jameslivingston] - what XML are you quoting in the description? Is that from some deployment descriptor? > Naming subsystem <lookup> could use LinkRef/Reference > ----------------------------------------------------- > > Key: AS7-6121 > URL: https://issues.jboss.org/browse/AS7-6121 > Project: Application Server 7 > Issue Type: Feature Request > Components: Naming > Affects Versions: 7.1.3.Final (EAP) > Reporter: James Livingston > Assignee: Eduardo Martins > Fix For: 7.2.0.Alpha1 > > > NameBindingAdd.installLookup() sets up the machinery so that when Context.lookup() is done it looks up the redirected name and returns it. > It should be possible to do that by binding a LinkRef, Reference or similar object into JNDI instead. > Where this could make a difference is when Context.lookupLink() is called instead. > Currently if you have > <simple name="java:/v" value="hello"/> > <lookup name="java:/a" lookup="java:/b"/> > lookupLink("java:/a") will return "hello" rather a LinkRef/Reference/whatever pointing to java:/b. > We need to decide whether a <lookup> should be considered a "link" for the purposes of lookup() or not. If it should be considered one, then we should change NameBindingAdd.installLookup() to make lookupLink() return the other value. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-6306) Validate composite operation steps just before executing them

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6306?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-6306: --------------------------------------- Yes, we roll back. I wasn't clear in the description. In all cases, the various steps are all steps within the same overall operation execution. So failure of any step triggers rollback. > Validate composite operation steps just before executing them > ------------------------------------------------------------- > > Key: AS7-6306 > URL: https://issues.jboss.org/browse/AS7-6306 > Project: Application Server 7 > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > Say we have a composite operation with 2 steps: > 1) /extension=org.jboss.as.messaging:add > 2) /subsystem=messaging:add > This will fail: > Failed to execute batch: JBAS014739: No handler for add at address > [("subsystem" => "messaging")] > This fails because at the time of validation the /subsystem=messaging:add is not valid. > To illustrate, the execution order is > Validate 1-2 > 1 > 2 > A possible solution is to convert this to the following: > V1 > 1 > V2 (works now because 1 has registered the subsystem API) > 2 > I think that should work but it's a very complex area, particularly in a managed domain, so it's not at all certain this would prove feasible. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-4464) EJB3 deployment metrics missing

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-4464?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration updated AS7-4464: ----------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=911117, https://bugzilla.redhat.com/show_bug.cgi?id=917129 (was: https://bugzilla.redhat.com/show_bug.cgi?id=911117) > EJB3 deployment metrics missing > ------------------------------- > > Key: AS7-4464 > URL: https://issues.jboss.org/browse/AS7-4464 > Project: Application Server 7 > Issue Type: Bug > Components: EJB > Affects Versions: 7.1.1.Final > Reporter: Stefan Negrea > Assignee: Carlo de Wolf > Priority: Critical > Labels: rhq > Fix For: 7.2.0.CR1 > > > The following metrics are missing from AS7 EJB3 subsystem from deployment when compared to AS5 exposed metrics: > Stateless Session Bean > Method Invocation Time - The minimum, maximum, and average invocation times for each of the methods exposed by this EJB > Stateful Session Bean > Method Invocation Time - The minimum, maximum, and average invocation times for each of the methods exposed by this EJB > Cache Size - Cache Size > Passivated Count - Passivated Count > Total Size - Total Size -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBEE-128) EJB 3.2 API (JSR-345) for EE7

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/JBEE-128?page=com.atlassian.jira.plugin.s... ] Shelly McGowan commented on JBEE-128: ------------------------------------- Alpha1 released: https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/j... > EJB 3.2 API (JSR-345) for EE7 > ------------------------------ > > Key: JBEE-128 > URL: https://issues.jboss.org/browse/JBEE-128 > Project: JBoss JavaEE Spec APIs > Issue Type: Sub-task > Components: jboss-ejb-api, jboss-javaee-specs > Reporter: jaikiran pai > Assignee: jaikiran pai > Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1 > > > Update the Java EE EJB API to incorporate the EJB 3.2 updates. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-6306) Validate composite operation steps just before executing them

by John Doyle (JIRA)

[ https://issues.jboss.org/browse/AS7-6306?page=com.atlassian.jira.plugin.s... ] John Doyle commented on AS7-6306: --------------------------------- It's not clear to me that the possible solution is desirable. What if V2 fails? Do we rollback? > Validate composite operation steps just before executing them > ------------------------------------------------------------- > > Key: AS7-6306 > URL: https://issues.jboss.org/browse/AS7-6306 > Project: Application Server 7 > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > Say we have a composite operation with 2 steps: > 1) /extension=org.jboss.as.messaging:add > 2) /subsystem=messaging:add > This will fail: > Failed to execute batch: JBAS014739: No handler for add at address > [("subsystem" => "messaging")] > This fails because at the time of validation the /subsystem=messaging:add is not valid. > To illustrate, the execution order is > Validate 1-2 > 1 > 2 > A possible solution is to convert this to the following: > V1 > 1 > V2 (works now because 1 has registered the subsystem API) > 2 > I think that should work but it's a very complex area, particularly in a managed domain, so it's not at all certain this would prove feasible. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-6661) Ensure OperationFailedException constructors don't allow null failure description

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6661?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-6661: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 Component/s: Domain Management > Ensure OperationFailedException constructors don't allow null failure description > --------------------------------------------------------------------------------- > > Key: AS7-6661 > URL: https://issues.jboss.org/browse/AS7-6661 > Project: Application Server 7 > Issue Type: Enhancement > Components: Domain Management > Environment: OFE.getFailureDescription() should not return null. > OperationClientException javadoc should clearly state this. > An OFE(Throwable cause) constructor would be good; just call this(cause.getMessage(), cause). > Reporter: Brian Stansberry > Fix For: 8.0.0.Alpha1 > > -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-6661) Ensure OperationFailedException constructors don't allow null failure description

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-6661: ------------------------------------- Summary: Ensure OperationFailedException constructors don't allow null failure description Key: AS7-6661 URL: https://issues.jboss.org/browse/AS7-6661 Project: Application Server 7 Issue Type: Enhancement Environment: OFE.getFailureDescription() should not return null. OperationClientException javadoc should clearly state this. An OFE(Throwable cause) constructor would be good; just call this(cause.getMessage(), cause). Reporter: Brian Stansberry -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-6655) binding subcontexts with <lookup> does not work

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/AS7-6655?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on AS7-6655: ---------------------------------- If we do end up supporting this, we need to make sure that the JNDI dependency resolver understands the meaning of it. > binding subcontexts with <lookup> does not work > ----------------------------------------------- > > Key: AS7-6655 > URL: https://issues.jboss.org/browse/AS7-6655 > Project: Application Server 7 > Issue Type: Bug > Components: Naming > Affects Versions: 7.1.3.Final (EAP) > Reporter: James Livingston > Assignee: Eduardo Martins > > If you attempt to bind a subcontext via <lookup> in the naming subsystem it will fail when anything is looked up under it. > To reproduce, add <lookup name="java:jboss/ds" lookup="java:jboss/datasources"/>, and then look up something under java:jboss/ds/ > In ServiceBasedNamingStore.lookup() it needs to return a ResolveResult, but the (!(obj instanceof NamingContext)) check skips it. > As a work-around, you can write an object factory which looks up the sub-context and then returns a wrapper around it, a Context implementation which simply delegates all methods to the original context. Since that wrapper is not a NamingContext instance, it works. -- 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

11 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2013