Got this working in the end, built a new extension as you suggested. Thanks so much for all your help, definitely steered me in the right direction.
Padraig -----Original Message----- From: Simon Laws [mailto:simonsl...@googlemail.com] Sent: 29 October 2010 11:05 To: user@tuscany.apache.org Subject: Re: How to add authentication property to JMS header On Thu, Oct 28, 2010 at 6:11 PM, Padraig Myers <padraig.my...@gmail.com> wrote: > Hi Simon, > > First, I am using 1.x > > Thanks for the link to that page, there is some useful information in there. > > At this stage it looks like I need to create a custom interceptor that grabs > the data from the session (that won't be problem, its stored in a > ThreadLocal singleton) and puts it into JMS properties. > > Essentially the > > org.apache.tuscany.sca.binding.jms.policy.authentication.token. > > JMSTokenAuthenticationReferencePolicyInterceptor does almost exactly what I > need, except in the section that says: > > if (principal == null){ > > // should call out here to some 3rd party system to get credentials > > // and correct token. Here we are just putting in the token name > > principal = new TokenPrincipal("DummyTokenID"); > > subject.getPrincipals().add(principal); > > } > > jmsMsg.setStringProperty(policy.getTokenName().toString(), > > principal.getName()); > > > > I need to replace this with code to add my session data to the properties. > Something like: > > jmsMsg.setStringProperty("USER_ID", SessionHolder.getUserId()); > > jmsMsg.setStringProperty("USER_NAME", SessionHolder.getUserName()); > > > > However to do this it looks like I need to rewrite the entire extension, > including all the StAX Processor files etc. > > This seems like overkill to get such a simple task done, am I missing > something whereby there is some method to call out to a simple message > processor without have to write a whole extension. > > > > Padraig > > So taking the policy approach (which seems sensible) what you should be able to do is create a new module that: - defines the new policy - defines the policy providers and interceptors - defines the policy set definitions and intents Then, if you add that the the classpath, you should be able to use it without re-working the JMS binding. Using the JMSTokenAuthenticationPolicy as an example you'll need.... A policy model which describes any configuration that can appear in the definitions.xml file: JMSTokenAuthenticationPolicy.java (from binding-jms-policy module) A processor to read this policy from the defintions.xml file: JMSTokenAuthenticationPolicyProcessor.java (from binding-jms-policy module) Some meta-data to tell the infrastructure to use this processor when it finds the policy in the definitions.xml file (from binding-jms-policy\src\main\resources\META-INF\services\org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessor) org.apache.tuscany.sca.binding.jms.policy.authentication.token.JMSTokenAuthenticationPolicyProcessor;qname=http://tuscany.apache.org/xmlns/sca/1.0#jmsTokenAuthentication,model=org.apache.tuscany.sca.binding.jms.policy.authentication.token.JMSTokenAuthenticationPolicy I you look at the definitions.xml file (in this case from itest\policy-security-token\src\main\resources) you'll see the policy set definition that makes the policy available to composite applications: <sca:policySet name="JMSTokenAuthenticationPolicySet" provides="authentication" appliesTo="sca:binding.jms"> <tuscany:jmsTokenAuthentication xmlns:foo="http://tuscany.apache.org/foo"; tokenName="foo:myname"/> </sca:policySet> The definition.xml file also needs a META-INF/services registration so the runtime will pick it up. This policy set can be referenced in a composite file, for example, helloworld.composite (from itest\policy-security-token\src\main\resources) <reference name="helloworldJMS" requires="authentication"> <binding.jms uri="jms:HelloWorldService"/> </reference> The requires="authentication" defines an intent that the policy set provides (see above). You can actually specific the policy set directly on the reference using the "policySet" attribute but this example doesn't do that. The presence of that policy set in the model will cause the runtime to add the interceptors to the wires. To make this happen we need some providers for the policy (from binding-jms-policy module) JMSTokenAuthenticationPolicyProviderFactory.java - a factory used to create the providers JMSTokenAuthenticationReferencePolicyProvider.java - providers for creating reference and service interceptros JMSTokenAuthenticationServicePolicyProvider.java JMSTokenAuthenticationReferencePolicyInterceptor.java - the providers themselves JMSTokenAuthenticationServicePolicyInterceptor.java To make the runtime aware of the providers again we need to add some META-INF/services meta data. See binding-jms-policy\src\main\resources\META-INF\services\org.apache.tuscany.sca.provider.PolicyProviderFactory Obviiously you can cut and paste the majority of this from the existing classes. If you package your policy in a new module a.new.policy.NewPolicy.java a.new.policy.NewPolicyProcessor.java a.new.policy.NewPolicyProviderFactory.java a.new.policy.NewReferencePolicyProvider.java a.new.policy.NewServicePolicyProvider.java a.new.policy.NewReferencePolicyInterceptor.java a.new.policy.NewServicePolicyInterceptor.java definitions.xml META-INF/services/org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessor META-INF/services/org.apache.tuscany.sca.provider.PolicyProviderFactory META-INF/services/org.apache.tuscany.sca.provider.SCADefinitionsProvider and add it to the runtime classpath I think you should be OK. Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
