[Design the new POJO MicroContainer] - Re: VFS HDScanner test
by sacha.labourey@jboss.com
Shouldn't we simply use an OS-dependent solution? i.e. depending on which OS JBoss is running on, we would use a different solution. That would mean that on some OSes, JBoss would be faster/more efficient, while on others it wouldn't. But at least, we would have a safe way of handling all situations. When I read that some solutions rely on timers, it freezes my spine.
Also, given that JBoss Web will be included in JBoss 5.0 and given that we will provide by default APR libraries for most OS, couldn't we also use this as part of the OS-specific check and rely on OS-specific native calls to detect whether a file is currently being opened/locked or not? Between the presence of APR libraries and OS-specific checks we should be able to offer a performing solution on most if not all OSes, no?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160781#4160781
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160781
15 years, 12 months
[Design of JBoss ESB] - Re: Wise based soap client for esb
by maeste
"jeffdelong" wrote :
| I have a question about how you would recommend handling ws-security and ws-transaction information. How would you recommend this be added to the SOAP Header?
| I have been working with JBoss Transaction XTS component, and have created a quickstart showing ws transactions business activity. But I had to add the transaction context to the SOAPHeader and invoke the web service through my own custom action. I would rather use SOAPClient.
well, wise natively support JAX-WS handler to modify SOAP Header. Wise-core support 3 kind of handler: a simple logging handler (to log request and response message), Smooks handler (to transfor header, supporting freemarker too), and custom handler to add any kind of JAX-WS compliant handler. The current implementation of ESB action just support Logging and Smooks ones, but it would be easy to add custom handler too.
Anyway Smooks handler have always done the job for me, being very powerful and flexible modifying headers.
The third quikstart sample I wrote demostrate a simple use of Smooks handler. It is a very simple use case, but keep in mind you have there all the Smooks' powers ;)
Does this answer your question? Do you need something more?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160770#4160770
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160770
15 years, 12 months
[Design of JBoss jBPM] - Re: jPDL 4 early feedback
by tom.baeyens@jboss.com
Thanks for pointing that out, Alejandro. Not all of it was clear to me so that proves my point that people should be able to use it without messing with namespaces :-)
feature http://apache.org/xml/features/validation/dynamic
is not supported in suns JDK 5 Dom parser
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6399139
anonymous wrote : javax.xml.parsers.DocumentBuilderFactory.setFeature(
| "http:// customer .org/xml/features/validation/dynamic", true);
|
| causes the following exception at runtime:
|
| javax.xml.parsers.ParserConfigurationException:
| jaxp_feature_not_supported: Feature
| "http:// customer .org/xml/features/validation/dynamic" is not supported.
|
| ...
|
| This is fixed in JAXP1.4/JDK6
| Posted Date : 2007-04-03 20:23:47.0
|
The only way I got around it was the following:
Use a SAX parser. The JDK 5 sax parser supports that feature. Then I 'borrowed' a DOMBuilder from ODE that implements ContentHandler and builds up a DOM (in the meantime it adds the line number information as attributes)
Not sure if this is a practical solution going forward.
I also wondered if it was necessary. Cause I found out that I was in fact NOT using a validating parser all the time. Our parser that walks the DOM generates most problems anyway. And people will author the process in an XML editor that still *does* support the validation.
So the way forward, I think is this:
1) We just use the plain DOM parser when walking the DOM and building the process object model. This does not do any validation
2) We have a list of deployers that is processing a deployment. So we can offer a separate validation deployer step that is configurable. If people use this, they will parse the process 2 times. I don't think that is a big deal.
3) We make the parser that builds up the object model from the DOM configurable. So that users that are using JDK 6 can activate schema validation in the DOM parse if they want to.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160757#4160757
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160757
15 years, 12 months