[JBoss-dev] xdoclet/lib not found building 4.0.4 source...

2006-01-04 Thread Scott Marlow
I have seen this build error in the past but have usually hacked past it
somehow.  

I took new 4.0.x source this afternoon and can't seem to get past this
build error:

 BUILD FAILED
 /disk2/src/jboss_jan/jboss-4.0/jmx/build.xml:152: 
/disk2/src/jboss_jan/jboss-4.0/thirdparty/xdoclet/lib not found.


Not that it should matter, I'm using Novell Linux Desktop (based on Suse
Linux) and have tried Java 1.5 + 1.4.

I'll probably remember soon how to hack around the problem again.  Does
anyone else see this issue?

I double checked the build instructions on
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossBuild and didn't see
anything about this there.

Scott



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] xdoclet/lib not found building 4.0.4 source...

2006-01-04 Thread Scott Marlow
That did it for me, I was checking the branch into a local folder named
jboss-4.0, issuing "cvs co -r Branch_4_0 jboss-4.0.x", did the trick.

Thank you,
Scott
>   

On Wed, 2006-01-04 at 17:44 -0600, Ruel Loehr wrote:
> I pulled the source and built without any issues.
> 
> Please verify that you have used the following checkout commands:
> 
> Cvs co -r Branch_4_0 jboss-4.0.x
> 
> Note that the module name is jboss-4.0.x and not jboss-4.0.   
> 
> 
> Ruel Loehr
> JBoss QA
>  
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Scott Marlow
> Sent: Wednesday, January 04, 2006 5:29 PM
> To: jboss-development@lists.sourceforge.net
> Subject: [JBoss-dev] xdoclet/lib not found building 4.0.4 source...
> 
> I have seen this build error in the past but have usually hacked past it
> somehow.  
> 
> I took new 4.0.x source this afternoon and can't seem to get past this
> build error:
> 
>  BUILD FAILED
>  /disk2/src/jboss_jan/jboss-4.0/jmx/build.xml:152:
> /disk2/src/jboss_jan/jboss-4.0/thirdparty/xdoclet/lib not found.
> 
> 
> Not that it should matter, I'm using Novell Linux Desktop (based on Suse
> Linux) and have tried Java 1.5 + 1.4.
> 
> I'll probably remember soon how to hack around the problem again.  Does
> anyone else see this issue?
> 
> I double checked the build instructions on
> http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossBuild and didn't see
> anything about this there.
> 
> Scott
> 
> 
> 
> ---
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> ___
> JBoss-Development mailing list
> JBoss-Development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 
> 
> ---
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> ___
> JBoss-Development mailing list
> JBoss-Development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] New wiki page on writing thread safe code...

2006-02-23 Thread Scott Marlow
http://wiki.jboss.org/wiki/Wiki.jsp?page=ThreadSafeCode is a new page
containing guidelines, common terms, anti-patterns related to writing
thread safe code.

This will also serve as a common page to put a stake in the ground on
writing thread safe code, although advanced techniques are purposely
left out (Doug Lea's book is still the best reference or reading
jboss.org.* code.) :)

I promised to do this in a private email thread (we are moving the
private discussion to the forums).

Let me know if anything is not clear on the wiki page.

Scott



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] Unassigned for 4.0.4

2006-04-03 Thread Scott Marlow
Does anyone reading this understand how "JBAS-2868 Missing jar
ehcache-1.1.jar for Hibernate support" should be fixed?

It is only of the few unassigned issues left.  I'm wondering if
Hibernate could use JBossCache for the level one cache instead of
ehCache (easy hibernate cache).  This might be a nice alternative to
adding the ehCache jar to the 4.0.4 as release.

On Mon, 2006-04-03 at 15:25 -0500, Dimitris Andreadis wrote:
> Works for me! 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] 
> > [mailto:[EMAIL PROTECTED] On 
> > Behalf Of Adrian Brock
> > Sent: 03 April, 2006 22:51
> > To: jboss-development@lists.sourceforge.net
> > Subject: RE: [JBoss-dev] Unassigned for 4.0.4
> > 
> > Try again.
> > 
> > On Mon, 2006-04-03 at 14:31 -0500, Ryan Campbell wrote:
> > > Adrian, it doesn't look like this filter is public.
> > > 
> > > Errors
> > > 
> > > * Could not getRequest search with this id.
> > > 
> > > 
> > > 
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of 
> > > Adrian Brock
> > > Sent: Monday, April 03, 2006 2:26 PM
> > > To: jboss-development
> > > Subject: [JBoss-dev] Unassigned for 4.0.4
> > > 
> > > There are still 19 tasks unassigned for 4.0.4 
> > > 
> > http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hide&reques
> > > tI
> > > d=12310482
> > > 
> > > We should get these assigned or deferred, so there isn't a mad rush 
> > > come release time. :-)
> > --
> > 
> > Adrian Brock
> > Chief Scientist
> > JBoss Inc.
> > 
> > 
> > 
> > 
> > ---
> > This SF.Net email is sponsored by xPML, a groundbreaking 
> > scripting language
> > that extends applications into web and mobile media. Attend 
> > the live webcast
> > and join the prime developer group breaking into this new 
> > coding territory!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&;
> dat=121642
> > ___
> > JBoss-Development mailing list
> > JBoss-Development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> > 
> 
> 
> ---
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> ___
> JBoss-Development mailing list
> JBoss-Development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] Unassigned for 4.0.4

