September 2009 - jboss-dev-forums

[JBoss ESB Development] - Re: SAML Token Support

by anil.saldhana＠jboss.com

"beve" wrote : Regarding the adding of the SAML Assertion to the outgoing SOAP Security Header, perhaps a better solution would be to have the JBossSTSAction set the SAML Assertion as a ThreadLocal. | This way we could write a a protocol handler for SOAP which could add the SAML Assertion to the out bound SOAP Header. | This would also simplify the STSAction as it would not require the additional 'addToEsb*' options. | | What do you think? | | Regards, | | /Daniel Dan., I think this is what the WS-T integration code will do. All you need to use is the API. Provide any assertion that you have. Under the covers the ws-t api should be doing this for you. I think the api is not updated to take in pre-existing assertions. Talk to Stefan to get it added. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255201#4255201 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255201

16 years, 6 months

1
0
0 / 0

[JBoss ESB Development] - Re: SAML Token Support

by jeff.yuchang

+1, I think we can go with ThreadLocal first and then see if there any problems. Thanks Jeff View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255200#4255200 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255200

16 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Potential deadlock in ClassLoaderManager

by adrian＠jboss.org

No the problem is on line 205 - unless the first thread with the add() is looping. It looks like a missed notification since nothing is holding the lock? | "Thread-2" prio=10 tid=0x83113800 nid=0x443e in Object.wait() [0x833b2000] | java.lang.Thread.State: WAITING (on object monitor) | at java.lang.Object.wait(Native Method) | - waiting on <0x942aa6e0> (a java.util.Collections$SynchronizedList) | at java.lang.Object.wait(Object.java:485) | at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:205) | - locked <0x942aa6e0> (a java.util.Collections$SynchronizedList) | If you can reproduce it, can you turn up the logging for org.jboss.detailed.classloader.ClassLoaderManager to TRACE. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255167#4255167 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255167

16 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Cannot resolve circular dependencies

by adrian＠jboss.org

This is very broken. You can't change the Capability interface in a stable release. Its part of the public spi. If you want a new method, then you should add a mixin interface, e.g. public interface Capability2 extends Capability { ... } and then have AbstractCapability implement it by invoking the old method calling code should do: | if (capability instanceof Capability2) | ((Capability2) capability).resolve(x, y, z); | else | capability.resolve(x, z); | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255163#4255163 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255163

16 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Autostart bundles when deployed in JBossAS

by adrian＠jboss.org

I'm not really following what this is all about? I don't think you should wrap and replace the DeployersImpl, that is very hacky. You should just extend it and configure your version as the impl to use. But even then, it doesn't look very good. e.g. This certainly looks very wrong. http://anonsvn.jboss.org/repos/jbossas/projects/demos/microcontainer/trun... It says anything that has an OSGiBundleState (which is everything - an OSGiMetaData attachment is what determines an OSGi deployment) should instantly move to INSTALLED at some unknown point in the CLASSLOADER stage of deployment - you don't even order after the java.lang.ClassLoader attachment? This completely breaks the "width first" behaviour of the deployers. If you just want all the bundles started then why not just set the required stage to INSTALLED in the first place? But this is actually not what it is says in the spec. If there are missing dependencies for something you want started, then you don't want to "after the fact" change the required state to DESCRIBED because then it won't appear in the IncompleteDeploymentException. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255161#4255161 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255161

16 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Cannot resolve dependency against unstarted bundle

by adrian＠jboss.org

