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

[Design of EJB 3.0] - EJB3 Mavenization / Build System Cleanup

by ALRubinger

Encouraged by Bill's recent work getting the EJB3 Core from AS into the ejb3-core Module in Projects, I've done some cleanup of the POMs in there. My goal is to get all common plugins, build configurations, and dependency versions centralized in the EJB3 Build POM, which acts as parent for the other projects. I've updated the version of the parent build to 0.12.0-SNAPSHOT, and it is now properly heading up the builds of all projects except for ejb3-core and sandbox. End result should be ultra-slim POMs for each project, and common versions for each dependency as mandated by the parent. I hope I haven't knocked ejb3-core too out-of-it in the process. This project had been working for Bill, but not building for me for a variety of dependency-related issues. What remains to be done here is: 1) Move all version information into the parent, if not present there already 2) Get the build configuration in-line (ie. src/main/java, not src/main) 3) Resolve the tests (Bill tells me this is more involved) 4) Ensure the dependencies are correct / get compilation going BTW, I'm thrilled to see us moving off the AS and taking charge of an independent release cycle. My one concern is that the dependencies we define for compilation and tests may not be the same versions placed into the various lib folders of AS and will differ for our end-users at runtime. How can we address/avoid this? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114915#4114915 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114915

18 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re

by jason.greene＠jboss.com

"manik.surtani(a)jboss.com" wrote : | about double classloader-specific marshalling. Even if region-based marshalling is off, there will still be double-marshalling, i.e., Pojo -> a byte[] in your MarshalledValue, which is put in the cache. The CacheMarshaller then marshalls your MarshalledValue into a (bigger) byte[] for replication. Or is there something clever in your MarshalledValue class that just passes the byte[] payload in writeExternal()? | This is how it should be done if its not already. anonymous wrote : | True. Maybe just the TCCL approach would work then. | Yes, this is the simplest, cleanest way. anonymous wrote : | "bstansberry(a)jboss.com" wrote : | | I'll need to find my scribbled design notes from when I thought about shared HTTP sessions, but I know that one thing that came out of my thinking was a need to flush the type system by converting everything back to a byte[]. This would be done on a redeploy, where we want to preserve cached data but the types are no longer usable. The MarshalledValue impl I was thinking of would have a method for that. I was assuming the session managment layer would walk the tree, get the marshalled values and invoke the "flush" method on them; if this is instead an internal detail of JBC there would need to be an API (probably on Node) to tell it to do the same thing. | | | | Hmm. Let me think about it, but I can't really see a way for this to happen automatically. It would have to be an API call. | I think this is very useful. I think it needs a better name than flush though. Maybe releaseObjectReferences(fqn) or something like that. anonymous wrote : | "bstansberry(a)jboss.com" wrote : | | 2) For collections, should probably just use it rather than doing something like trying to determine the type of all collection elements. | | 2) Perhaps its a behavior that should be cache-wide configurable. So, if I'm storing a bunch of Sets whose elements are all Strings, I could turn this off. | | Yes, there should always be a way to disable this and allow manual spinning of marshalled values. I'd enable it by default though just to allow for lazy unmarshalling. | I agree, this behavior should be the default. The overhead is minor (temporary double buffer). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114881#4114881 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114881

18 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re

by manik.surtani＠jboss.com

