[JCA Development] - moving validate capability to metadata
by Stefano Maestri
Stefano Maestri [http://community.jboss.org/people/maeste] created the discussion
"moving validate capability to metadata"
To view the discussion, visit: http://community.jboss.org/message/553037#553037
--------------------------------------------------------------
Hi guys,
during re-design of our metadata I've seen validate methods in current org.jboss.jca.common.metadata.Metadata. This class isn't at the moment a metadata itself, but it'd more or less a metadataFactory where this utility methods have been added.
I think we can move validate capability into metadatas itself, adding to our new JCAMetadata interface the method "public void validate() throws ValidateException".
Moreover we can change, during this refactoring, a bit the validation control flow, adding intead of the previous proposed above to JCAMetadata the method:
"public ValidationStatus validate();"
where ValidationStatus is a simple pojo with 2 member: boolean valid; List<String> validationErrors;
In practice I'm saying to move validation strategies as closer as possible to the object to validate and don't use exception to control the flow.
If you'll agree I'll open a Jira linked to JBJCA-385 and I'll take care of this one too.
bye
S.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/553037#553037]
Start a new discussion in JCA Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 6 months
[EJB 3.0 Development] - What makes a business method asynchronous?
by jaikiran pai
jaikiran pai [http://community.jboss.org/people/jaikiran] created the discussion
"What makes a business method asynchronous?"
To view the discussion, visit: http://community.jboss.org/message/552992#552992
--------------------------------------------------------------
... other than the use of @Asynchronous annotation or it's xml equivalent. >From what I see in the EJB3.1 Spec, Section 4.5.1:
The @Asynchronous annotation is used to designate which business methods are asynchronous.
...
Asynchronous methods can also be designated via the deployment descriptor.
I do however see that in our async interceptor (which has to decide whether to spawn a new thread or continue in the current one), we additionally check for method return type to decide whether it's asynchronous:
// Determine if asynchronous (either returns Future or has @Asynchronous)
if (invocation.resolveAnnotation(Asynchronous.class) != null || actualMethod.getReturnType().equals(Future.class))
Just wondering whether this is OK. The only side-effect that I can think of, with this implicit rule for asynchronous method, is the difference in transaction semantics for that method invocation.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/552992#552992]
Start a new discussion in EJB 3.0 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 6 months
Re: [jboss-dev-forums] [JBoss ESB Development] - httprouter issues with GET/POST WADL Services and Web Routing
by jack lista
jack lista [http://community.jboss.org/people/jackalista] replied to the discussion
"httprouter issues with GET/POST WADL Services and Web Routing"
To view the discussion, visit: http://community.jboss.org/message/552913#552913
--------------------------------------------------------------
I don't thnk so, I just got it working, I'm spewing XML all over the place, thanks Dave. So we have a set of REST-like services that we will want to interact with on the bus, the exact architecture isn't determined just yet, we're just getting going with it (the ESB) now but being able to consume several of these services is one thing we needed, I suspect we may want to expose these services on the bus too which may require different sorts of things so I don't think this was a bad thing, I got a solution that's perhaps part of an evolving component to talk to restful services, we need that and it appears that's what Jersey's purpose is so it's sensible enough right now, I'm just at POC stage so it's all good.
It *does* make me wonder about JBoss ESB a bit, as while I like it, this is an awful lot of work to do to be able to talk to REST implementations from the bus, I would have thought JBoss would have provided this component. That said, you don't mind if I post the source for this do you? I've got it working as part of one of the quick starts so it's easy to deply and would hate to see the next who knows how many people have to repeat these steps... If I don't hear that you *don't* want me to post the source, I'll post it, at least to help those trying to do similar things get going. I have to clean it up a little and will atribute all but it's whittling down / repackaging to you as that's the reality of it. Anyway, I'm curious as to your thoughts but no, it's a starting point and much appreciated for what it is!
--j
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/552913#552913]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 6 months