[JBoss Web Services Development] - Bad URL for jar resources in WSConsume
by chrholm
Hi
We are using WSConsume to generate stubs for a WSDL document. We put the document in the jar-file along with the generated stubs, and specify the wsdlLocation as "file.wsdl".
The @WebServiceClient file then contains the following part in a static block:
| static {
| URL url = null;
| try {
| URL baseUrl;
| baseUrl = foo.Bar.class.getResource(".");
| url = new URL(baseUrl, "file.wsdl");
| } catch (MalformedURLException e) {
| logger.warning("Failed to create URL for the wsdl Location: 'file.wsdl', retrying as a local file");
| logger.warning(e.getMessage());
| }
| PXORDER_WSDL_LOCATION = url;
| }
|
I don't know why it makes use of the baseURL, but this fails when the resource is in a jar file. A simpler approach (that works in a jar file also), is to simply do:
| static {
| URL url = null;
| try {
| url = foo.Bar.class.getResource("file.wsdl");
| } catch (MalformedURLException e) {
| logger.warning("Failed to create URL for the wsdl Location: 'file.wsdl', retrying as a local file");
| logger.warning(e.getMessage());
| }
| PXORDER_WSDL_LOCATION = url;
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255319#4255319
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255319
16 years, 6 months
[jBPM Development] - Re: Change caching strategy from nonstrict-read-write to tra
by the_olo
"tom.baeyens(a)jboss.com" wrote : changing caching strategy from nonstrict-read-write to transactional doesn't seem to be necessary to me.
|
| in jBPM 3, we only cached process DEFINITION data. which is assumed to be static in the DB. so the idea is that this can be cached in read only mode. the reason why we used nonstrict-read-write instead of read-only is to allow for new process definitions to be deployed (read: inserted)
Exactly for this reason we need write-capable and cluster-wide consistent cache.
We're going to hot redeploy business processes - otherwise, what's the point of the whole business process engine, if we can just as well write some logic and deploy the new EAR (ok, ok, ready framework for keeping the state of long running processes, process abstraction that it imposes and other stuff is good to have, but hot deployment is the killer feature for many).
I've investigated the issue a bit further and it turns out that the problem lies in some lack of coordination between jBPM-jPDL and jBPM-BPEL development, coupled with a Hibernate bug and general quirks of Hibernate 2nd level cache.
In jBPM-BPEL 1.1.GA release, there was jBPM-jPDL version 3.2.2 embedded. It contained all its cache configuration in .hbm.xml files.
The per class HBM files located in jbpm-jpdl.jar, bundled with jBPM-BPEL had the cache hardcoded to nonstrict-read-write.
This is the caching strategy that works with all 2nd level cache implementations apart from JBoss's TreeCache and JBoss Cache 2 (http://docs.jboss.org/hibernate/stable/core/reference/en/html/performance...).
It seems that between versions 3.2.2 and 3.2.3, jBPM-jPDL people have decided to centralize second level cache configuration and remove it from individual HBM files, placing them centrally in the hibernate config file (config/hibernate.cfg.xml), after the mapping section.
I can't point to an URL for the exact distributed file (you can download jbpm-jpdl-3.2.3 release and have a look yourself), but an approximate version can be seen here since it has been embedded in seam:
http://svn.apache.org/repos/asf/myfaces/tobago/trunk/example/seam/src/mai...
As you can see, the file contains the mapping declarations, sourced from individual HBM files, then goes on to specify cache settings for the mapped classes and collections.
Now, two things went wrong here:
1) It seems that Alejandro Guizar, when incorporating jbpm-jpdl-3.2.3 into the next release jbpm-bpel-1.1.1 (https://jira.jboss.org/jira/browse/BPEL-297), hasn't noticed the caching change. This has resulted in jbpm-bpel-1.1.1 running totally cache-less with respect to jPDL entities. We've observed a ten-fold performance drop when upgrading from jbpm-bpel-1.1.GA to jbpm-bpel-1.1.1. Process execution speed has literally dropped through the floor.
Only after adding the cache tags back to HBM files in jbpm-jpdl.jar (one by one, since the HBM files for jPDL 3.2.3 contained some vital modifications unrelated to 2nd level cache), we got the engine's performance back to normal.
One might think that it would be a lot easier to simply copy the centralized cache settings from jbpm-jpdl-3.2.3 hibernate.cfg.xml to jbpm.hibernate.cfg.xml in jbpm-bpel-1.1.1. It's not so simple, unfortunately, due to the problem no.:
2) Due to a Hibernate bug (http://opensource.atlassian.com/projects/hibernate/browse/HHH-2808 - rejected BTW by Hibernate devs), one cannot specify collection cache settings in the Hibernate session factory configuration file.
The elements are there in the DTD (see http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd), but using them on a collection mapped in a subclass simply results in an exception: "org.hibernate.MappingException: Cannot cache an unknown collection".
So the example configuration distributed with jbpm-jpdl-3.2.3 won't work for jbpm-bpel-1.1.1 anyway and unless HHH-2808 issued gets fixed, one has to resort to modifying the jPDL HBM files by hand.
This also makes clustering the business process engine much harder, since in order to guarantee consistency of hot-deployed business processes throughout the cluster, one needs to employ a replicated second level cache, which requires changing the caching strategy from nonstrict-read-write to transactional, and doing this across dozens of .hbm.xml files packed in a .jar is far from perfect.
The method we employed was to unpack the jar, run a find|perl one liner that did the substitution, then jar it up again.
"tom.baeyens(a)jboss.com" wrote : in jBPM 4, the process definitions are cached in memory by jBPM itself. so there we don't even have hibernate second level cache configurations at all.
|
| we didn't specify 2nd level cache configurations on the runtime data. not in jBPM 3 and not in jBPM 4. that is a topic we could explore. but it doesn't have a priority for us at this time. in that case i guess the cache must be configured as transactional as the runtime data is not read only (of course)
Based on our testing, we can say that properly caching the definition data helps a lot - improves performance by an order of magnitude.
Cache for runtime might help, but first and foremost, I don't think that definition data can be treated as read only, since the point of a business process engine is to gain flexibility in the world of inevitable change, which concerns business processes.
We cannot treat processes as static data.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255256#4255256
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255256
16 years, 6 months
[JBoss ESB Development] - Re: SAML Token Support
by anil.saldhana＠jboss.com
"beve" wrote : Jeff Yu and I are working on adding SAML v2.0 support for JBossESB : http://jira.jboss.org/jira/browse/JBESB-2263
|
| We have the following situations regarding authentication:
|
| The calling party has a pre-existing SAML Assertion that is to be validated.
| This option is taken care of by JBossSTSLoginModule which is a JAAS Login Module which will call JBossSTS (Security Token Service) to validate an existing SAML Assertion. The SAML Assertion will be extracted prior to calling the service by the client. The client could be an external client using the ServiceInvoker or could be a gateway in the ESB.
|
| Example of JBossSTSLoginModule configuration:
| <application-policy name = "jbossesb-saml">
| | <authentication>
| | <login-module code="org.jboss.soa.esb.services.security.auth.login.JBossSTSLoginModule" flag="required">
| | <module-option name="serviceName">JBossSTS</module-option>
| | <module-option name="portName">JBossSTSPort</module-option>
| | <module-option name="endpointAddress">http://localhost:8080/jboss-sts/JBossSTS</module-option>
| | <module-option name="username">admin</module-option>
| | <module-option name="password">admin</module-option>
| | </login-module>
| | </authentication>
| | </application-policy>
| |
|
| The calling party does not have a SAML Assertion so one needs to be issued.
| The issuing of a SAML Assertion will be performed by an action in the ESB called JBossSTSAction. This actions configuration is very similar to the
| configuration of the JBossSTSLoginModule since they both use the WSTrustClient under the covers.
|
| Example configuration of JBossSTSAction:
| <action name="issueToken" class="org.jboss.soa.esb.actions.security.JBossSTSAction">
| | <property name="serviceName" value="JBossSTS"/>
| | <property name="portName" value="JBossSTSPort"/>
| | <property name="endpointAddress" value="http://localhost:8080/jboss-sts/JBossSTS"/>
| | <property name="username" value="admin"/>
| | <property name="password" value="admin"/>
| | <property name="tokenType" value="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"/>
| | <property name="addToEsbMessage" value="false"/>
| | <property name="addToEsbAuthRequest" value="true"/>
| | </action>
| The properties 'addToEsbMessage' and 'addToEsbAuthRequest' might need some explaination.
|
| addToEsbMessage means that the SAML Assertion will be set on the ESB Message object using the configuration location. This uses the the PayloadProxy so the normal options are available here. This would be used when you are about to call an external services and need access to the SAML Assertion.
|
| addToEsbAuthRequest means that the SAML Assertion will be added to the ESB AuthenticationRequest. This would be set when your are will be calling other services in the ESB that require a valid SAML Assertion, i.e. that are using the JBossSTSLoginModule.
|
| What still needs to be done is adding the extraction of the SAML Assertions in the gateway(s) and also have the Assertion injected into outgoing SOAP Message Security Headers. Using JAX-WS protocol handlers seem appropriate in this situation but I'll be looking onto this next
|
| Workspace: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/dbevenius/sam...
| Quickstart: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/dbevenius/sam...
|
| Any thoughts or comments are welcome.
|
| Regards,
|
| /Daniel
Looks reasonable to me. Just ensure that you do not use any JAXB api as it can mess up the xml signatures. The STS will be the authority in validating as well as issuing assertions.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255202#4255202
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255202
16 years, 6 months