2006-04-04 Thread Scott Marlow
Sounds good to me.  My next question is how do we tell Hibernate to use
JBoss Cache as the first level cache?

On Mon, 2006-04-03 at 17:13 -0500, Scott M Stark wrote:
> Yes, we should be defaulting to a single node, unclustered jboss cache
> rather than having to supply yet another thirdparty jar to handle the
> baseline cache. 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] 
> > [mailto:[EMAIL PROTECTED] On 
> > Behalf Of Scott Marlow
> > Sent: Monday, April 03, 2006 2:05 PM
> > To: jboss-development@lists.sourceforge.net
> > Subject: RE: [JBoss-dev] Unassigned for 4.0.4
> > 
> > Does anyone reading this understand how "JBAS-2868 Missing 
> > jar ehcache-1.1.jar for Hibernate support" should be fixed?
> > 
> > It is only of the few unassigned issues left.  I'm wondering 
> > if Hibernate could use JBossCache for the level one cache 
> > instead of ehCache (easy hibernate cache).  This might be a 
> > nice alternative to adding the ehCache jar to the 4.0.4 as release.
> > 
> 
> 
> ---
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> ___
> JBoss-Development mailing list
> JBoss-Development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] Unassigned for 4.0.4

2006-04-04 Thread Scott Marlow
On Tue, 2006-04-04 at 15:56 +0200, Max Rydahl Andersen wrote:
> On Tue, 04 Apr 2006 15:44:51 +0200, Scott Marlow  
> <[EMAIL PROTECTED]> wrote:
> 
> > Sounds good to me.  My next question is how do we tell Hibernate to use
> > JBoss Cache as the first level cache?
> 
> *first* level cache ? Why would you ever want that ?
> 
> You mean second level cache, right ?
I mean first level cache, which by default is using ehcache-1.1.jar (jira 
JBAS-2868).  We don't include ehcache-1.1.jar with the 4.0.4 as release which 
is why it cannot be resolved.  I would like to use jboss cache instead as the 
first level cache but am not sure if Hibernate allows that.





---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] JBossCache 1.3.0.GA released + a change to how we deal with java.util.properties

2006-04-06 Thread Scott Marlow
It turns out that the root cause behind JBCACHE-531 is deeper than I
thought.

After fixing a minor international character support issue in
org.jboss.cache.config.CacheLoaderConfig (we were calling
String.getBytes() without specifying an encoding).  I then came across
the same issue in
org.jboss.util.propertyeditor.PropertiesEditor.getValue().  I fixed the
character encoding issue locally but I'm not sure of how to fix the
deeper issue.  

Before I move into the deeper issue, let me explain the problem with
calling String.getBytes() without specifying an encoding (before someone
flames me :).  String.getBytes() will return a byte array containing the
character values converted into the default platform encoding (perhaps
big5 or utf8 or perhaps latin1).  In the two code sites mentioned above,
we are passing the byte array into java.util.properties which always
wants encoding "ISO8859_1".

The deeper issue:

org.jboss.util.propertyeditor.PropertiesEditor.getValue() is expected to
take a Java String value and parse it java.util.properties style.
However, we also support expanding JBoss system expressions that can be
invalid when passed into java.util.properties.load() as we do.  

For example, if the expression "${jboss.server.data.dir}" is passed in
and you are running on Windows, the intermediate result might be path
"c:\jboss\server\all\data".  The output of java.util.properties.load
will be something like: "c: boss erver ll ata".  

