[JBoss AOP Development] New message: "How can I use JBoss AOP on jboss 4.0.2 ?"
by Doochul KIM
JBoss development,
A new message was posted in the thread "How can I use JBoss AOP on jboss 4.0.2 ?":
http://community.jboss.org/message/528106#528106
Author : Doochul KIM
Profile : http://community.jboss.org/people/headiron
Message:
--------------------------------------------------------------
Hi.
Today I try to use jboss AOP on jboss 4.0.2.
I have some question about it.
1. Is it support only POJO class or include EJB bean ?
I want to use jBoss AOP to intercept some EJB call, but there isn't any article whether it is support ejb or not.
2. Can I use interceptor on EJB3 using jboss 4.0.2?
It seems that jboss4.0.2 support just J2EE1.4.
If I want to use interceptor on EJB3 what version of jboss I use ?
3. How can I use(use ) AOP on jboss 4.0.2 ?
I download sample file from http://docs.jboss.org/jbossas/jboss4guide/r3/jboss4guide.zip and build it( move to examples subfolder and build by ant ).
After that I copy two files (MortgageCalculator.war, TrialLimitAspect.aop ) on examples/output/jbossaop/ folder to deploy folder on jboss server.
I test it , but AOP function is not work.
Do I need to do any step ?
( I attach above two files on this )
Thanks
Doochul
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/528106#528106
16 years, 1 month
[JBoss ESB Development] New message: "Camel integration input requested"
by David Ward
JBoss development,
A new message was posted in the thread "Camel integration input requested":
http://community.jboss.org/message/528084#528084
Author : David Ward
Profile : http://community.jboss.org/people/dward
Message:
--------------------------------------------------------------
Hi everybody,
I've been doing a lot of studying and playing around with Camel lately ( http://camel.apache.org/ ), and I think if we could integrate it well with JBoss ESB, we could win a lot of great functionality all at once. Camel does not claim to be an ESB, but a routing and mediation engine. I think it would be great if we could leverage it, especially given all the cool connectors it has out-of-the-box ( http://camel.apache.org/components.html ).
FYI: Edgar S. and Tom F. have already done some playing around with Camel integration:
* http://ankiewsky.blogspot.com/2008/10/integrating-apache-camel-with-jboss...
* http://ankiewsky.blogspot.com/2009/02/combining-apachecamelbsf-to-make-jb...
* http://blog.smooks.org/2010/02/22/apache-camel-smooks/
What I am requesting in this developer forum thread is for people to brainstorm how they would like to see it integrated as a 1st class JBoss ESB citizen, any thoughts or concerns, etc. I will go ahead and list some *+possibilities+* here:
* *Deployment*
0.1. Extend the jboss-esb.xml config format to allow for Camel XML DSL to be defined. This is currently a bit yucky as we actually duplicate a considerable amount of java code whenever we add a new version of jboss-esb.xml config.
0.2. Augment the ESB deployer mechansim to pickup and hot-deploy Camel XML DSL by some sort of naming convention in the .esb archive structure.
0.3. Similar to #1 and/or #2 above, but allow for Java DSL. Personally I like the Java DSL much better than the XML (Spring) DSL. I am not suggesting putting it in the jboss-esb.xml itself, but maybe define a class in the XML which extends Camel's RouteBuilder. That way we can have compile-time safety.
0.4. Don't add anything to jboss-esb.xml but instead do .esb archive class scanning for any class which extends Camel's RouteBuilder, and deploy it.
* *Components*1. Create our own Camel component representing invoking a JBossESB-deployed service via service category + service name. It would be represented by our own custom URI but use our ServiceInvoker under-the-hood.
2. What else?
* *Message Translation*1. We would need to be able to translate between Camel's concept of Messages (and Exchanges) to/from our concept of Messages, possibly as part of the consumer/producer work.
2. We might need to come up with our own Camel DataFormat for body transformation.
* *Actions/Listeners/Gateways*1. We could technically create a new Action and/or Listener that builds the Camel routes, but I feel we could do a tighter (more "elegant") and feature-rich integration than this.
What else? I know I'm missing a lot here (it's late and I'm tired), but I wanted to get this discussion kicked off. I would really like to hear your sugestions!
Thanks in advance for your help,
David
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/528084#528084
16 years, 1 month
[JBoss ESB Development] New message: "Allow Service execution from HttpGatewayServlet with ?wsdl requests when there is no ContractProvider available?"
by David Ward
JBoss development,
A new message was posted in the thread "Allow Service execution from HttpGatewayServlet with ?wsdl requests when there is no ContractProvider available?":
http://community.jboss.org/message/528017#528017
Author : David Ward
Profile : http://community.jboss.org/people/dward
Message:
--------------------------------------------------------------
Please first read this JBoss ESB User Form Thread: http://community.jboss.org/message/528014#528014
This JBoss ESB Developer Forum Thread is in context to the short-circuting behavior of HttpGatewayServlet when it encounters a ?wsdl (or ?WSDL) request.
Right now, the SOAPProxyWsdlContractPublisher is the only Publisher that implements ContractProvider. When there is a Service whose action pipeline contains an action that is annotated with @Publish, and the associated Publisher implements ContractProvider, then the HttpGatewayServlet knows to ask it to provide the ContractInfo so it can respond to the WSDL request appropriately. However, if a ?wsdl request is made to the servlet and there is no ContractProvider, it simply spits out an empty <definitions/> WSDL contract. This is expected behavior.
We might want to change this behavior, such that +*if there is no ContractProvider*+, then go ahead and have the HttpGatewayServlet execute ServiceInvoker anyway, even if it's a ?wsdl request. What this does is it gives the developer an option to write a custom action that uses HttpRequest requestInfo = HttpRequest.getRequest(message), then use the properties of requestInfo to determine of the user asked for the WSDL (?wsdl), then serve up custom wsdl. The downside is that if the developer doesn't handle that case, then most likely the action pipeline will get executed without the correct request data / payload, and things will fail. Hmmm... perhaps we keep the current behavior the default, but provide an option to HttpGateway to allow for this? Maybe something like <http-gateway name="..." allow-wsdl-requests="true"/> ? (Okay, that's a bad attribute name, but you get the point.)
If we don't do anything, the developer still has another existing option, although it does entail a bit more work. Basically, on a custom action, add a @Publish annotation that uses a custom Publisher implementation that implements ContractProvider. The developer could simply extend DefaultContractReferencePublisher and implemement ContractProvider, for example, then use that to spit out their custom WSDL. The added benefit of this approach is that their WSDL will also magically show up in the contract JSP application ( http://.../contract/ ).
Thoughts?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/528017#528017
16 years, 1 month
[JBoss ESB Development] New message: "Allow Service execution from HttpGatewayServlet with ?wsdl requests when there is no ContractProvider available"
by David Ward
JBoss development,
A new message was posted in the thread "Allow Service execution from HttpGatewayServlet with ?wsdl requests when there is no ContractProvider available":
http://community.jboss.org/message/528013#528013
Author : David Ward
Profile : http://community.jboss.org/people/dward
Message:
--------------------------------------------------------------
Please first read this JBoss ESB User Forum thread first: http://community.jboss.org/thread/148046
Right now, the SOAPProxyWsdlContractPublisher is the only Publisher that implements ContractProvider. When an action pipeline contains the SOAPProxy, then, the HttpGatewayServlet knows to execute it to get the WSDL contract from a http://.../http/category/service?wsdl URL. This is correct behavior.
Now, say that a developer has his/her own actions +not+ including the SOAPProxy, but still want to expose his/her own WSDL for it, as in the aforementioned user forum thread... If a developer wants to, there is nothing stopping him/her from creating his/her own custom action that has a Publish annotation defining a custom Publisher implementation that extends, for example, DefaultContractReferencePublisher and implements the ContractProvider interface. Then not only can the developer serve up this/her own WSDL, but that WSDL would also dynamically be available via the contract JSP application ( http://.../contract/ ). But that's a bit of work...
However, if the developer doesn't care about exposing the WSDL in the contract JSP application, but still wants the HttpGatewayServlet to expose their own WSDL, but DOESN'T want to go through the work mentioned above, it would be nice to provide that functionality. To do that, a very simple change to HttpGatewayServlet would have to be made:
Right now, the HttpGatewayServlet looks for query strings of ?wsdl (or ?WSDL). If found, it immediately short-circuits and exposes the WSDL contract it found using the ContractProvider. +*If there was no ContractProvider, an empty <definitions/> WSDL is returned.*+ The easy change would be that once the servlet knows it's a WSDL request, if there is a ContractProvider, spit out the WSDL it provides, but if there is NO ContractProvider don't short-circuit, instead go ahead and execute ServiceInvoker. Then, in a custom action at the beginning of the pipeline, the developer could use HttpRequest requestInfo = HttpRequest.getRequest(message); to inspect the message, see that it was a WSDL request, and spit out the custom WSDL, otherwise, do something else.
Thoughts?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/528013#528013
16 years, 1 month