February 2007 - jboss-dev-forums - Jboss List Archives

[Design of AOP on JBoss (Aspects/JBoss)] - Re: JBAS-2100 AOP integration in JBoss5

by adrian＠jboss.org

Build is broken: | BUILD FAILED | /home/ejort/jboss-head/build/build.xml:898: The following error occurred while executing this line: | /home/ejort/jboss-head/build/build-thirdparty.xml:145: A versioning problem exists: | Component: jboss/aop is at version: 2.0.0.alpha3 | but it is also required to be compatible with: [Compatible@c943d1{id=null, version=1.5.0.GA}, Compatible@18352d8{id=null, version=1.5.1.GA}, Compatible@b40ec4{id=null, version=1.5.2.GA}, Compatible@13576a2{id=null, version=1.5.3.GA}, Compatible@ff8c74{id=null, version=1.5.4.GA}] | by: jboss/messaging | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021271#4021271 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021271

19 years, 1 month

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: JBAS-2100 AOP integration in JBoss5

by kabir.khan＠jboss.com

I have made AOP 2.0.0.alpha3 available in the repository and upgraded the microcontainer and jboss-head builds to use it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021264#4021264 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021264

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Need cleanup of the attachments api

by adrian＠jboss.org

In most cases, the Component just overrides one piece of metadata (and usually it is not an override) e.g. the MC components "overrides" the BeanMetaData. I think it would be pretty annoying if the deployer needs to always code | Blah result = unit.getAttachment(Blah.class); | if (result == null && unit.isComponent()) | result = unit.getParent().getAtttachment(Blah.class); | IIRC. The case where Bill came across it originally was because he got an invocation of his deployer for every component when he just wanted to do it once per deployment (it was after the component deployers). I told him to add a check: | if (unit.isComponent()) | return; | We might want to add better support for deployers that aren't interested in components? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021261#4021261 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021261

19 years, 1 month

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Support for cross-cluster HAJNDI list operations

by schaefera

If you don't want to fix it why can't then at least the entries from the HA-Singleton be entered into the HAJNDI because that are the most likely candidates not to be found on a local JNDI.list() call? -Andy View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021260#4021260 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021260

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Scoped Kernels

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : but also needs to use ConstrollerContext.getScopeKey() | | From previous problem (duplicate 'context') temp fix, I currently have Context's hashCode under WORK level to diff the contexts. What's the appropriate fix? | I don't understand that. anonymous wrote : | What about this new scope key - gained from class/bean (deployment) annotations? Should it be considered once it is resolved - with some update to current context scope - or is this how I used it ok --> install ScopeKey. It's generally a bad idea to change an identity (hashCode/equals) unless you are sure that nobody storing an object in a collection is going to be broken by it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021257#4021257 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021257

19 years, 1 month

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Support for cross-cluster HAJNDI list operations

by JerryGauth

As Scott noted, HAJNDI 's list() and listBindings() operations are based upon the corresponding JNDI operations. Consequently they only return entries relative to the HAJNDI tree. It is possible to bind to the HAJNDI tree although this probably isn't done by any JBoss modules right now. Entries bound to the HAJNDI tree are replicated throughout the cluster and consequently readily available on all nodes via HAJNDI. There's probably no reason why HAJNDI can't offer new operations that return all bindings in a cluster. As Brian noted, it would be necessary to determine how to handle situations where objects are bound under the same key on multiple local nodes. Alternatively, the operation might return all bindings for all nodes in the cluster, identifying the node associated with each key/value binding. For reference - HAJNDI in JBoss 5 is based on JBossCache but JBossCache is only used for entries bound in HAJNDI. Local bindings are outside the scope of HAJNDI and currently aren't stored in JBossCache. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021255#4021255 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021255

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: OSGi integration

by scott.stark＠jboss.org

Fine with me. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021251#4021251 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021251

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Need cleanup of the attachments api

by scott.stark＠jboss.org

That change was way back in Sep. So when requesting an attachment from a component it will pickup its parent. Is this ok or do we need a visitor to allow this to be up to the caller? I know there are circumstances in which one does need to look across DeploymentUnits and I did add a parent accessor to DeploymentUnit for this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021250#4021250 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021250

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: OSGi integration

by alesj

Ok, I'll first try to finish my current idea / impl, with delegation to existing OSGi framework. And then I'll try to carry on your work with refactoring of CL layer with package versioning. I think I'll bug you a lot then, with your huge CL experience. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021239#4021239 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021239

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Scoped Kernels

by alesj

"adrian(a)jboss.org" wrote : but also needs to use ConstrollerContext.getScopeKey() >From previous problem (duplicate 'context') temp fix, I currently have Context's hashCode under WORK level to diff the contexts. What's the appropriate fix? What about this new scope key - gained from class/bean (deployment) annotations? Should it be considered once it is resolved - with some update to current context scope - or is this how I used it ok --> install ScopeKey. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021234#4021234 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021234

19 years, 1 month

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-dev-forums February 2007