This creates a blocking problem for our sfsb fine grained replication
project. :(

Should we try to hack the expansion of jboss system expressions to
double escape the "\" escape character?  

This seems like a tricky path to follow as I'm not sure if we should do
the same for values that are simply passed in.  For instance, are users
expected to hard code paths in configuration files like this?

  mytempdir=c:\temp

or like this:

  mytempdir=c:\\temp

In one case, they already hit the bug that requires "\" to be doubled.
If I add code that doubles their "\", then we might end up with
something like "mytempdir=c:temp"  (assuming that they already
doubled them).  I suppose we could detect if the "\" characters are
already escaped and don't escape them again if so.  

This also seems like a big change to make so near the end of the 4.0.4
release.  I'll create a Jira for 4.0.4 unless someone talks me out of
making this change. 

What is the right thing to do here?


On Thu, 2006-04-06 at 06:36 -0500, Ben Wang wrote:
> Yes, it has. The other two are almost done. Scott Marlow and I need to
> verify JBCACHE-531 fix. I'd say let's go for QA next Monday then?
>  
> -Ben



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] JBossCache 1.3.0.SP1 (WAS: JBossCache 1.3.0.GA released)

2006-04-06 Thread Scott Marlow
Sure, is the following command correct for accessing it:

cvs  co -r Branch_JBossCache_1_3_0 JBossCache

Thanks,
Scott

On Thu, 2006-04-06 at 19:02 +0100, Manik Surtani wrote:
> Ok, so I have created a branch - 
> 
> 
> Branch_JBossCache_1_3_0
> 
> 
> Could we make sure any potential fixes for an SP release go here as
> well as in HEAD.
> 
> 
> From what I can tell, we have:
> 
> 
> * Ben's SFSB fixes
> * The fix to the examples build script
> * Potential problem with the TreeCache GUI
> * JBCACHE-531 (Forcing file encodings when reading properties)
> * JBCACHE-548 (to do with TxManagers in WebLogic and WebSphere)
> * JBCACHE-534 (documentation typo)
> 
> 
> What else is critical for this SP?  Do we have JIRA tasks for the
> first 3?
> 
> 
> Cheers,
> --
> Manik Surtani
> [EMAIL PROTECTED]
> 
> 
> Lead, JBoss Cache
> 
> 
> Telephone: +44 7786 702 706
> MSN: [EMAIL PROTECTED]
> Yahoo: maniksurtani
> AIM: maniksurtani
> Skype: maniksurtani
> 
> 
> 
> On 6 Apr 2006, at 15:55, Ben Wang wrote:
> 
> > What tutorial? It is not broken, AFAIK.
> > 
> > 
> > 
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> > Manik Surtani
> > Sent: Thursday, April 06, 2006 8:16 PM
> > To: jboss-development@lists.sourceforge.net
> > Subject: Re: [JBoss-dev] JBossCache 1.3.0.GA released
> > 
> > 
> > Ok.  Has the tutorial been fixed as well?   
> > --
> > Manik Surtani
> > [EMAIL PROTECTED]
> > 
> > 
> > Lead, JBoss Cache
> > 
> > 
> > Telephone: +44 7786 702 706
> > MSN: [EMAIL PROTECTED]
> > Yahoo: maniksurtani
> > AIM: maniksurtani
> > Skype: maniksurtani
> > 
> > 
> > 
> > On 6 Apr 2006, at 12:36, Ben Wang wrote:
> > 
> > > Yes, it has. The other two are almost done. Scott Marlow and I
> > > need to verify JBCACHE-531 fix. I'd say let's go for QA next
> > > Monday then?
> > >  
> > > -Ben
> > > 
> > > 
> > > __
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf
> > > Of Manik Surtani
> > > Sent: Thursday, April 06, 2006 5:51 PM
> > > To: jboss-development@lists.sourceforge.net
> > > Subject: Re: [JBoss-dev] JBossCache 1.3.0.GA released
> > > 
> > > 
> > > This is a better case.  The tutorial issue on its own was not
> > > strong enough, IMO.  :) 
> > > 
> > > 
> > > Ben, is this fixed in HEAD at  the moment?
> > > 
> > > 
> > > Cheers,
> > > --
> > > Manik Surtani
> > > [EMAIL PROTECTED]
> > > 
> > > 
> > > Lead, JBoss Cache
> > > 
> > > 
> > > Telephone: +44 7786 702 706
> > > MSN: [EMAIL PROTECTED]
> > > Yahoo: maniksurtani
> > > AIM: maniksurtani
> > > Skype: maniksurtani
> > > 
> > > 
> > > 
> > > On 5 Apr 2006, at 21:55, Ryan Campbell wrote:
> > > 
> > > > Is this (and the tutorial issue) not a good reason for
> > > > 1.3.1.CR1? 
> > > > 
> > > > And then 1 week later, once we have a bug free release, we just
> > > > rename (and retag it) as 1.3.1.GA.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > From: Ben Wang 
> > > > Sent: Tuesday, April 04, 2006 8:42 PM
> > > > To: jboss-development@lists.sourceforge.net
> > > > Cc: QA
> > > > Subject: RE: [JBoss-dev] JBossCache 1.3.0.GA released
> > > > 
> > > > 
> > > > I know this not good timing. :-) But during my work on migrating
> > > > ejb3 sfsb passivation using JBossCache
> > > > (http://jira.jboss.com/jira/browse/EJBTHREE-500), I have
> > > > discovered two bugs. And I will need these two fixed so I can
> > > > check in my code in head. So first option is to create a patch
> > > > and use that. Second option is use the snapshot in JBossCache
> > > > and couting on that 1.4 release will be out soon.
> > > > 
> > > > I am leaning towards the second option such that if there is any
> > > > future bug fixes or enahncement then I can create another
> > > > shapshot right away. What do peop

RE: [JBoss-dev] Unassigned for 4.0.4

2006-04-07 Thread Scott Marlow
Thanks to everyone that responded.  I understand now.

On Fri, 2006-04-07 at 08:07 -0500, Steve Ebersole wrote:
> Just so it is perfectly clear:
> 
> Hibernate does not use its cache providers in any way, shape or form for
> implementing the "first level cache".  As Max mentioned, the "first
> level cache" is really just a particular aspect of the role fulfilled by
> the org.hibernate.engine.PersistenceContext implementation which
> internally uses a series of maps.
> 
> Thus, no need to bundle ehcache at all unless a user wants to use that
> as their second level cache.
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Scott Marlow
> Sent: Tuesday, April 04, 2006 10:12 AM
> To: jboss-development@lists.sourceforge.net
> Subject: Re: [JBoss-dev] Unassigned for 4.0.4
> 
> On Tue, 2006-04-04 at 15:56 +0200, Max Rydahl Andersen wrote:
> > On Tue, 04 Apr 2006 15:44:51 +0200, Scott Marlow  
> > <[EMAIL PROTECTED]> wrote:
> > 
> > > Sounds good to me.  My next question is how do we tell Hibernate to
> use
> > > JBoss Cache as the first level cache?
> > 
> > *first* level cache ? Why would you ever want that ?
> > 
> > You mean second level cache, right ?
> I mean first level cache, which by default is using ehcache-1.1.jar
> (jira JBAS-2868).  We don't include ehcache-1.1.jar with the 4.0.4 as
> release which is why it cannot be resolved.  I would like to use jboss
> cache instead as the first level cache but am not sure if Hibernate
> allows that.
> 
> 
> 
> 
> 
> ---
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> ___
> JBoss-Development mailing list
> JBoss-Development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 
> 
> ---
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> ___
> JBoss-Development mailing list
> JBoss-Development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] synchronization on non-final fields warning

