March 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBossCache] - Re: JBCACHE-1170

by manik.surtani＠jboss.com

Ah, I see it - a stale TL on a sender thread, and the sender thread is then reused to transfer state and since it isn't an RPC call, the stale TL isn't overwritten. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137882#4137882 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137882

18 years

1
0
0 / 0

[Design of JBossCache] - Re: JBCACHE-1170

by manik.surtani＠jboss.com

Hmm, thinking about this a bit, and referring to your comments on the JIRA issue raised: "bstansberry(a)jboss.com" wrote : | 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Wrote version 20 | 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Region based call. Using region /JSESSION/localhost/http-field | 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Marshalling object true | 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Writing region /JSESSION/localhost/http-field to stream | 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.statetransfer.StateTransferManager] locking the /JSESSION/localhost/http-scoped subtree to return the in-memory (transient) state | | The second line shows the problem -- "/JSESSION/localhost/http-field" is written to the stream; it should be "/JSESSION/localhost/http-scoped", or perhaps nothing at all. | I'm guessing this is being written on the sender's side? So, this means: 1) The ThreadLocal value being leaked on the receiver is irrelevant, as this will always be overwritten when the next communication comes in. 2) The ThreadLocal on the sender is irrelevant as well, since this only becomes a problem if the sender attempts to reuse a thread and the next call is a return value. (if not, the ThreadLocal will just get overwritten again). So, the only real problem is if the ThreadLocal leaks (and this seems to happen with async replication as per the JGroups code above), and a sending thread is then reused as a receiving thread. Now AFAIK, JGroups maintains separate thread pools for sending and receiving, so the above should never happen. Does the above accurately describe the issue you're seeing, though? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137880#4137880 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137880

18 years

1
0
0 / 0

[Design of POJO Server] - Re: Fixing the WarClassLoaderDeployer

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : The current way the WarClassLoaderDeployer works is all over the place. :-) | | INCLUDE WEB-INF | | I thought the requirement was to include the root of the war | since that is what the old UCL did? | Anyway this should be in the structure deployer not the classloader deployer. | No, this is the workaround for webservices packaging expectations of being able to load resources from the WEB-INF dir. Should be in WARStructure, but its isolated to the jbossas codebase for now. "adrian(a)jboss.org" wrote : | COPYING TO TEMP | | Again this should be in the structure deployer. The VirtualFiles is adds | should be the temp ones. | this should not be needed. "adrian(a)jboss.org" wrote : | ALT-DD | | This doesn't look like it is handled properly in the new deployers? | Shouldn't this be handled in the metadata parsing? | Yes, we are not handling this. Its a bit awkward as you would first have to scan the base descriptor for the alt path and then parse that file. Doesn't neatly fit into the current metadata parsing abstractions. These issues are spread across the various war deployers, not just the WarClassLoaderDeployer. You wrote "is all of the place", but meant is all over the place. The war deployers and tomcat embedding code still await a major overhaul. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137874#4137874 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137874

18 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Jbpm pageflow

by koen.aers＠jboss.com

The 'incomplete alpha' one is the plugin that will be used in the future. I am not sure what you mean by it being incomplete but I would definitely appreciate your help in making it more complete or downright better :-) So, it would be good if you check out the plugins on head. We can have a discussion here on the lacking elements and how to add them. Regards, Koen View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137873#4137873 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137873

18 years

1
0
0 / 0

[Design of POJO Server] - Re: Fixing the WarClassLoaderDeployer

by scott.stark＠jboss.org

No, that is the Ejb3Deployer.scanWars that controlls that behavior. acceptNonWarDirs is obsolete in the new deployers as the war structure is based on the existence of a WEB-INF/web.xml regardless of whether the parent has a .war. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137871#4137871 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137871

18 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: TransactionTimeoutConfiguration pluggability

by mark.little＠jboss.com

OTS? Did someone mention OTS? -1 is wrong. 0 was "no application specific timeout has been defined". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137868#4137868 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137868

18 years

1
0
0 / 0

[Design of POJO Server] - Re: Fixing the WarClassLoaderDeployer

by wolfc

"adrian(a)jboss.org" wrote : INCLUDE WEB-INF | | I thought the requirement was to include the root of the war | since that is what the old UCL did? | Anyway this should be in the structure deployer not the classloader deployer. | Same goes for some of the other flags, is "acceptNonWarDirs" still used? This sounds like something I requested. Any class that is in the root of a war should not be considered as an EJB 3 bean candidate. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137865#4137865 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137865

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Shared Parent POM for dependencyManagement

by adrian＠jboss.org

"ALRubinger" wrote : | We can introduce some ranges and see what kind of results we have...technically this is a supported feature. | It needs testing. Somebody needs to run some test projects through a few releases (including snapshots) to validate the behaviour is correct; * specific versions pom tagged in svn * ranges in the repository If it is not correct in some cases we learn what to avoid or how to work around the problems. If I had more time, I'd do it myself, for now I'm just using mvn dependency:tree to check poms are behaving as expected when I create releases and fixing it with exclusions if they are not. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137858#4137858 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137858

18 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: TransactionTimeoutConfiguration pluggability

by adrian＠jboss.org

"jhalliday" wrote : Quite. Rather begs the question, why does getTransactionTimeout throw it for any error? How about the case where there is no default timeout set? Is that an error and if not, what's the expected return value. -1 == not specified/unknown But that's really for the case where you specify that the error should be ignored. That usage only existed in the old TM to support the OTS Current.get_timeout() and even there I didn't think it looked correct, but I'm not a big OTS expert. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137855#4137855 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137855

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Shared Parent POM for dependencyManagement

by ALRubinger

"adrian(a)jboss.org" wrote : Is that confirmation that it doesn't understand 1.0.1 > 1.0.0 like I said above. Or is that just his preference. No, Maven will understand version order (we covered this elsewhere in the conversation; check the full transcript). This is his preference, likely based on some prior experience (conjecture). "adrian(a)jboss.org" wrote : There's no way we can fix dependencies at single version given the number of projects/releases we have. We can introduce some ranges and see what kind of results we have...technically this is a supported feature. Any better ideas? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137854#4137854 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137854

18 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-dev-forums March 2008