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

[Design of JBoss Collaboration Server] - Re: SVN source

by acoliver＠jboss.org

I sent you a private email with instructions on how to get a more recent version. The M5 version is not in SVN, it is in CVS. M5-pre1 was on a different branch ( we did that every release ). If the other committers and I get everything we want to get done this weekend then I'll have public info on Monday. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992407#3992407 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992407

19 years, 4 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - Re: SVN source

by johanwasserman

I urgently need at least 1.0 Milestone 5-pre1 to compile into an ear / war, and deploy on my current server View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992400#3992400 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992400

19 years, 4 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - SVN source

by johanwasserman

Where can I find the source? Using Tortoise to https://svn.jboss.org and I cannot find anything, please specify the path. I see it's also been disabled from FishEye View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992397#3992397 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992397

19 years, 4 months

1
0
0 / 0

[Design of Security on JBoss] - Concurrency bug in JaasSecurityManager

by Cyberax

This is a cross-post from user forum (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=95622). I've found a VERY curious concurrency bug in JaasSecurityManager. I'm using custom login modules and custom principal and a custom SecurityInterceptor for JNDI lookups, this interceptor checks . My DefaultCacheTimeout value was set to 0 (I wanted to turn off authentication cache). My application (remote Swing client) worked fine as long as there was only one thread doing JNDI lookups. But sometimes a second application threw exception during JNDI authorization , it turned out that authenticated Subject had an empty role set. But this is impossible, because my Subjects always have at least one role. After few hours of debugging I've found the problem: my custom login module removes its Subject roles during the logout() method. I've found that this module is called by JaasSecurityManager$DomainInfo.destroy. And that's a bug. Suppose we have two threads: Code: | Thread 1: Thread 2 (some time after Thread1): | 1. 'User1' authentication 1. 'User1' logs in. | 2. 'User1' is added to auth cache 2. Auth cache entry has expired. | 3. Doing some lengthy operation 3. Calling .logout() on stale entry | 4. Checking roles of User1 - WILL FAIL, another thread has called logout()! | This problem may be not evident with the stock JBoss login modules, because their logout() methods do not remove subject's roles. Proposed fixes: 1. Use deep cloning. That way threads 1 and 2 doesn't share any data, thus no problem. 2. Use acquire/release semantics in conjunction with SecurityAssociation. 3. Remove logout() from DomainInfo.destroy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992393#3992393 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992393

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService kickoff

by weston.price＠jboss.com

Cool. I just wanted to walk through how I see it working. Sounds like we are all on the same page. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992392#3992392 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992392

19 years, 4 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Exception propagation using HTTP servlet transport on 1.4.4

by Cyberax

There's a bug in ServletServerInvoker in 1.4.4 version of remoting. 'processRequest' methods do not support propagation of exceptions to remote clients. This code: | try | { | // call transport on the subclass, get the result to handback | invocationResponse = invoke(invocationRequest); | } | catch(Throwable ex) | { | log.debug("Error thrown calling invoke on server invoker.", ex); | invocationResponse = ex; | isError = true; | } | | //Start with response code of 204 (no content), then if is a return from handler, change to 200 (ok) | int status = 204; | if(invocationResponse != null) | { | if(isError) | { | response.sendError(500, "Error occurred processing invocation request. "); | } | else | { | status = 200; | } | } | sends "500 Server Error" message in response body to client. Client then tries to unmarshal this message using ObjectInputStream and fails. The simple fix is: | try | { | // call transport on the subclass, get the result to handback | invocationResponse = invoke(invocationRequest); | } | catch(Throwable ex) | { | log.debug("Error thrown calling invoke on server invoker.", ex); | invocationResponse = ex; | | String sessionId=null; | if (invocationRequest instanceof InvocationRequest) | sessionId=((InvocationRequest)invocationRequest).getSessionId(); | invocationResponse=new InvocationResponse(sessionId,ex,true,null); | //isError = true; | } | It seems to be working for me. Should I create JIRA bug for this issue? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992391#3992391 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992391

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService kickoff

by scott.stark＠jboss.org

"weston.price(a)jboss.com" wrote : | The 'mapping' issue we talked about now comes into play.The underlying metadata (EAR, WAR, RAR) is effectlively much different than the management meta data that the ProfileService understands. How does the subset (management) infrastructure create/read/update/delete against the superset (actual metadata). | This is the magic Adrian is working on. Until we see that I don't know the details. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992381#3992381 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992381

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService kickoff

by scott.stark＠jboss.org

"weston.price(a)jboss.com" wrote : | From a root deployment (initial deployment) the profile service has to know about what gets deployed and the metadata that gets generated as result, or at the very least, it's Management DD. It does this via the deployment chain as you talked about. The results of the initial deployment are persisted to the repository. Diffs can begin at this point, effectively the deployment is versioned. | | I think I was hung up more on the 'who starts the chain' more than I was what happens as a result. | | So, based on this design, there is no concept of a JBoss instance existing without a ProfileService, they are effectively one and the same in terms of the 'client view'. The ProfileService really takes over what the old JMX system used to provide but with a ton of more features (versioning, dynamic lifecycle including a STOP, etc). | | Let me know if I am on the right track. | The profile service plugs into the long standing ServerImpl bootstrap mechanism, so to some extent its replacable. With the update to all of the deployers, there is an extended contract on how deployments are brought into the server that obsoletes the old scanners, but they could be ported over in place of the profile service. Certainly all of the new features we are working on now are quality of service issues that can be disabled and you still have a functional server. We do want a full featured profile service as the default replacement for the old jmx deployment mechanism, so yes, there is no interesting jboss server without a profile service. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992380#3992380 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992380

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService kickoff

by weston.price＠jboss.com

Yes, now I see. The 'mapping' issue we talked about now comes into play.The underlying metadata (EAR, WAR, RAR) is effectlively much different than the management meta data that the ProfileService understands. How does the subset (management) infrastructure create/read/update/delete against the superset (actual metadata). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992373#3992373 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992373

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService kickoff

by weston.price＠jboss.com

OK, I think I have a better grasp on this now. >From a root deployment (initial deployment) the profile service has to know about what gets deployed and the metadata that gets generated as result, or at the very least, it's Management DD. It does this via the deployment chain as you talked about. The results of the initial deployment are persisted to the repository. Diffs can begin at this point, effectively the deployment is versioned. I think I was hung up more on the 'who starts the chain' more than I was what happens as a result. So, based on this design, there is no concept of a JBoss instance existing without a ProfileService, they are effectively one and the same in terms of the 'client view'. The ProfileService really takes over what the old JMX system used to provide but with a ton of more features (versioning, dynamic lifecycle including a STOP, etc). Let me know if I am on the right track. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992370#3992370 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992370

19 years, 4 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 2006