Hi Adam,
On Thu, 7 Jul 2011 11:44:52 +0200, Adam Bien wrote:
> What is actually the definition of POJO? No proxies allowed between or no bytecode extension?
I'd say that a POJO has no dependencies... to be more precise: only on
classes that are in the jar of the POJO itself or in Java SE (or maybe
even only Java ME). Annotations don't count here, as the class can be
loaded even when the annotations are not on the classpath! But the Event
class *does* count.
> I would like to see a strong integration of all Java EE 7 specs and pruning all overlaps.
+1, but it should be possible to use JMS 2.0 in Java SE as well,
shouldn't it?
>> I love CDI, but I only like events. To me they feel somewhat foreign to the DI concept. They look cool, but the little experience I had with them was, that I often had to create a special message object class.
>
> Why not a Qualifier?
> ...
> In all my cases all event classes in CDI are just my domain classes.
> I use Qualifiers as replacement for topic names.
Hmmm... I don't know... E.g.
@Inject
@Create
Event<Customer> createCustomer;
...
createCustomer.fire(new Customer("Joe", "Doe"));
just doesn't look so lean and lightweight to me as
@Inject customerService;
...
customerService.createCustomer("Joe", "Doe"));
does. I'm not religious about that, but maybe it's that I have a
tendency to leave qualifiers for non-functional aspects. I just prefer
to have an explicit method or type for the semantics.
Speaking of topics: Would you place the same customer messages into one
topic to create and another topic to delete them? I'd rather not do that.
>>> Then only an empty interface, annotated with e.g. @JMSSender would be sufficient, right? If yes, then (dynamic) proxy would implement the heavy lifting
>
> One of the first feature requests in CDI 1.1 (Java EE 7) is the support for interception of Abstract classes / interfaces: https://issues.jboss.org/browse/CDI-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589523#comment-12589523
>
> This would also solve this issue in a standard way.
That's a nice feature. But for messages the receiver implements the same
interface that the client calls. I think it would be very confusing to
have an abstract class, then.
>> The interface would contain at least one method. The dynamic proxy would implement the heavy lifting of mapping the method name and the parameters to a JMS message.
>
> Or an interceptor / ServiceHandler. Why to re-invent the wheel?
Dynamic proxy or invocation handler... there'd be the same work to do,
wouldn't it?
On Thu, 7 Jul 2011 14:41:27 +0200, "John D. Ament"
<john.d.ament_at_gmail.com> wrote:
>>>>> > And I don't think that we should force all JMS implementations to run outside of "their" environment, e.g. in plain vanilla Java SE. If we instead would make sure that all JMS client code really runs without any modification in any JMS implementation, that would be a *big* win. If the JMS implementations specify the exact environment they need, clients would be free to choose and change their minds at any time.
>>>>
>>>> What do you mean by " force all JMS implementations to run outside of "their" environment"?
>>>
>>> There was a suggestion on the list to force all JMS implementations run in plain Java SE. I don't think that's a good thing to require from all providers, as they now can simply rely on a lot of their infrastructure.
>> +1.
> I'm not too sure what this means to be honest. If the issue is that a JMS implementation should be bootable in an SE environment, then yes I think that should be included. What that actually boots (e.g. a full web container, EJB container, CDI container, etc) will vary.
I find it difficult to imagine to simply throw some libs into your Java
SE classpath that then boot a Glassfish, JBoss, or whatever. The
essential point IMHO is that the JMS API stays absolutely clear of
those... but the implementations may require them (to be running).
On Thu, 7 Jul 2011 15:26:35 +0200, Adam Bien <abien_at_adam-bien.com> wrote:
> we could use CustomScopes to bind an Event to a session like: @Inject @JMSSessionScoped Event<javax.jms.Message> msgEvent. I would even allow @Inject Event<String> topic. A String should be automatically translated into a TextMessage behind the scenes. You won't be able to set headers that way, but in most cases you are just sending a message without the header anyway.
You could set headers with other annotations. Say you want a
time-to-live header, there could be a @TimeToLive(1000) annotation.
Properties could be set with a generic @MessageProperty("key", "value")
annotation, as long as the value doesn't have to be dynamic... but I
can't see a use-case for that right now.
Regards
Rüdiger