[My last mail was sent too early... wrong button... please ignore!]
John,
On 08/31/2011 01:42 AM, John D. Ament wrote:
> On Sun, Aug 28, 2011 at 4:52 PM, Rüdiger zu Dohna
> <ruediger.dohna_at_1und1.de <mailto:ruediger.dohna_at_1und1.de>> wrote:
>
> I thought about your business interface binding as well. Assuming CDI
> 1.1 supports service handlers,
I started to work on my own extension, because the service handlers
extension doesn't allow me to refer to the injection points. The core
problem is working but it's not finished, yet.
> I think this is more extension rather
> than core.
Extension to JMS? Yeah, it can be implemented to sit on top of JMS. But
maybe it can replace the 1.1 API completely!
> I don't know that it makes sense to standardize, especially
> when the arguments are all per application.
I agree, certainly not! I will try to produce a proposal, so it's clear
what it's supposed to do.
> * ObjectMessages
>
> I run into class loader issues all the time. I've thought off and on
> about how to automate binding, and the only decent way I can think of is
> to leverage JAX-B and make it look like to the producer and consumer
> that it's the reall object.
This is exactly what I did for the MessageApi.
> * Defining all defaults, e.g. the default factory attribute of the
> JmsConnection annotation, would improve portability, wouldn't it?
> The spec doesn't have to define the exact value in this case, but
> the exact semantics should be set, shouldn't it?
>
>
> At least in my history, all of these are really application specific.
> I'm not sure a default would always help, unless it were application
> configurable defaults. This would definitely help with readability.
The name of the connection factory selects only two things: The JMS
provider, and XA or not. Normally you'll only have a single JMS provider
in your EE container, so specifying it is redundant. But even if you
have multiple, one could be the default.
And I never quite understood, why the XA handling is hidden from the
code, but reintroduced by the name you'll have to use!
> * I think that it would be more consistent with the EJB behavior of
> automatically managing transactions, if the default of the
> JmsConnection#transacted attribute were true.
>
>
> * Maybe it would be easier and suffice if "transacted" were not a
> separate attribute but a fourth acknowledge mode (as I understand
> it, this is what Nigel suggests in JMS_SPEC-45).
>
>
> We'll need to mull on it. I set it to false since I am targetting more
> SE than EE work. I may have read Nigel's comments wrong then, this
> would be cleaner.
Let's hear other voices, then!
> * The JmsCredentials annotation (used literal as well as plain) is
> not really an improvement over the current security situation of JMS
> client code. But the only real solution that I can think of may be
> out of scope, as it's a general EE issue: Every application has some
> identity and required privileges to e.g. send messages to some
> queue. The deployer checks this identity and grants it the requested
> privileges. So the developer only defines what the application
> needs, while the deployer checks and fulfills these needs.
>
>
> This sort of crosses both of my proposals. I really only think of
> credentials in an SE environment. As I go through this more and more, I
> really start wondering if we need a jms.xml deployment descriptor...
Yeah... but that only helps, if there is a separate Assembler role that
configures these. Maybe it would be easier if this would be done via an
appication id signed by the developer and the deployer granting access.
> * Page 5, 2nd "contract" bullet point: Do you really suggest that
> messages that can't be converted for some reason be dropped with
> only an optional waring in some logs?!?
>
> Maybe. Would you expect that they generate an object message that has
> the serialized object as the payload?
No... I want an exception!
> * Page 5, last paragraph, 2nd to last sentence: I just don't get it.
> Why is the message selector supposed to be an interceptor? How it it
> supposed to do the routing, if there are multiple message selectors?
> How is transactionality related?
>
>
> I suppose a message should only be considered delivered if it found a
> matching observer. In this case, an interceptor could be used to
> evaluate if the selector matches the message criteria, and only forward
> to the method if it's valid. Thoughts?
Hmmm... maybe that should just be left to the implementation?
> * Page 6-8, API Changes: I'd prefer to read (eventually commented)
> code for all annotations and enumerations.
>
>
> I was thinking about this as well. I know that the code's sitting in an
> SVN repository:
> http://java.net/projects/jms-spec/sources/repository/show but maybe we
> could take a note from other projects and work in a distributed SCM?
> E.g. github or mercurial? I know that some specs are working outside
> the box with these respects. Should get some feedback from Nigel about
> this first.
I'm perfectly okay with Subversion! I just would have preferred code in
the docs, when it's easier to read than English ;)
Rüdiger