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

[Design of JBoss/Tomcat Integration] - Re: Programmatic configuration of jvmRoute

by bstansberry＠jboss.com

OK, with that approach presumably you could have some logic somewhere that says "if my metadata says I'm using JK, then check for jvmRoute metadata" which defaults to the overall server id. Is having jbossweb completely driven by web container metadata something you're thinking about for AS 5.0.0? If not, then my original question about whether it's OK to add a std jvmRoute attribute to server.xml still stands. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098975#4098975 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098975

18 years, 5 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Thread-Safety problems GeneratedClassAdvisor

by jason.greene＠jboss.com

While glancing at the AOP code for possible explanations of JBAOP-480, I noticed 2 major thread safety issues in GeneratedClassAdvisor: Problem #1 is inadequate locking when using ConcurrentHashMap: | public MethodJoinPointGenerator getJoinPointGenerator(MethodInfo info) | { | MethodJoinPointGenerator generator = (MethodJoinPointGenerator)joinPointGenerators.get(info.getJoinpoint()); | if (generator == null) | { | generator = new MethodJoinPointGenerator(GeneratedClassAdvisor.this, info); | initJoinPointGeneratorsMap(); | joinPointGenerators.put(info.getJoinpoint(), generator); | } | return generator; | } | There is a race between reading a value in a CHM and inserting one. So, in this case there is a strong possibility of multiple/different join-point generator instances being available to different threads. For this reason CHM has a putIfAbsent() method that should be used instead. If a race occurs a unneeded generator my be created, but it won't be seen by other threads, and gc'd soon. Problem#2 - Usage of Double-Checked Locking | protected void initJoinPointGeneratorsMap() | { | if (joinPointGenerators == UnmodifiableEmptyCollections.EMPTY_CONCURRENT_HASHMAP) | { | lockWrite(); | try | { | if (joinPointGenerators == UnmodifiableEmptyCollections.EMPTY_CONCURRENT_HASHMAP) | { | joinPointGenerators = new ConcurrentHashMap(); | } | } | finally | { | unlockWrite(); | } | } | } | This is a known flawed approach to thread safety. http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#dcl This can be fixed by marking the joinPointGenerators map as volatile, or changing it to an AtomicReference. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098971#4098971 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098971

18 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Problems getting WS into ESB

by Kevin.Conner＠jboss.com

I believe the EAP is also based on 4.2.1 at this point in time but Trevor may be able to comment further on this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098961#4098961 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098961

18 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Problems getting WS into ESB

by Kevin.Conner＠jboss.com

ESB is currently based on AS4.2.1 and will be for our 4.2.1 release (in less than one weeks time). A subsequent release will support AS 4.2.2. We are currently using WS2.0.0 in the ESB as 2.0.1 was not backwardly compatible with our code. I believe this may have been fixed in a recent CP release but we cannot use those in the project. I still don't know whether the SP2 release includes this fix or not, you owe me an answer on that one ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098960#4098960 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098960

18 years, 5 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Programmatic configuration of jvmRoute

by scott.stark＠jboss.org

It needs to be part of the container metadata as in general this should be coming from some server/clustered configuration potentially set by the admin tools. A tomcat deployer specific setting is just an override to a higher level server setting. In general we need to forget that xml exists, and define a metadata model that encapsulates all externalized behavior, and then map the sources of that information onto the metadata model. The tomcat deployer is a long way from correctly using such a model due to its internal parsing of its own descriptors like server.xml, conf/web.xml, etc. Its a todo to have jbossweb completely driven by the web container metadata model. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098959#4098959 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098959

18 years, 5 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Programmatic configuration of jvmRoute

by bstansberry＠jboss.com

JBoss Messaging has introduced a requirement that all nodes in a cluster be given a unique id (see http://jira.jboss.com/jira/browse/JBMESSAGING-1121). Since we now have the requirement I'd like to brainstorm a bit about how that id could be used across all cases in the AS where we want to uniquely identify nodes. The obvious one that comes to mind is the Tomcat jvmRoute. For now, let's assume that the JBM unique id is represented by system property "server.peer.id". (Also assume we'll come up a more generic name for the property.) A simple thing to do would be to hard code the following into the std server.xml: <Engine name="jboss.web" defaultHost="localhost" jvmRoute="${server.peer.id:0}> Downside to that is we now dot append the id (or default 0) to every session id, even if we aren't using JK. That's probably no big deal; anyone see a reason why it would be? If it is a problem, perhaps we could leave the jvmRoute attribute out of server.xml and programatically call Engine.setJvmRoute() if the TomcatDeployer's useJK property is set to true. That seems pretty clunky though. Note that JBM requires that the id be a non-negative integer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098951#4098951 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098951

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Microcontainer 2.0.0.Beta5

by scott.stark＠jboss.org

When I try to update to the 2.0.0.Beta5, there are compile problems with the ServiceMetaDataICF: | /home/svn/JBossHead/jboss-head/system-jmx/src/main/org/jboss/system/deployers/managed/ServiceMetaDataICF.java:47: org.jboss.system.deployers.managed.ServiceMetaDataICF is not abstract and does not override abstract method getComponentName(org.jboss.beans.info.spi.BeanInfo,org.jboss.managed.api.ManagedProperty,java.io.Serializable,org.jboss.metatype.api.values.MetaValue) in org.jboss.managed.spi.factory.InstanceClassFactory | public class ServiceMetaDataICF | Ales was working on this so he will have to update the mc version and include his related changes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098930#4098930 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098930

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Microcontainer 2.0.0.Beta5

by scott.stark＠jboss.org

Yes it was released. I thought Ales was updating trunk to use this. If it has not been done I'll do it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098915#4098915 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098915

18 years, 5 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Is any option in JBoss to load web wars on demand

by amitavc

I like to know if there is any way to load web war files to container on demand. Thanks in advance. -Amitav View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098914#4098914 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098914

18 years, 5 months

1
0
0 / 0

[Design of JBossXB] - Re: annotations on properties declared in interfaces

by wolfc

Just what I thought, both problems are related because of generics. This construct breaks the lot: interface MyInterface<X> | { | void setA(X x); | } | | class Something implements MyInterface<SomethingElse> | { | @MyAnnotation | void setA(SomethingElse x) { } | } View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098903#4098903 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098903

18 years, 5 months

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 October 2007