deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <john.d.am...@gmail.com>
Subject Re: DISCUSS DeltaSpike-324
Date Thu, 21 Mar 2013 22:47:47 GMT
Arne,

Not sure I follow.  Typically the only case where you would embed a JMS
implementation is in a Tomcat/Spring configuration.  There are
complications trying to bootstrap a JMS server within an EE container, most
require some JNDI entries to be made, or container provided configuration
(WebSphere, WebLogic, OpenMQ [sort of]).  Others like HornetQ and ActiveMQ
can read configuration purely from a file and start that way.  You'll also
likely run into classloader problems with conflicts between libraries.

Currently the only implementation is OpenMQ.  Since it expects certain JCA
methods to be there, I doubt it's backwards compatible with Java EE 6
containers.

John


On Thu, Mar 21, 2013 at 5:49 PM, Arne Limburg <arne.limburg@openknowledge.de
> wrote:

> We should find out if one can simply use a JMS 2.0 implementation and put
> it into an deployment. If that will be possible, we would not need to
> implement it.
>
> Cheers,
> Arne
>
> Am 21.03.13 22:34 schrieb "Mark Struberg" unter <struberg@yahoo.de>:
>
> >I tend to lean towards +1 simply because EE-7 containers will take
> >another year (or 2) to become used in projects.
> >
> >I just think we should first close a few tasks before we open new ones.
> >
> >LieGrue,
> >strub
> >
> >
> >
> >
> >----- Original Message -----
> >> From: John D. Ament <john.d.ament@gmail.com>
> >> To: deltaspike-dev@incubator.apache.org
> >> Cc:
> >> Sent: Thursday, March 21, 2013 6:09 PM
> >> Subject: Re: DISCUSS DeltaSpike-324
> >>
> >> Romain,
> >>
> >> Generally, I'm mixed about these.  However I think there's some pretty
> >> good
> >> benefits.  For an application developer, maybe none of the other JMS 2
> >> features are useful to you (the bulk of the feature went into CDI
> >>support,
> >> app server integration, and documentation clean up).  You don't want to
> >> move off of TomEE 1.5.x to TomEE Y (which could support Java EE 7 Web
> >> Profile) due to downtime in your application.  There's also lead time
> >> required to impelement JMS 2/Java EE 7 features in your application
> >>server,
> >> but perhaps you don't want to or need to wait for the whole thing.
> >>
> >> This solution would be DS oriented, I believe requires TransactionScoped
> >> (which could require the transaction classes be moved away from
> >> persistence) to operate properly.
> >>
> >> There's also the case of using DeltaSpike as your CDI-JMS
> >>implementation if
> >> you were a JMS implementer.  I haven't reached out to communities such
> >>as
> >> Apache ActiveMQ or HornetQ to see input here; I know the current
> >>GlassFish
> >> implementation calls their lower level directly (and not by wrapping the
> >> JMS APIs).
> >>
> >> John
> >>
> >>
> >> On Thu, Mar 21, 2013 at 12:30 PM, Romain Manni-Bucau
> >> <rmannibucau@gmail.com>wrote:
> >>
> >>>  Hi
> >>>
> >>>  i'm globally -1 for redoing something which will exist somewhere else
> >>>  (basically if somebody wants JavaEE just let him use JavaEE, CDI
> >> doesn't
> >>>  need the full stack IMO). Was my point for JPA, more again on JMS.
> >>>
> >>>  It is great to add feature before the specs not once it is (or almost)
> >>>  done.
> >>>
> >>>  Maybe i didnt fully get what you want to do so maybe share some
> >>>pastebin to
> >>>  be sure we speak about the same stuff.
> >>>
> >>>  *Romain Manni-Bucau*
> >>>  *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> >>>  *Blog: **http://rmannibucau.wordpress.com/*<
> >>>  http://rmannibucau.wordpress.com/>
> >>>  *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >>>  *Github: https://github.com/rmannibucau*
> >>>
> >>>
> >>>
> >>>  2013/3/21 John D. Ament <john.d.ament@gmail.com>
> >>>
> >>>  > All,
> >>>  >
> >>>  > I'd like to open the floor to discussion for porting JMS 2
> >> features to
> >>>  > DeltaSpike, specifically the features that added some CDI
> >>>capabilities
> >> to
> >>>  > JMS.
> >>>  >
> >>>  > Details of my rough proposal are here:
> >>>  > https://issues.apache.org/jira/browse/DELTASPIKE-324
> >>>  >
> >>>  > Importing these features start to deprecate functionality in Seam
> >>>JMS
> >>>  > (ideal).  These features would give access to an API very similar
> >>>to
> >> the
> >>>  > JMS2 API around CDI injection.
> >>>  >
> >>>  > Some limitations:
> >>>  >
> >>>  > - This would not be a JMS implementation, simply an inspired
> >>>interface
> >>>  for
> >>>  > use in Java EE 6/JMS 1.x that leveraged CDI injection based on the
> >> rules
> >>>  > for CDI injection of these interfaces.  We would bring in very
> >>>similar
> >>>  > annotations that supported the injection of the three target types.
> >>>  >
> >>>  > - Cannot use the exact interface, since the interface implements
> >>>  > AutoCloseable which is a Java SE 7 interface.  DeltaSpike uses Java
> >>>SE
> >> 6
> >>>  > for a compiler.
> >>>  >
> >>>  > - Internally these would have to use the current JMS interfaces of
> >>>  > connection, session.
> >>>  >
> >>>  > - Testing would be feasible but require a full Java EE container
> >>>(e.g.
> >> no
> >>>  > testing in Weld/OWB directly) that supported deployment of
> >> destinations
> >>>  at
> >>>  > runtime.  Since this doesn't touch MDBs we can manually read from
> >> the
> >>>  > destination.
> >>>  >
> >>>  > John
> >>>  >
> >>>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message