2006-04-20 Thread Scott Marlow
The problem in the JaasSecurityManager class example below is that the
domainCache variable itself needs to be protected with synchronization
since its non-final (for all domainCache read/write operations.)

It is not fine as one thread could be performing updateCache(Principal),
meanwhile, another thread assigns a new value to domainCache.  The
thread performing updateCache, wouldn't have a consistent memory view of
the new domainCache and also violates atomicity. 

On Tue, 2006-04-11 at 23:51 -0500, Scott M Stark wrote:
> I'm trying to understand the full implication of the intellij
> synchronization on non-final fields warning, which has this description:
> 
> This inspection reports instances of synchronized statements where the
> lock expression is a non-final field. Such statements are unlikely to
> have useful semantics, as different threads may be locking on different
> objects even when operating on the same object.
> 
> An example usage is the following where a multiple operations on the
> domainCache variable is done in a synchronized block so that the
> remove/insert are atomic:
> 
> public class JaasSecurityManager
> { 
>private CachePolicy domainCache;
> 
>private Subject updateCache(Principal principal)
>{
>   synchronized( domainCache )
>   {
>  if( domainCache.peek(principal) != null )
> domainCache.remove(principal);
>  domainCache.insert(principal, info);
>   }
>}
> }
> 
> In going over the current memory model docs:
> http://www.cs.umd.edu/~pugh/java/memoryModel/
> http://gee.cs.oswego.edu/dl/jmm/cookbook.html
> http://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf
> 
> The only context I can see where this warning applies is if the
> domainCache variable is being changed. In that case two threads may
> actually be synchronizing/working on different objects, but that is fine
> in this case as the atomic block of ops only applies to the domainCache
> object. If other state was being referenced I can see a problem, but not
> for the illustrated usage.
> 
> Am I missing something here?
> 
> 
> Scott Stark
> VP Architecture & Technology
> JBoss Inc.
>  
>  
> 
> 
> ---
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> ___
> JBoss-Development mailing list
> JBoss-Development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jboss-development



---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development