"bstansberry(a)jboss.com" wrote : anonymous wrote : | | AFAIK - and please correct me if I am wrong - Brian, for HTTP sessions, your "cached objects" are MarshalledValue instances that only unmarshall when you do a MarshalledValue.get() as opposed to when the JBC marshaller unmarshalls. | | | | I presume this means we have 2 levels of marshalling/unmarshalling, which could be wasteful. | | By default, region based marshalling is not enabled. You have to enable it if you want to use FIELD (which doesn't use MarshalledValue). But if you enabled it for FIELD and also had non-FIELD apps, yes, you'd have double marshalling. | You're just talking about double classloader-specific marshalling. Even if region-based marshalling is off, there will still be double-marshalling, i.e., Pojo -> a byte[] in your MarshalledValue, which is put in the cache. The CacheMarshaller then marshalls your MarshalledValue into a (bigger) byte[] for replication. Or is there something clever in your MarshalledValue class that just passes the byte[] payload in writeExternal()? "bstansberry(a)jboss.com" wrote : | Plus, having to change the cache config to support FIELD is crappy. | Agreed. "bstansberry(a)jboss.com" wrote : | anonymous wrote : 2. When an object is put in cache (cache.put()) I create a MarshalledValue and store the object as well as the thread's class loader. | | We have to be careful with the classloader ref, as leaking classloaders is a big no-no. It could be stored as a WeakReference, but need to think through how much that buys you versus not storing it at all and just using the TCCL. Particularly since on remote nodes the classloader ref will be null. | | I know in the standard AS use cases the read is always done with the correct TCCL. | True. Maybe just the TCCL approach would work then. "bstansberry(a)jboss.com" wrote : | anonymous wrote : 3. When the object is requested (cache.get()) I inspect the object and if it is a MarshalledValue, I return the object. If the object is not present, I deserialize the byte stream, first with the associated class loader, and if one is not present, the calling thread's class loader. | | ... and throw away the ref to the byte[] -- i.e. no double memory usage. | Yes, definitely. Only one would exist at any time - the object ref or the byte array; never both. "bstansberry(a)jboss.com" wrote : | I'll need to find my scribbled design notes from when I thought about shared HTTP sessions, but I know that one thing that came out of my thinking was a need to flush the type system by converting everything back to a byte[]. This would be done on a redeploy, where we want to preserve cached data but the types are no longer usable. The MarshalledValue impl I was thinking of would have a method for that. I was assuming the session managment layer would walk the tree, get the marshalled values and invoke the "flush" method on them; if this is instead an internal detail of JBC there would need to be an API (probably on Node) to tell it to do the same thing. | Hmm. Let me think about it, but I can't really see a way for this to happen automatically. It would have to be an API call. "bstansberry(a)jboss.com" wrote : | 1) Shouldn't use the MarshalledValue for primitive types. | Or any other JDK objects - Dates, etc. "bstansberry(a)jboss.com" wrote : | 2) For collections, should probably just use it rather than doing something like trying to determine the type of all collection elements. | 2) Perhaps its a behavior that should be cache-wide configurable. So, if I'm storing a bunch of Sets whose elements are all Strings, I could turn this off. Yes, there should always be a way to disable this and allow manual spinning of marshalled values. I'd enable it by default though just to allow for lazy unmarshalling. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114867#4114867 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114867

18 years, 3 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Thread safety and rollback

by mark.little＠jboss.com

Participants (two phase and synchronizations) may get called multiple times in the event of certain types of failures (e.g., the tm sends a prepare, doesn't get a response and so sends it again) so they should expect this kind of behaviour. But in this case it isn't a failure, it's a bug ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114842#4114842 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114842

18 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re

by bstansberry＠jboss.com

anonymous wrote : | AFAIK - and please correct me if I am wrong - Brian, for HTTP sessions, your "cached objects" are MarshalledValue instances that only unmarshall when you do a MarshalledValue.get() as opposed to when the JBC marshaller unmarshalls. | | I presume this means we have 2 levels of marshalling/unmarshalling, which could be wasteful. By default, region based marshalling is not enabled. You have to enable it if you want to use FIELD (which doesn't use MarshalledValue). But if you enabled it for FIELD and also had non-FIELD apps, yes, you'd have double marshalling. Plus, having to change the cache config to support FIELD is crappy. anonymous wrote : 2. When an object is put in cache (cache.put()) I create a MarshalledValue and store the object as well as the thread's class loader. We have to be careful with the classloader ref, as leaking classloaders is a big no-no. It could be stored as a WeakReference, but need to think through how much that buys you versus not storing it at all and just using the TCCL. Particularly since on remote nodes the classloader ref will be null. I know in the standard AS use cases the read is always done with the correct TCCL. anonymous wrote : 3. When the object is requested (cache.get()) I inspect the object and if it is a MarshalledValue, I return the object. If the object is not present, I deserialize the byte stream, first with the associated class loader, and if one is not present, the calling thread's class loader. ... and throw away the ref to the byte[] -- i.e. no double memory usage. I'll need to find my scribbled design notes from when I thought about shared HTTP sessions, but I know that one thing that came out of my thinking was a need to flush the type system by converting everything back to a byte[]. This would be done on a redeploy, where we want to preserve cached data but the types are no longer usable. The MarshalledValue impl I was thinking of would have a method for that. I was assuming the session managment layer would walk the tree, get the marshalled values and invoke the "flush" method on them; if this is instead an internal detail of JBC there would need to be an API (probably on Node) to tell it to do the same thing. Other random thoughts... 1) Shouldn't use the MarshalledValue for primitive types. 2) For collections, should probably just use it rather than doing something like trying to determine the type of all collection elements. 2) Perhaps its a behavior that should be cache-wide configurable. So, if I'm storing a bunch of Sets whose elements are all Strings, I could turn this off. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114774#4114774 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114774

