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

[Design of Security on JBoss] - Re: Broken object names in jacc

by anil.saldhana＠jboss.com

| static final String BASE_OBJECT_NAME = "jboss.jacc:service=jacc,id="; | | /** | * Qualify the object name with parent name just to avoid conflicts | * with deployments with the same name in multiple archives | */ | private String getObjectName(DeploymentUnit unit) | { | String deploymentName = unit.getSimpleName(); | DeploymentUnit parentDU = unit.getParent(); | String parentDeploymentName = parentDU != null ? | ",parent=" + parentDU.getSimpleName() : ""; | return BASE_OBJECT_NAME + deploymentName + parentDeploymentName; | } | If deploymentunit.getSimpleName is blank, then id= is blank. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137156#4137156 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137156

18 years

1
0
0 / 0

[Design of Security on JBoss] - Re: Broken object names in jacc

by anil.saldhana＠jboss.com

the id=something of the objectname is for the JACC context id of the deployment. Something like "id=ROOT.war" or id=jmx-console.war Is there a particular test that displays this issue? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137154#4137154 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137154

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Moving to CR1 releases of the MC projects

by alesj

"adrian(a)jboss.org" wrote : | e.g. I'd like to get the reflection and MDR projects with the latest "private fields" changes/fixes beta12 out as soon as possible since the other projects depend on those. | I'm currently hacking in the field injection features in the Kernel module. ATM I don't see any other fixes/addition to Reflection or MDR, but I'm not done yet, specially not with the full blown tests. But I promise I'll be done by Thursday. With all 3 modules. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137153#4137153 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137153

18 years

1
0
0 / 0

[Design of JBossCache] - JBCACHE-1170

by bstansberry＠jboss.com

Discussion of ongoing problems with http://jira.jboss.org/jira/browse/JBCACHE-1170 . Possible cause, from org.jgroups.blocks.RequestCorrelator.handleRequest() through which all RPCs come: | try { | retval=request_handler.handle(req); | } | catch(Throwable t) { | if(log.isErrorEnabled()) log.error("error invoking method", t); | retval=t; | } | | if(!hdr.rsp_expected) // asynchronous call, we don't need to send a response; terminate call here | return; | | if(transport == null) { | if(log.isErrorEnabled()) log.error("failure sending response; no transport available"); | return; | } | | // changed (bela Feb 20 2004): catch exception and return exception | try { // retval could be an exception, or a real value | rsp_buf=marshaller != null? marshaller.objectToByteBuffer(retval) : Util.objectToByteBuffer(retval); | The first try block calls into the JBC code and ends up calling into the code that sets the CacheMarshaller200.regionForRemoteCall ThreadLocal. Last try block again calls into the JBC response marshalling code, which clears the ThreadLocal. Problem is the 2 return calls in between, particularly the 1st which will cause the method to return for every ASYNC RPC w/o clearing the ThreadLocal. This is a private method, so there's no clean way to override it to ensure the TL is cleared. Perhaps InactiveRegionAwareRpcDispatcher can clear the TL if the return value is null. That's a fragile mechanism to try to guesstimate what returns are possibly async. Mostly just a cleanup attempt. A separate question is why the partial state transfer call isn't setting the TL to the correct value. Ah, right, it's not RPC based so the state transfer request doesn't go through the marshaller. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137144#4137144 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137144

18 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: New jBPM Console

by brittm

So much can be gained (and proven) using an EJB3 stack, that I can't think of a good reason not to. Three thoughts: * The jBPM/SEAM/Jboss community should be looking for opportunities to demonstrate all these offerings really working together on a modern EJB3 platform. Red Hat/Jboss needs to show the industry that its solutions are modern and to take the lead in demonstrating best-practices in the implementation of its leading technologies. * Implementing against EJB3 would be more likely to identify bugs and needed enhancements in up-stream projects--doing more to both improve the upstream projects and provide a greater pool of solid, working examples of utilizing these technologies in a modern framework. * Process management is such an "enterprise" type of application, that requiring a modern container seems quite reasonable. * Negatives might be any known issues with EJB3 that would hamper delivery of a solid product. (But I don't know of any, so someone else will have to speak about that.) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137143#4137143 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137143

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Moving to CR1 releases of the MC projects

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | So starting from this week, I'm going to be doing beta releases on Fridays | of the MC projects if they have changes during the week. | If we can get a release out before Friday all the better. e.g. I'd like to get the reflection and MDR projects with the latest "private fields" changes/fixes beta12 out as soon as possible since the other projects depend on those. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137141#4137141 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137141

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Moving to CR1 releases of the MC projects