I think you're missing the point? What is actually required is like "on-demand" processing for pojos but done for deployments. i.e. the bundle/deployment should sit at status DESCRIBED or CLASSLOADER (if somebody manually resolved it) until somebody wants to import from it. When somebody does that, it should try to move the deployment to INSTALLED If you look at the AbstractDependencyItem.resolve() there is this code | if (context == null) | { | resolved = false; | ControllerContext unresolvedContext = controller.getContext(iDependOn, null); | if (unresolvedContext != null && ControllerMode.ON_DEMAND.equals(unresolvedContext.getMode())) | { | try | { | controller.enableOnDemand(unresolvedContext); | } | catch (Throwable ignored) | { | if (log.isTraceEnabled()) | log.trace("Unexpected error", ignored); | } | } | } | but RequirementDependencyItem overrides that method so there is no on-demand processing. But making deployments have a controller mode of "on-demand" probably isn't the correct solution? For normal usage they need to be "manual" so that deployments are fully under the control of the MainDeployer. But you could add some similar code to the RequirementDependencyItem, e.g. (completely untested/compiled etc.) | // Resolved against a context in the dependent state | Object iDependOn = module.getContextName(); | ControllerContext context = controller.getContext(iDependOn, getDependentState()); | if (context != null) | { | setIDependOn(context.getName()); | addDependsOnMe(controller, context); | setResolved(true); | if (module.getClassLoadingSpace() == null) | log.warn(getModule() + " resolved " + getRequirement() + " to " + module + " which has import-all=true. Cannot check its consistency."); | return isResolved(); | } | + else | + { | + // The dependent module is not fully installed | + // if its not currently being processed (required state == state) then try to fully install it | + context = controller.getContext(iDependOn, null); | + if (context != null && context.getRequiredState().equals(context.getState())) | + { | + try | + { | + controller.change(context, ControllerState.INSTALLED); | + // It worked so we are now resolved | + if (ControllerState.INSTALLED.equals(context.getState())) | + { | + <Same code as above when it was already in the correct state/> | + } | + } | + catch (Throwable t) | + { | + log.trace("Error trying to fully install a dependent module: " + module, t); | + } | + } | + } | You almost certainly need to do something for circular dependencies in this code. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255154#4255154 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255154

16 years, 6 months

1
0
0 / 0

[JBoss Transactions Development] - Re: Asynchronicity and transaction context propagation

by chtimi2

"mark.little(a)jboss.com" wrote : | Check out Checked Transactions semantics. This tends to be the reason most implementations stay clear. JBossTS supported Checked Transactions, but does allow you to configure this aspect so it's possible. | | You can also check out http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.9485 Thanks for ideas, i'm going to do some reading. Also can you explain what you mean by JBossTS supported Checked Transactions, but does allow you to configure this aspect so it's possible. | ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255148#4255148 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255148

16 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: 3.6.3 Optional Packages

by adrian＠jboss.org

The issue here is that the dynamic import metadata isn't getting mapped to a PackageRequirement at the moment (see OSGiBundleClassLoadingDeployer for the TODO). The reason I haven't done it, is because the OSGi metadata lets you specify the packages using wildcards, while the current jboss implementation only lets you do explicit package names. See org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory and related classes. I could make your test work (since it doesn't use wildcards) but that wouldn't be the full solution. There's a similar issue for the "uses" constraint. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255139#4255139 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255139

16 years, 6 months

1
0
0 / 0

[EJB 3.0 Development] - HornetQ JCA Adapter question

by ataylor

Guys, HornetQ has its own RA adapter for MDB's and we have a question regarding the spec and the ejb3 implementation you may be able to answer. This is regarding section 12.5.6 of the JCA spec. Originally we used Option B and used the beforeDelivery/afterDelivery methods on MessageEndpoint to control transaction demarcation etc. We have recently changed this however to use Option A, we did this so we could have more control over the transactions so we could add things like local tx optimization, transaction batching etc. According to the spec with option A you don't call beforeDelivery/afterDelivery, you can see this clearly in figure 12-7 that this doesn't occur. The problem is that because we don't call these methods the Thread Context Classloader no longer gets set, so the question is this! Is the spec slightly ambiguous here, should we always call before/afterDelivery to do this. I would have thought that if we didn't call these then the MessageEndpoint proxy would still set the TCL before calling the MDB onMessage method. Any input would be appreciated! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255121#4255121 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255121

16 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor

by alesj

"emuckenhuber" wrote : | It most probably should be part of the AS integration, as we only add it to the DU we don't need the deployers to depend on it as well. | Yes, sounds even better. e.g. other AS components could just rely on it, w/o knowing anything about Papaki. "emuckenhuber" wrote : | We could also add some simple deployers to the 5_x branch - at least generating a empty ScanningMetaData for isMetaDataComplete() does not require Papaki. This could speed up legacy deployments quite a bit, as we wouldn't process the already scanned annotations anyway. | I think ScottM already did something similar. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255108#4255108 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255108

16 years, 6 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 September 2009