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

[Design of JBoss Web Services] - Re: Why is the UMDM using ConcurrentHashMap?

by jason.greene＠jboss.com

ConcurrentHashMap usually does not lock on reads with a successful ConcurrentHashMap usually does not lock on reads with a successful result. However, if the entry does not exist, a lock is always held on the corresponding stripe. Along with the extra locking, it also adds more processing and memory overhead. All of this is of course needed to handle multiple concurrent writers (or the possibility of multiple concurrent writers). However, since the UMD is written to only at the start, and only from one thread, no synchronization is needed, even in that single thread. So, since no locking is needed, there is no need for ConcurrentHashMap. It could be argued though that ConcurrentHashMap would improve safety, since improper use of the UMD (a writer happens after eager initialization for example) would be slightly protected. However the problem is that this would only be protecting one of the many internal types within the UMD, so the overall access to it still can not allow for multiple writers, unless of course, it was redesigned to allow for the multiple writer scenario. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4014598#4014598 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4014598

19 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Why is the UMDM using ConcurrentHashMap?

by heiko.braun＠jboss.com

anonymous wrote : | The design of the UMDM is that writes are confined to single thread on startup, and all access after that point is read-only. | Exactly. That's the reason why i changed it. The ConcurrentHashMap does not entail locking on read operations. I think this is the desired behaviour or did i miss your point? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4014575#4014575 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4014575

19 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: various questions

by kukeltje

Tom, The subject could be the 'business' key Gavin also wants for seam (at least that is how I interpret it) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4014556#4014556 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4014556

19 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: initial nodes

by kukeltje

great news Tom.. maybe I should 'fix' the issue of starting a process WITH passing initial variables. (it is assigned to me) That would be a nice combination. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4014555#4014555 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4014555

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Lifecycle aspects revisited

by scott.stark＠jboss.org

It seems that this notion should be something that integrates at the ClassAdapter as Adrian was talking about here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=94495 rather than as interceptors on the KernelControllerContextAware methods. I'm not that familiar with the KernelControllerContextAction notions, but @JMX and @Jndi should probably show up as additional side effect behaviors run during the corresponding kernel lifecycle phase. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4014352#4014352 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4014352

19 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: repository.jboss.com/maven2 missing files??

by scott.stark＠jboss.org

There should be, but I think this is still a work in progress by Paul: | [starksm@succubus 2.0.0.Beta]$ cvs log jboss-metatype-2.0.0.Beta.jar | | RCS file: /cvsroot/jboss/repository.jboss.com/maven2/jboss/jboss-metatype/2.0.0.Beta/jboss-metatype-2.0.0.Beta.jar,v | Working file: jboss-metatype-2.0.0.Beta.jar | head: 1.1 | branch: | locks: strict | access list: | symbolic names: | keyword substitution: b | total revisions: 1; selected revisions: 1 | description: | ---------------------------- | revision 1.1 | date: 2007/01/18 21:28:44; author: pgier; state: Exp; | JBMICROCONT-117; Added microcontainer subproject metatype. | ============================================================================= | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4014311#4014311 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4014311

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Lifecycle aspects revisited

by kabir.khan＠jboss.com

Another issue at the moment is if something for example has both lifecycle-configure and aop:lifecycle-install aspects. In this case setKernelControllerContext() gets called both during configure and install, with no real way to controll which of the lifecycle aspects to call. This could be handled at aspect level, since we have access to the KernelControllerContext, but that seems slightly ugly. Would it make sense to make these methods more finegrained? i.e. | public interface ConfigureKernelControllerContextAware extends KernelControllerContextAware | { | void setConfigureKernelControllerContext(KernelControllerContext context) throws Exception; | void unsetConfigureKernelControllerContext(KernelControllerContext context) throws Exception; | } | | public interface InstallKernelControllerContextAware extends KernelControllerContextAware | { | void setInstallKernelControllerContext(KernelControllerContext context) throws Exception; | void unsetInstallKernelControllerContext(KernelControllerContext context) throws Exception; | | ... | } WRT my previous post the default pointcut for a lifecycle-configure would then become | execution(* CLASSES_VALUE->$implements{org.jboss.kernel.spi.dependency.ConfigureKernelControllerContextAware}(..))" | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4014270#4014270 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4014270

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Lifecycle aspects revisited

by kabir.khan＠jboss.com

I also think it should be possible to make the pointcut attribute optional for the lifecycle events | <aop:lifecycle-configure xmlns:aop="urn:jboss:aop-beans:1.0" | name="JMXLifecycle" | class="org.jboss.aop.microcontainer.aspects.jmx.JMXIntroduction" | classes="@org.jboss.aop.microcontainer.aspects.jmx.JMX" | </aop:lifecycle-configure> | Since in most cases the pointcut will be something along the lines of | execution(* CLASSES_VALUE->$implements{org.jboss.kernel.spi.dependency.KernelControllerContextAware}(..))"> | i.e.: | execution(* @org.jboss.aop.microcontainer.aspects.jmx.JMX->$implements{org.jboss.kernel.spi.dependency.KernelControllerContextAware}(..))"> | If something apart from this defaul needs doing it will be possible to specify the "pointcut" attribute as it works at present. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4014258#4014258 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4014258

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Lifecycle aspects revisited

by kabir.khan＠jboss.com

One problem with the current lifecycle introduction aspects (JMXIntroduction, JndiIntroduction) is that they do not call invocation.invokeNext(). This means that if we use both the @JMX and the @JndiBinding annotations to a bean, the first one in the chain wins, so we either get registered in JMX or in JNDI, but not both. If these asepcts are changed to call invokeNext(), we will eventually end up with the MethodInvocation trying to call the setKernelControllerContext() method in the target which does not exist, resulting in an exception. I think the woven/proxy code needs to be modified to detect if an interface introduction is the cause of the MethodInvocation, and if this is the case we do not attempt to call the target method at the end of the interceptor chain. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4014257#4014257 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4014257

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Registering a bean as an aspect in the bootstrap

by kabir.khan＠jboss.com

"scott.stark(a)jboss.org" wrote : | There does not appear to be any support for specifying which method in an aspect to use via the aop:lifecycle-configure element. How would I map these aop.xml element to an aop:lifecycle-configure equivalent? | | This has been fixed, you can now do: | <aop:lifecycle-configure xmlns:aop="urn:jboss:aop-beans:1.0" | name="JMXLifecycle" | class="org.jboss.test.microcontainer.support.TestAspect" | classes="@org.jboss.aop.microcontainer.aspects.jmx.JMX" | method="foo" | pointcut="execution(* @org.jboss.aop.microcontainer.aspects.jmx.JMX->$implements{org.jboss.kernel.spi.dependency.KernelControllerContextAware}(..))"> | <property name="shouldInvoke">false</property> | </aop:lifecycle-configure> | "method" specifies the aspect method View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4014255#4014255 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4014255

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