by adrian＠jboss.org

In an effort to try to get the codebase stable I want to move to more frequent releases of the betas with the codebase in an easy integratable state into JBossAS. If we think a beta is stable then we can move it to an CR1 meaning there will be no more new features (however minor), just bug fixes. So starting from this week, I'm going to be doing beta releases on Fridays of the MC projects if they have changes during the week. These are the main projects used by the AS that I'm responsbile for at the moment, i.e. not VFS, managed, reliance, OSGI With that in bind, JIRA needs updating with what we think will be done end of Thursday. Friday will be testing and bug fixing only until I've got the releases out. :-) I'll be spending most of my time testing and fixing the AS anyway. Anything that doesn't make it must be reverted and done again in the next week, so plan accordingly. (if we move to project to a CRx then I'll create a branch such that new development/features can continue in trunk). I'm hoping we can get to CRx/GA releases very quickly, hopefully within a couple of weeks? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137140#4137140 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137140

18 years

1
0
0 / 0

[Design of POJO Server] - Fixing the WarClassLoaderDeployer

by adrian＠jboss.org

The current way the WarClassLoaderDeployer works is all of 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. Same goes for some of the other flags, is "acceptNonWarDirs" still used? COPYING TO TEMP Again this should be in the structure deployer. The VirtualFiles is adds should be the temp ones. ALT-DD This doesn't look like it is handled properly in the new deployers? Shouldn't this be handled in the metadata parsing? PLAYING AROUND WITH METADATA The merging and altering of metadata shouldn't be left to the "RealDeployer" i.e. AbstractWarDeployer. Doing so means it cannot be overridden by some other policy. What's most annoying is that bad examples like this are being used by the other people as the correct way to do things :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137137#4137137 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137137

18 years

1
0
0 / 0

[Design of POJO Server] - Re: State of the integration of the latest MC into AS

by adrian＠jboss.org

I've decided to commit this, even though it is not complete. Trying to unravel how the WAR classloader is integrated (wrongly :-) is going to take me a fair bit of work in different places. For now I've just replaced the WARClassLoaderDeployer with a POST_PARSE deployer that creates the ClassLoadingMetaData for the war classloader. i.e. it uses the new mechanism but almost certainly with lots of problems that the old mechanism had. I'm also going to commit against the snapshot-temp I created of the MC. It will include an update JBossXB CR7 This isn't ideal, but with Ales's latest change to add support for private field injection, despite my request NOT to do major changes until I'd updated the latest (split up) MC in to JBossAS http://www.jboss.com/index.html?module=bb&op=viewtopic&t=130461 I don't feel confident about putting the latest stuff in there. We'd need to get this stablised as ASAP so we are back on proper releases and get to the CR1 as soon as possible. Reflection and MDR which is what Ales is changing are the only projects I'd done beta11 releases for, but they are obviously out-of-date now. ;-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137132#4137132 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137132

18 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Potential enhancement to jbpm

by brittm

I've created Jira issues for these four pieces of data: task ui= http://jira.jboss.com/jira/browse/JBPM-1149 process-definition ui= http://jira.jboss.com/jira/browse/JBPM-1150 process-definition release= http://jira.jboss.com/jira/browse/JBPM-1151 process-definition timestamp http://jira.jboss.com/jira/browse/JBPM-1152 If someone is willing to implement the ui= attributes, I'll provide a section for the documentation that describes their purpose and provides a good usage example--just tell me who to send it to. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137130#4137130 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137130

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