[JBoss Web Services Development] - Re: jms transport support in jbossws-cxf
by jim.ma
So far the jms transport testcase I committed in does not register the jms endpoint in EndpointRegistry. If we list the services , there is one one endpoint listed in page and the jms transport endpoint is missing . Dug the code and found we use these steps to register endpoint :
1. create Service and Endpoints in WSDeploymentDeployer.
2. set the address in EndpointAddressDeploymentAspect and modify the name in EndpointNameDeploymentAspect (for native stack) . If the transport is MDB jms , the jms: will be appended to name .
3. register these endpoints in EndpointRegistryDeploymentAspect.
When the jms transport is enabled , we can see the endpoint address is http or https. Can we modify it to real correct jms address value ?
I thought of some possible solutions and to start this discussion here :
a. configure the jms address as the servlet parameter and set this jms address in WSDeploymentDeployer.
b. parse the wsdl and get the address and endpoint name map , then attach it to deployment . Use this map to match the endpoint's address In EndpointAddressDeploymentAspect. It only works for the service contains a wsdl. How to do with java first service ?
Is there any other solution here ? Which way is the better to go ?
I am waiting for your thoughts and comments ...
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261640#4261640
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261640
16 years, 5 months
[jBPM Development] - Re: Some bugs and feature requests on jBPM 4.1
by camunda
Joram wrote :
| 2. Invalid types.xml doesn't result in a parsing error
|
| Indeed a 'nice to have' feature ... should be easy to catch and log.
|
No, I think logging is not appropriate. The XML is wrong, so it should throw an exception!
Joram wrote :
| 4. Should be possible to set Subprocess Key by expression
|
| I've heard this request from someone else too. Besides have an easier overview with multiple subprocesses, what other benefits do you see?
|
If you have to externally signal that sub process you have to search it by key (since searching by process variables is not yet possible and maybe ineffective). But therefor you need a possibility to specify the key on creation to use it later to query the right process instance.
Joram wrote :
| 7. Signavio
|
| I agree. I got the same feedback from a meeting with real-life users. Also, the other way around (from Eclipse -> Signavio) doesn't always work well regarding coordinates, it seems.
|
Yesterday I got a NPE when opening a process from Eclipse in Signavio (unfortantely in a live presentation ;-) Anyway, so for sure there is still some work to do in that area ;-)
anonymous wrote :
| 8. Support EJB3 Entities as process variables
|
Yes, Ronald is right. How to use SLSB as variable? ;-) The other feature is nice as well, but EJB3 Entities is more important for me at the moment. But since both makes sense, cool to hear there is some progress in that area.
You should be totally releaxed after your honemoon, eh?
Can you create the bugs as JIRA issues? That would be really cool, otherwise I will do it hopefully next week.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261639#4261639
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261639
16 years, 5 months
[JBoss ESB Development] - Re: SAML Token Support
by anil.saldhana＠jboss.com
I had a good conversation with Kevin this morning. I agree with him for the following reasons.
Currently the STS Action is creating a token (via the STS) but updates the current security context with the new SC. The SC that the action was invoked is lost. Kevin asserts and I agree that the new SAML token should just augment the security context that currently exists rather than switching. If you want to switch the SC, then that should be a configurable option.
The STS action should be replaced by a pluggable SAMLTokenIssuingLoginModule such that you can just either push it in a new SecurityAction that does JAAS internally or you need to plugin the LM in the current JAAS framework wherever it is in the ESB infrastructure. Kevin mentioned that the JAAS layer already exists. So the STS action is not a replacement here.
On the SAML token validation end, the current LM is fine.
But there is a difference of opinion on the token generation end.
So you can either use a SecurityAction or use existing JAAS layer to do the following:
logincontext.login
Now the SAMLTokenIssuingLM will contact the STS for a new token. Then update the JAAS subject with this new token. You can choose either to make it a principal or a credential. Then before anything is sent on the wire to do a WS call, u can pluck the SAML token off of the security context (which has the JAAS subject) and send it over the wire.
Kevin, please update the text with clarification or pointers.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261633#4261633
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261633
16 years, 5 months
[JBoss Microcontainer Development POJO Server] - Re: Cleanup path for Structure Deployers
by david.lloyd＠jboss.com
Okay, after much discussion and gnashing of teeth here's the best approach we can figure out so far.
In order to accommodate the variety of conditions under which an archive may be mounted, the easiest solution would be to keep a registry of deployments, root or nested, which is the "resource owner" for the various submounts. This way, on undeploy the only information we need to clean everything up is the VirtualFile of the deployment root, which we should always have available if I understand this correctly.
This registry is lazily populated as deployers need access to archives; this is not unlike the automagic mount facility in VFS2. The difference is that all mounts have a deterministic lifecycle that is tied to deployments in various ways.
In order to manage references to mounted archives outside of the deployment, this registry would provide a simple refcount-backed mount system. Every deployment using a specific external classpath root would have a reference handle which is associated with the deployment registry mentioned above; when the deployment is removed, the handles will be cleaned up automatically, and any resources whose refcount drops to zero will be unmounted.
In addition, all mounts inside a deployment are subject to removal when the deployment is removed. In particular, if a refcounted resource later comes to be a part of another deployment for whatever reason, that deployment then assumes automatic ownership of that mount, so if the deployment is removed, the mount is nuked and any outside deployments referring to that resource are SOL.
This solution should allow deployments to access archive data as needed, including external shared archives, while still making sure that all resources are unmounted once nothing refers to them anymore.
Hoping this makes sense.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261626#4261626
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261626
16 years, 5 months
[JBoss ESB Development] - Re: Continue attribute in stateful rules evaluation
by jeffdelong
Kevin,
One of the design issues with support for stateful services was to be able to determine when to dispose of the StatefulSession. In the code I contributed I used message properties to tell the BusinessRulesProcessor to create the StatefulSession, continue to use it, or to dispose of it. In retrospect I am not sure this is necessarily a good design, as it requires the use of these message properties.
I don't believe these are currently working in ESB 4.6. I have been doing testing with ESB 4.6 and Drools 5 Complex Event Processing, and it appears the StatefulSession remains until the service is re-loaded (which is fine for the testing I have been doing).
I have written up other JIRAs recently proposing some ideas on how to better support CEP and StatefulSessions. One idea is to separate the management of the StatefulSession and the inserting of events into the StatefulSession into different services.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261623#4261623
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261623
16 years, 5 months