18 years, 3 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Make VirtualHosts use different SecurityDomains

by acoliver＠jboss.org

bah brain turned off different security DOMAINs per virtual host. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114753#4114753 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114753

18 years, 3 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Make VirtualHosts use different SecurityDomains

by acoliver＠jboss.org

shit...that dropped the formatting rather nicely. The idea is that security association is per virtual host with a default. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114752#4114752 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114752

18 years, 3 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Make VirtualHosts use different SecurityDomains

by acoliver＠jboss.org

At present jboss-web takes one security-domain and potentially many virtual-host configurations such that one webapp is deployed to many virtual hosts with the same security domain. For websites with multiple regions, it often makes sense to use DIFFERENT security domains for each virtual host. Today we can have only jboss-web security-association virtual-host Ideally we could have jboss-web virtual-host security-association virtual-host security-association Or: jboss-web security-association virtual-host security-association virtual-host security-association where the virtual host security-associations would override the parent. In tomcat/src/main/org/jboss/web/tomcat/service/TomcatDeployer.xml the performDeployInternal happens ALREADY for each hostname. At present it uses ONE SecurityAssociationValve for all virtual hosts and the securityassociationvalve is configured with the metaData.getSecurityDomain(). This could instead be a seperate SecurityAssociationValve for each host with the securitydomain as an argument (used to flush the authentication cache). Elsewhere, the ENC/security/security-domain is used. This instead could be the ENC/security/vhost/security-domain or securityMgr (they ultimately are the same thing in server/src/main/org/jboss/web/AbstractWebDeployer). The trickiest piece isn't the server code, this would require some refactoring but doing the descriptor in an adequate but backward compatible way. <virtual-host>hostname</virtual-host> becomes <virtual-host>xxx</virtual-host><security-domain>domain</security-domain> or something like that. Ideally it would be <virtual-host>xxx<security-domain>xxx</security-domain></virtual-host> for clarity. Thoughts? (Sh/C)ould this be done? Accepted if done by someone else? If so could it make the 4.2 branch or possibly somewhere in 5 + 4.2 backport? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114751#4114751 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114751

18 years, 3 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Thread safety and rollback

by adrian＠jboss.org

I know this is "invalid usage", but it still shouldn't lead to broken behaviour. :-) See the test in jboss-4.2 | $ ./build.sh one-test -Dtest=org.jboss.test.tm.test.CompetingRollbackStressTestCase | This is stress test for a race condition (two threads invoking rollback "at the same time"). I'm seeing the transaction synchronizations getting invoked twice. | <testcase classname="org.jboss.test.tm.test.CompetingRollbackStressTestCase" name="testExecuteSQLDuringRollback" time="7.132"> | <error message="Synchronization invoked 2 times" type="org.jboss.test.util.ejb.RemoteTestException">java.lang.RuntimeException: Synchronization invoked 2 times | at org.jboss.test.tm.test.CompetingRollbackStressTestCase$Main.test(CompetingRollbackStressTestCase.java:136) | at org.jboss.test.tm.test.CompetingRollbackStressTestCase$TestRunnable.run(CompetingRollbackStressTestCase.java:193) | at java.lang.Thread.run(Thread.java:595) | NOTE: This is a stress test, so you'll probably have to make it do lots of iterations to reproduce the problem. e.g. start jboss with | $ ./run.sh -Djbosstest.iterationcount=10000 | and maybe run it a few times? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114750#4114750 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114750

18 years, 3 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Deploying maven built artifacts to the ant repository.

by pgier

Oops, I forgot to escape my tags. You can use <artifactId>new-name</artifactId> View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114721#4114721 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114721

18 years, 3 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 December 2007