You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "John D. Ament" <jo...@gmail.com> on 2013/03/21 15:12:49 UTC
DISCUSS DeltaSpike-324
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
Re: DISCUSS DeltaSpike-324
Posted by hantsy <ha...@yahoo.com.cn>.
I think make the good parts of JMS2 (and other Java EE7 specs) as
consideration in Deltaspike 1.0, but NOT a must, if possible provide
equivalent implementations in Deltaspike. In future, add adapters to
use Java EE 7 when switch to Java EE 7 development.
I hope the 1.0 can be released as soon as possible.
Hantsy
On 3/24/2013 06:57, Jason Porter wrote:
> As much as I want to see JMS added, I agree it should be after 1.0. We need
> to get this pushed out.
>
>
> On Sat, Mar 23, 2013 at 4:22 PM, Gerhard Petracek <
> gerhard.petracek@gmail.com> wrote:
>
>> @ romain: +1
>>
>> regards,
>> gerhard
>>
>>
>> 2013/3/23 Romain Manni-Bucau <rm...@gmail.com>
>>
>>> yes but JMS is clearly not the most used
>>>
>>> can't we push it for the > 1.0?
>>>
>>> users really wait the first 1.0 to use DS and adding JMS now simply looks
>>> like forgetting more common use cases
>>>
>>> *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/23 Gerhard Petracek <ge...@gmail.com>
>>>
>>>> hi @ all,
>>>>
>>>> imo it's more a basic question.
>>>> if we do it for jms 2, we also have to (/should) do it for other
>>>> specifications like bv 1.1
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>>
>>>> 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
>>>>
>>>>> Ill rephrase a bit. I m rather -0 about it and -1 since a lot of
>> others
>>>>> stuff are needed before.
>>>>> Le 21 mars 2013 22:50, "Arne Limburg" <arne.limburg@openknowledge.de
>>> a
>>>>> écrit :
>>>>>
>>>>>> 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 <jo...@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
>>>>>>>> <rm...@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 <jo...@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
>>>>>>>>> >
>>>>>>>>>
>>>>>>
>
>
Re: DISCUSS DeltaSpike-324
Posted by Jason Porter <li...@gmail.com>.
As much as I want to see JMS added, I agree it should be after 1.0. We need
to get this pushed out.
On Sat, Mar 23, 2013 at 4:22 PM, Gerhard Petracek <
gerhard.petracek@gmail.com> wrote:
> @ romain: +1
>
> regards,
> gerhard
>
>
> 2013/3/23 Romain Manni-Bucau <rm...@gmail.com>
>
> > yes but JMS is clearly not the most used
> >
> > can't we push it for the > 1.0?
> >
> > users really wait the first 1.0 to use DS and adding JMS now simply looks
> > like forgetting more common use cases
> >
> > *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/23 Gerhard Petracek <ge...@gmail.com>
> >
> > > hi @ all,
> > >
> > > imo it's more a basic question.
> > > if we do it for jms 2, we also have to (/should) do it for other
> > > specifications like bv 1.1
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
> > >
> > > > Ill rephrase a bit. I m rather -0 about it and -1 since a lot of
> others
> > > > stuff are needed before.
> > > > Le 21 mars 2013 22:50, "Arne Limburg" <arne.limburg@openknowledge.de
> >
> > a
> > > > écrit :
> > > >
> > > > > 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 <jo...@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
> > > > > >> <rm...@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 <jo...@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
> > > > > >>> >
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
--
Jason Porter
http://en.gravatar.com/lightguardjp
Re: DISCUSS DeltaSpike-324
Posted by Gerhard Petracek <ge...@gmail.com>.
@ romain: +1
regards,
gerhard
2013/3/23 Romain Manni-Bucau <rm...@gmail.com>
> yes but JMS is clearly not the most used
>
> can't we push it for the > 1.0?
>
> users really wait the first 1.0 to use DS and adding JMS now simply looks
> like forgetting more common use cases
>
> *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/23 Gerhard Petracek <ge...@gmail.com>
>
> > hi @ all,
> >
> > imo it's more a basic question.
> > if we do it for jms 2, we also have to (/should) do it for other
> > specifications like bv 1.1
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
> >
> > > Ill rephrase a bit. I m rather -0 about it and -1 since a lot of others
> > > stuff are needed before.
> > > Le 21 mars 2013 22:50, "Arne Limburg" <ar...@openknowledge.de>
> a
> > > écrit :
> > >
> > > > 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 <st...@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 <jo...@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
> > > > >> <rm...@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 <jo...@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
> > > > >>> >
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: DISCUSS DeltaSpike-324
Posted by "John D. Ament" <jo...@gmail.com>.
Mark,
Agreed about you and Gerhard. In the first 10 months DS was in incubation,
I was unfortunately working on a project 70-80 hrs/week. With a 1 month
overlap, then the last 5 months did something even sillier. Since then
though I've been trying to play catch up with where DS ended up (hence the
surge in emails). This is also why I took your WindowContext issue and
broke it down further, smaller digestable chunks. Hopefully this will help
get it implemented faster.
John
On Mon, Mar 25, 2013 at 6:09 PM, Mark Struberg <st...@yahoo.de> wrote:
> well, a roadmap always depends on how much one can spend.
> The roadmap for 0.4 originally have been JSF support. This is still the
> case.
> But with only Gerhard and me doing 80% of the commits it's obvious that we
> are not that fast.
>
> So please just help with the features as well!
>
> @Pete: it's pretty easy: 0.4 basic JSF support and basic JPA support, 0.5
> even more JSF support and JPA support.
>
> And then 1.0 is just around the corner.
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
> > From: Cody Lerum <co...@gmail.com>
> > To: deltaspike-dev@incubator.apache.org
> > Cc:
> > Sent: Monday, March 25, 2013 3:07 PM
> > Subject: Re: DISCUSS DeltaSpike-324
> >
> > +1
> > On Mar 25, 2013 8:04 AM, "Nicklas Karlsson" <ni...@gmail.com>
> > wrote:
> >
> >> I'm currently in the process of porting an application from Seam3 to
> >> DeltaSpike, with a clear roadmap I might be able to spend some work
> hours
> >> in getting stuff forward.
> >>
> >>
> >> On Mon, Mar 25, 2013 at 3:58 PM, Pete Muir <pm...@redhat.com> wrote:
> >>
> >> > Hi all,
> >> >
> >> > At the moment it's really hard for Red Hat to fund more people to
> > work on
> >> > DeltaSpike. Without a clear roadmap, and a regular release schedule
> > (e.g.
> >> > time boxed) it's really hard for us to justify more people for
> > DeltaSpike
> >> > as we can't see how many people we should offer to get to the
> > features
> >> our
> >> > customers need, nor can we see when those features will be available
> > for
> >> > customers to start using.
> >> >
> >> > Last time we asked to agree on a roadmap, this group decided it
> > wasn't
> >> > something that it wanted to do. If we are now able to agree on a
> > roadmap
> >> > with some sort of regular release schedule (even just having approx
> > dates
> >> > for a release is good enough) then I can see how I can reprioritise
> > our
> >> > current work, and get some more help for DeltaSpike, and hopefully
> get
> > us
> >> > closer to 1.0, which is really what I think we are all after (I'm
> > not
> >> sure
> >> > if I will succeed, but right now it's not really worth me even
> > trying).
> >> >
> >> > Pete
> >> >
> >> > On 24 Mar 2013, at 18:33, Romain Manni-Bucau
> > <rm...@gmail.com>
> >> > wrote:
> >> >
> >> > > I did a JUG this week with a part on DS and was the main question
> > asked
> >> > > with those words "when will it be usable?"...kind of
> > sad. Releasing
> >> even
> >> > in
> >> > > alpha/beta is better IMO.
> >> > > Le 24 mars 2013 19:29, "Jason Porter"
> > <li...@gmail.com> a
> >> écrit
> >> > :
> >> > >
> >> > >> +1 glad I'm not the only one asking for a roadmap now.
> >> > >> —
> >> > >> Sent from Mailbox for iPhone
> >> > >>
> >> > >> On Sun, Mar 24, 2013 at 11:54 AM, Romain Manni-Bucau
> >> > >> <rm...@gmail.com> wrote:
> >> > >>
> >> > >>> Do we already have a roadmap? I think we should define
> > one by
> >> iteration
> >> > >>> (+handle a backlog if we want).
> >> > >>> I can help on cdi query part if needed (jsf is still a
> > bit too new
> >> for
> >> > >> me).
> >> > >>> Le 24 mars 2013 18:49, "Gerhard Petracek" <
> >> gerhard.petracek@gmail.com>
> >> > a
> >> > >>> écrit :
> >> > >>>> hi john,
> >> > >>>>
> >> > >>>> we can't keep it currently (i'm also unhappy
> > about it), because if
> >> > only
> >> > >> 2-3
> >> > >>>> people help on a >regular< basis [1], you have
> > to wait until they
> >> have
> >> > >>>> time.
> >> > >>>> it isn't only about unassigned issues. e.g. not
> > that many help with
> >> > >> writing
> >> > >>>> tests and examples, writing/reviewing javadoc and
> > documentation.
> >> > >>>>
> >> > >>>> even the graduation process takes (very) long.
> >> > >>>> that might be a big blocker for some users.
> >> > >>>> at least codi had several users way before v1 (and
> > for sure even
> >> more
> >> > >> after
> >> > >>>> v1).
> >> > >>>> however, we would lose more users, if we release v1
> > which isn't
> >> ready.
> >> > >>>>
> >> > >>>>> imo< our goal for v1 should be >at
> > least< everything (which we know
> >> > >>>> already) we need for improving the java-ee
> > web-profile as well as a
> >> > >> stable
> >> > >>>> api and spi.
> >> > >>>>
> >> > >>>> regards,
> >> > >>>> gerhard
> >> > >>>>
> >> > >>>> [1]
> > https://github.com/apache/incubator-deltaspike/contributors
> >> > >>>>
> >> > >>>>
> >> > >>>>
> >> > >>>> 2013/3/24 Romain Manni-Bucau
> > <rm...@gmail.com>
> >> > >>>>
> >> > >>>>> I get you and think we agree behund words. My
> > main issue is our 0.4
> >> > is
> >> > >>>> not
> >> > >>>>> ready to be released and still doesnt contain
> > what users are
> >> waiting
> >> > >>>> for...
> >> > >>>>>
> >> > >>>>> When i spoke about > 1.0 just understand when
> > last release answer
> >> > >> basic
> >> > >>>>> needs
> >> > >>>>> Le 24 mars 2013 16:49, "John D. Ament"
> > <jo...@gmail.com> a
> >> > >> écrit
> >> > >>>> :
> >> > >>>>>
> >> > >>>>>> Romain,
> >> > >>>>>>
> >> > >>>>>> I'm not sure what to tell you. One of
> > our founding statements was
> >> > >>>>> release
> >> > >>>>>> early and often. I'm not sure why we
> > haven't stuck to that.
> >> > >>>>> Personally, I
> >> > >>>>>> think we have failed to do that. We probably
> > have too many
> >> features
> >> > >>>> in a
> >> > >>>>>> single release/ not much release
> > planning/attempt to release
> >> > >> everything
> >> > >>>>> as
> >> > >>>>>> one big release rather than more modular in
> > nature. Those are
> >> just
> >> > >>>>>> thoughts.
> >> > >>>>>>
> >> > >>>>>> As I already stated, I don't want this in
> > 0.4. But I don't think
> >> > >> it's
> >> > >>>>>> appropriate to stick this in after 1.0, who
> > knows when that will
> >> > >> be. I
> >> > >>>>>> would love to see this in 0.5, already have
> > prototypes working.
> >> My
> >> > >>>>> biggest
> >> > >>>>>> issue, as I was trying to raise in the other
> > thread, is that when
> >> > >>>> people
> >> > >>>>>> look at the issue list out there, generally
> > the candidates to work
> >> > >> on
> >> > >>>> are
> >> > >>>>>> the unassigned issues. If 80% of what we
> > have out there is
> >> > >> assigned,
> >> > >>>>> then
> >> > >>>>>> it's assumed someone's work on it.
> > If it's assigned to someone
> >> and
> >> > >>>>> they're
> >> > >>>>>> not working on it, that's probably an
> > issue that needs to be
> >> > >> addressed.
> >> > >>>>> As
> >> > >>>>>> far as I can tell, of the 10 unassigned
> > issues out there, none of
> >> > >> them
> >> > >>>>> are
> >> > >>>>>> comprehensible enough (other than the one I
> > already worked on) to
> >> be
> >> > >>>>> worked
> >> > >>>>>> through. So I'm not sure, maybe it's
> > an issue of perception, but
> >> I
> >> > >>>> don't
> >> > >>>>>> think we have a large pile of open work for
> > future releases.
> >> > >>>>>>
> >> > >>>>>> John
> >> > >>>>>>
> >> > >>>>>>
> >> > >>>>>> On Sun, Mar 24, 2013 at 11:19 AM, Romain
> > Manni-Bucau
> >> > >>>>>> <rm...@gmail.com>wrote:
> >> > >>>>>>
> >> > >>>>>>> Sure but we cant start everything,
> > finishing nothing...our rare
> >> > >>>>> releases
> >> > >>>>>>> are already a pain for users.
> >> > >>>>>>>
> >> > >>>>>>> We need jsf + if possible cdi query for
> > 0.4 IMO then i agree rest
> >> > >>>>> helpers
> >> > >>>>>>> are a must have (some tools around jaxrs
> > client part can be
> >> great)
> >> > >>>>> etc...
> >> > >>>>>>> Le 24 mars 2013 16:13, "John D.
> > Ament" <jo...@gmail.com>
> >> a
> >> > >>>>> écrit
> >> > >>>>>> :
> >> > >>>>>>>
> >> > >>>>>>>> Romain,
> >> > >>>>>>>>
> >> > >>>>>>>> My only issue with this is that I
> > don't think we've mapped out
> >> > >> what
> >> > >>>>> the
> >> > >>>>>>>> common use cases are (at least based
> > on the email I sent out).
> >> > >> If
> >> > >>>>>> we're
> >> > >>>>>>>> favoring JSF, we're neglecting
> > the growing population of REST
> >> > >> APIs
> >> > >>>>> for
> >> > >>>>>>> rich
> >> > >>>>>>>> javascript clients (from UI).
> >> > >>>>>>>>
> >> > >>>>>>>>
> >> > >>>>>>>> On Sat, Mar 23, 2013 at 6:04 PM,
> > Romain Manni-Bucau
> >> > >>>>>>>> <rm...@gmail.com>wrote:
> >> > >>>>>>>>
> >> > >>>>>>>>> yes but JMS is clearly not the
> > most used
> >> > >>>>>>>>>
> >> > >>>>>>>>> can't we push it for the >
> > 1.0?
> >> > >>>>>>>>>
> >> > >>>>>>>>> users really wait the first 1.0
> > to use DS and adding JMS now
> >> > >>>> simply
> >> > >>>>>>> looks
> >> > >>>>>>>>> like forgetting more common use
> > cases
> >> > >>>>>>>>>
> >> > >>>>>>>>> *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/23 Gerhard Petracek
> > <ge...@gmail.com>
> >> > >>>>>>>>>
> >> > >>>>>>>>>> hi @ all,
> >> > >>>>>>>>>>
> >> > >>>>>>>>>> imo it's more a basic
> > question.
> >> > >>>>>>>>>> if we do it for jms 2, we
> > also have to (/should) do it for
> >> > >>>> other
> >> > >>>>>>>>>> specifications like bv 1.1
> >> > >>>>>>>>>>
> >> > >>>>>>>>>> regards,
> >> > >>>>>>>>>> gerhard
> >> > >>>>>>>>>>
> >> > >>>>>>>>>>
> >> > >>>>>>>>>>
> >> > >>>>>>>>>> 2013/3/21 Romain Manni-Bucau
> > <rm...@gmail.com>
> >> > >>>>>>>>>>
> >> > >>>>>>>>>>> Ill rephrase a bit. I m
> > rather -0 about it and -1 since a
> >> > >> lot
> >> > >>>>> of
> >> > >>>>>>>> others
> >> > >>>>>>>>>>> stuff are needed before.
> >> > >>>>>>>>>>> Le 21 mars 2013 22:50,
> > "Arne Limburg" <
> >> > >>>>>>> arne.limburg@openknowledge.de
> >> > >>>>>>>>>
> >> > >>>>>>>>> a
> >> > >>>>>>>>>>> écrit :
> >> > >>>>>>>>>>>
> >> > >>>>>>>>>>>> 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 <jo...@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
> >> > >>>>>>>>>>>>>>
> > <rm...@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 <jo...@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
> >> > >>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>
> >> > >>>>>>>>>>
> >> > >>>>>>>>>
> >> > >>>>>>>>
> >> > >>>>>>>
> >> > >>>>>>
> >> > >>>>>
> >> > >>>>
> >> >
> >> >
> >>
> >>
> >> --
> >> Nicklas Karlsson, +358 40 5062266
> >> Vaakunatie 10 as 7, 20780 Kaarina
> >>
> >
>
Re: DISCUSS DeltaSpike-324
Posted by Mark Struberg <st...@yahoo.de>.
well, a roadmap always depends on how much one can spend.
The roadmap for 0.4 originally have been JSF support. This is still the case.
But with only Gerhard and me doing 80% of the commits it's obvious that we are not that fast.
So please just help with the features as well!
@Pete: it's pretty easy: 0.4 basic JSF support and basic JPA support, 0.5 even more JSF support and JPA support.
And then 1.0 is just around the corner.
LieGrue,
strub
----- Original Message -----
> From: Cody Lerum <co...@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc:
> Sent: Monday, March 25, 2013 3:07 PM
> Subject: Re: DISCUSS DeltaSpike-324
>
> +1
> On Mar 25, 2013 8:04 AM, "Nicklas Karlsson" <ni...@gmail.com>
> wrote:
>
>> I'm currently in the process of porting an application from Seam3 to
>> DeltaSpike, with a clear roadmap I might be able to spend some work hours
>> in getting stuff forward.
>>
>>
>> On Mon, Mar 25, 2013 at 3:58 PM, Pete Muir <pm...@redhat.com> wrote:
>>
>> > Hi all,
>> >
>> > At the moment it's really hard for Red Hat to fund more people to
> work on
>> > DeltaSpike. Without a clear roadmap, and a regular release schedule
> (e.g.
>> > time boxed) it's really hard for us to justify more people for
> DeltaSpike
>> > as we can't see how many people we should offer to get to the
> features
>> our
>> > customers need, nor can we see when those features will be available
> for
>> > customers to start using.
>> >
>> > Last time we asked to agree on a roadmap, this group decided it
> wasn't
>> > something that it wanted to do. If we are now able to agree on a
> roadmap
>> > with some sort of regular release schedule (even just having approx
> dates
>> > for a release is good enough) then I can see how I can reprioritise
> our
>> > current work, and get some more help for DeltaSpike, and hopefully get
> us
>> > closer to 1.0, which is really what I think we are all after (I'm
> not
>> sure
>> > if I will succeed, but right now it's not really worth me even
> trying).
>> >
>> > Pete
>> >
>> > On 24 Mar 2013, at 18:33, Romain Manni-Bucau
> <rm...@gmail.com>
>> > wrote:
>> >
>> > > I did a JUG this week with a part on DS and was the main question
> asked
>> > > with those words "when will it be usable?"...kind of
> sad. Releasing
>> even
>> > in
>> > > alpha/beta is better IMO.
>> > > Le 24 mars 2013 19:29, "Jason Porter"
> <li...@gmail.com> a
>> écrit
>> > :
>> > >
>> > >> +1 glad I'm not the only one asking for a roadmap now.
>> > >> —
>> > >> Sent from Mailbox for iPhone
>> > >>
>> > >> On Sun, Mar 24, 2013 at 11:54 AM, Romain Manni-Bucau
>> > >> <rm...@gmail.com> wrote:
>> > >>
>> > >>> Do we already have a roadmap? I think we should define
> one by
>> iteration
>> > >>> (+handle a backlog if we want).
>> > >>> I can help on cdi query part if needed (jsf is still a
> bit too new
>> for
>> > >> me).
>> > >>> Le 24 mars 2013 18:49, "Gerhard Petracek" <
>> gerhard.petracek@gmail.com>
>> > a
>> > >>> écrit :
>> > >>>> hi john,
>> > >>>>
>> > >>>> we can't keep it currently (i'm also unhappy
> about it), because if
>> > only
>> > >> 2-3
>> > >>>> people help on a >regular< basis [1], you have
> to wait until they
>> have
>> > >>>> time.
>> > >>>> it isn't only about unassigned issues. e.g. not
> that many help with
>> > >> writing
>> > >>>> tests and examples, writing/reviewing javadoc and
> documentation.
>> > >>>>
>> > >>>> even the graduation process takes (very) long.
>> > >>>> that might be a big blocker for some users.
>> > >>>> at least codi had several users way before v1 (and
> for sure even
>> more
>> > >> after
>> > >>>> v1).
>> > >>>> however, we would lose more users, if we release v1
> which isn't
>> ready.
>> > >>>>
>> > >>>>> imo< our goal for v1 should be >at
> least< everything (which we know
>> > >>>> already) we need for improving the java-ee
> web-profile as well as a
>> > >> stable
>> > >>>> api and spi.
>> > >>>>
>> > >>>> regards,
>> > >>>> gerhard
>> > >>>>
>> > >>>> [1]
> https://github.com/apache/incubator-deltaspike/contributors
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> 2013/3/24 Romain Manni-Bucau
> <rm...@gmail.com>
>> > >>>>
>> > >>>>> I get you and think we agree behund words. My
> main issue is our 0.4
>> > is
>> > >>>> not
>> > >>>>> ready to be released and still doesnt contain
> what users are
>> waiting
>> > >>>> for...
>> > >>>>>
>> > >>>>> When i spoke about > 1.0 just understand when
> last release answer
>> > >> basic
>> > >>>>> needs
>> > >>>>> Le 24 mars 2013 16:49, "John D. Ament"
> <jo...@gmail.com> a
>> > >> écrit
>> > >>>> :
>> > >>>>>
>> > >>>>>> Romain,
>> > >>>>>>
>> > >>>>>> I'm not sure what to tell you. One of
> our founding statements was
>> > >>>>> release
>> > >>>>>> early and often. I'm not sure why we
> haven't stuck to that.
>> > >>>>> Personally, I
>> > >>>>>> think we have failed to do that. We probably
> have too many
>> features
>> > >>>> in a
>> > >>>>>> single release/ not much release
> planning/attempt to release
>> > >> everything
>> > >>>>> as
>> > >>>>>> one big release rather than more modular in
> nature. Those are
>> just
>> > >>>>>> thoughts.
>> > >>>>>>
>> > >>>>>> As I already stated, I don't want this in
> 0.4. But I don't think
>> > >> it's
>> > >>>>>> appropriate to stick this in after 1.0, who
> knows when that will
>> > >> be. I
>> > >>>>>> would love to see this in 0.5, already have
> prototypes working.
>> My
>> > >>>>> biggest
>> > >>>>>> issue, as I was trying to raise in the other
> thread, is that when
>> > >>>> people
>> > >>>>>> look at the issue list out there, generally
> the candidates to work
>> > >> on
>> > >>>> are
>> > >>>>>> the unassigned issues. If 80% of what we
> have out there is
>> > >> assigned,
>> > >>>>> then
>> > >>>>>> it's assumed someone's work on it.
> If it's assigned to someone
>> and
>> > >>>>> they're
>> > >>>>>> not working on it, that's probably an
> issue that needs to be
>> > >> addressed.
>> > >>>>> As
>> > >>>>>> far as I can tell, of the 10 unassigned
> issues out there, none of
>> > >> them
>> > >>>>> are
>> > >>>>>> comprehensible enough (other than the one I
> already worked on) to
>> be
>> > >>>>> worked
>> > >>>>>> through. So I'm not sure, maybe it's
> an issue of perception, but
>> I
>> > >>>> don't
>> > >>>>>> think we have a large pile of open work for
> future releases.
>> > >>>>>>
>> > >>>>>> John
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> On Sun, Mar 24, 2013 at 11:19 AM, Romain
> Manni-Bucau
>> > >>>>>> <rm...@gmail.com>wrote:
>> > >>>>>>
>> > >>>>>>> Sure but we cant start everything,
> finishing nothing...our rare
>> > >>>>> releases
>> > >>>>>>> are already a pain for users.
>> > >>>>>>>
>> > >>>>>>> We need jsf + if possible cdi query for
> 0.4 IMO then i agree rest
>> > >>>>> helpers
>> > >>>>>>> are a must have (some tools around jaxrs
> client part can be
>> great)
>> > >>>>> etc...
>> > >>>>>>> Le 24 mars 2013 16:13, "John D.
> Ament" <jo...@gmail.com>
>> a
>> > >>>>> écrit
>> > >>>>>> :
>> > >>>>>>>
>> > >>>>>>>> Romain,
>> > >>>>>>>>
>> > >>>>>>>> My only issue with this is that I
> don't think we've mapped out
>> > >> what
>> > >>>>> the
>> > >>>>>>>> common use cases are (at least based
> on the email I sent out).
>> > >> If
>> > >>>>>> we're
>> > >>>>>>>> favoring JSF, we're neglecting
> the growing population of REST
>> > >> APIs
>> > >>>>> for
>> > >>>>>>> rich
>> > >>>>>>>> javascript clients (from UI).
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>> On Sat, Mar 23, 2013 at 6:04 PM,
> Romain Manni-Bucau
>> > >>>>>>>> <rm...@gmail.com>wrote:
>> > >>>>>>>>
>> > >>>>>>>>> yes but JMS is clearly not the
> most used
>> > >>>>>>>>>
>> > >>>>>>>>> can't we push it for the >
> 1.0?
>> > >>>>>>>>>
>> > >>>>>>>>> users really wait the first 1.0
> to use DS and adding JMS now
>> > >>>> simply
>> > >>>>>>> looks
>> > >>>>>>>>> like forgetting more common use
> cases
>> > >>>>>>>>>
>> > >>>>>>>>> *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/23 Gerhard Petracek
> <ge...@gmail.com>
>> > >>>>>>>>>
>> > >>>>>>>>>> hi @ all,
>> > >>>>>>>>>>
>> > >>>>>>>>>> imo it's more a basic
> question.
>> > >>>>>>>>>> if we do it for jms 2, we
> also have to (/should) do it for
>> > >>>> other
>> > >>>>>>>>>> specifications like bv 1.1
>> > >>>>>>>>>>
>> > >>>>>>>>>> regards,
>> > >>>>>>>>>> gerhard
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>> 2013/3/21 Romain Manni-Bucau
> <rm...@gmail.com>
>> > >>>>>>>>>>
>> > >>>>>>>>>>> Ill rephrase a bit. I m
> rather -0 about it and -1 since a
>> > >> lot
>> > >>>>> of
>> > >>>>>>>> others
>> > >>>>>>>>>>> stuff are needed before.
>> > >>>>>>>>>>> Le 21 mars 2013 22:50,
> "Arne Limburg" <
>> > >>>>>>> arne.limburg@openknowledge.de
>> > >>>>>>>>>
>> > >>>>>>>>> a
>> > >>>>>>>>>>> écrit :
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>> 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 <jo...@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
>> > >>>>>>>>>>>>>>
> <rm...@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 <jo...@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
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>
>> > >>>>>>
>> > >>>>>
>> > >>>>
>> >
>> >
>>
>>
>> --
>> Nicklas Karlsson, +358 40 5062266
>> Vaakunatie 10 as 7, 20780 Kaarina
>>
>
Re: DISCUSS DeltaSpike-324
Posted by "John D. Ament" <jo...@gmail.com>.
Agreed, getting a roadmap will help everyone. Users can know when they can
move a feature from CODI or Seam3 to DS. Committers can know which issues
have top priority in a release and know when to work on it.
RE getting more people, I've been trying to spend more time on this.
John
On Mon, Mar 25, 2013 at 10:07 AM, Cody Lerum <co...@gmail.com> wrote:
> +1
> On Mar 25, 2013 8:04 AM, "Nicklas Karlsson" <ni...@gmail.com> wrote:
>
> > I'm currently in the process of porting an application from Seam3 to
> > DeltaSpike, with a clear roadmap I might be able to spend some work hours
> > in getting stuff forward.
> >
> >
> > On Mon, Mar 25, 2013 at 3:58 PM, Pete Muir <pm...@redhat.com> wrote:
> >
> > > Hi all,
> > >
> > > At the moment it's really hard for Red Hat to fund more people to work
> on
> > > DeltaSpike. Without a clear roadmap, and a regular release schedule
> (e.g.
> > > time boxed) it's really hard for us to justify more people for
> DeltaSpike
> > > as we can't see how many people we should offer to get to the features
> > our
> > > customers need, nor can we see when those features will be available
> for
> > > customers to start using.
> > >
> > > Last time we asked to agree on a roadmap, this group decided it wasn't
> > > something that it wanted to do. If we are now able to agree on a
> roadmap
> > > with some sort of regular release schedule (even just having approx
> dates
> > > for a release is good enough) then I can see how I can reprioritise our
> > > current work, and get some more help for DeltaSpike, and hopefully get
> us
> > > closer to 1.0, which is really what I think we are all after (I'm not
> > sure
> > > if I will succeed, but right now it's not really worth me even trying).
> > >
> > > Pete
> > >
> > > On 24 Mar 2013, at 18:33, Romain Manni-Bucau <rm...@gmail.com>
> > > wrote:
> > >
> > > > I did a JUG this week with a part on DS and was the main question
> asked
> > > > with those words "when will it be usable?"...kind of sad. Releasing
> > even
> > > in
> > > > alpha/beta is better IMO.
> > > > Le 24 mars 2013 19:29, "Jason Porter" <li...@gmail.com> a
> > écrit
> > > :
> > > >
> > > >> +1 glad I'm not the only one asking for a roadmap now.
> > > >> —
> > > >> Sent from Mailbox for iPhone
> > > >>
> > > >> On Sun, Mar 24, 2013 at 11:54 AM, Romain Manni-Bucau
> > > >> <rm...@gmail.com> wrote:
> > > >>
> > > >>> Do we already have a roadmap? I think we should define one by
> > iteration
> > > >>> (+handle a backlog if we want).
> > > >>> I can help on cdi query part if needed (jsf is still a bit too new
> > for
> > > >> me).
> > > >>> Le 24 mars 2013 18:49, "Gerhard Petracek" <
> > gerhard.petracek@gmail.com>
> > > a
> > > >>> écrit :
> > > >>>> hi john,
> > > >>>>
> > > >>>> we can't keep it currently (i'm also unhappy about it), because if
> > > only
> > > >> 2-3
> > > >>>> people help on a >regular< basis [1], you have to wait until they
> > have
> > > >>>> time.
> > > >>>> it isn't only about unassigned issues. e.g. not that many help
> with
> > > >> writing
> > > >>>> tests and examples, writing/reviewing javadoc and documentation.
> > > >>>>
> > > >>>> even the graduation process takes (very) long.
> > > >>>> that might be a big blocker for some users.
> > > >>>> at least codi had several users way before v1 (and for sure even
> > more
> > > >> after
> > > >>>> v1).
> > > >>>> however, we would lose more users, if we release v1 which isn't
> > ready.
> > > >>>>
> > > >>>>> imo< our goal for v1 should be >at least< everything (which we
> know
> > > >>>> already) we need for improving the java-ee web-profile as well as
> a
> > > >> stable
> > > >>>> api and spi.
> > > >>>>
> > > >>>> regards,
> > > >>>> gerhard
> > > >>>>
> > > >>>> [1] https://github.com/apache/incubator-deltaspike/contributors
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> 2013/3/24 Romain Manni-Bucau <rm...@gmail.com>
> > > >>>>
> > > >>>>> I get you and think we agree behund words. My main issue is our
> 0.4
> > > is
> > > >>>> not
> > > >>>>> ready to be released and still doesnt contain what users are
> > waiting
> > > >>>> for...
> > > >>>>>
> > > >>>>> When i spoke about > 1.0 just understand when last release answer
> > > >> basic
> > > >>>>> needs
> > > >>>>> Le 24 mars 2013 16:49, "John D. Ament" <jo...@gmail.com>
> a
> > > >> écrit
> > > >>>> :
> > > >>>>>
> > > >>>>>> Romain,
> > > >>>>>>
> > > >>>>>> I'm not sure what to tell you. One of our founding statements
> was
> > > >>>>> release
> > > >>>>>> early and often. I'm not sure why we haven't stuck to that.
> > > >>>>> Personally, I
> > > >>>>>> think we have failed to do that. We probably have too many
> > features
> > > >>>> in a
> > > >>>>>> single release/ not much release planning/attempt to release
> > > >> everything
> > > >>>>> as
> > > >>>>>> one big release rather than more modular in nature. Those are
> > just
> > > >>>>>> thoughts.
> > > >>>>>>
> > > >>>>>> As I already stated, I don't want this in 0.4. But I don't
> think
> > > >> it's
> > > >>>>>> appropriate to stick this in after 1.0, who knows when that will
> > > >> be. I
> > > >>>>>> would love to see this in 0.5, already have prototypes working.
> > My
> > > >>>>> biggest
> > > >>>>>> issue, as I was trying to raise in the other thread, is that
> when
> > > >>>> people
> > > >>>>>> look at the issue list out there, generally the candidates to
> work
> > > >> on
> > > >>>> are
> > > >>>>>> the unassigned issues. If 80% of what we have out there is
> > > >> assigned,
> > > >>>>> then
> > > >>>>>> it's assumed someone's work on it. If it's assigned to someone
> > and
> > > >>>>> they're
> > > >>>>>> not working on it, that's probably an issue that needs to be
> > > >> addressed.
> > > >>>>> As
> > > >>>>>> far as I can tell, of the 10 unassigned issues out there, none
> of
> > > >> them
> > > >>>>> are
> > > >>>>>> comprehensible enough (other than the one I already worked on)
> to
> > be
> > > >>>>> worked
> > > >>>>>> through. So I'm not sure, maybe it's an issue of perception,
> but
> > I
> > > >>>> don't
> > > >>>>>> think we have a large pile of open work for future releases.
> > > >>>>>>
> > > >>>>>> John
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On Sun, Mar 24, 2013 at 11:19 AM, Romain Manni-Bucau
> > > >>>>>> <rm...@gmail.com>wrote:
> > > >>>>>>
> > > >>>>>>> Sure but we cant start everything, finishing nothing...our rare
> > > >>>>> releases
> > > >>>>>>> are already a pain for users.
> > > >>>>>>>
> > > >>>>>>> We need jsf + if possible cdi query for 0.4 IMO then i agree
> rest
> > > >>>>> helpers
> > > >>>>>>> are a must have (some tools around jaxrs client part can be
> > great)
> > > >>>>> etc...
> > > >>>>>>> Le 24 mars 2013 16:13, "John D. Ament" <john.d.ament@gmail.com
> >
> > a
> > > >>>>> écrit
> > > >>>>>> :
> > > >>>>>>>
> > > >>>>>>>> Romain,
> > > >>>>>>>>
> > > >>>>>>>> My only issue with this is that I don't think we've mapped out
> > > >> what
> > > >>>>> the
> > > >>>>>>>> common use cases are (at least based on the email I sent out).
> > > >> If
> > > >>>>>> we're
> > > >>>>>>>> favoring JSF, we're neglecting the growing population of REST
> > > >> APIs
> > > >>>>> for
> > > >>>>>>> rich
> > > >>>>>>>> javascript clients (from UI).
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau
> > > >>>>>>>> <rm...@gmail.com>wrote:
> > > >>>>>>>>
> > > >>>>>>>>> yes but JMS is clearly not the most used
> > > >>>>>>>>>
> > > >>>>>>>>> can't we push it for the > 1.0?
> > > >>>>>>>>>
> > > >>>>>>>>> users really wait the first 1.0 to use DS and adding JMS now
> > > >>>> simply
> > > >>>>>>> looks
> > > >>>>>>>>> like forgetting more common use cases
> > > >>>>>>>>>
> > > >>>>>>>>> *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/23 Gerhard Petracek <ge...@gmail.com>
> > > >>>>>>>>>
> > > >>>>>>>>>> hi @ all,
> > > >>>>>>>>>>
> > > >>>>>>>>>> imo it's more a basic question.
> > > >>>>>>>>>> if we do it for jms 2, we also have to (/should) do it for
> > > >>>> other
> > > >>>>>>>>>> specifications like bv 1.1
> > > >>>>>>>>>>
> > > >>>>>>>>>> regards,
> > > >>>>>>>>>> gerhard
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
> > > >>>>>>>>>>
> > > >>>>>>>>>>> Ill rephrase a bit. I m rather -0 about it and -1 since a
> > > >> lot
> > > >>>>> of
> > > >>>>>>>> others
> > > >>>>>>>>>>> stuff are needed before.
> > > >>>>>>>>>>> Le 21 mars 2013 22:50, "Arne Limburg" <
> > > >>>>>>> arne.limburg@openknowledge.de
> > > >>>>>>>>>
> > > >>>>>>>>> a
> > > >>>>>>>>>>> écrit :
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> 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 <jo...@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
> > > >>>>>>>>>>>>>> <rm...@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 <jo...@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
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > >
> > >
> >
> >
> > --
> > Nicklas Karlsson, +358 40 5062266
> > Vaakunatie 10 as 7, 20780 Kaarina
> >
>
Re: DISCUSS DeltaSpike-324
Posted by Cody Lerum <co...@gmail.com>.
+1
On Mar 25, 2013 8:04 AM, "Nicklas Karlsson" <ni...@gmail.com> wrote:
> I'm currently in the process of porting an application from Seam3 to
> DeltaSpike, with a clear roadmap I might be able to spend some work hours
> in getting stuff forward.
>
>
> On Mon, Mar 25, 2013 at 3:58 PM, Pete Muir <pm...@redhat.com> wrote:
>
> > Hi all,
> >
> > At the moment it's really hard for Red Hat to fund more people to work on
> > DeltaSpike. Without a clear roadmap, and a regular release schedule (e.g.
> > time boxed) it's really hard for us to justify more people for DeltaSpike
> > as we can't see how many people we should offer to get to the features
> our
> > customers need, nor can we see when those features will be available for
> > customers to start using.
> >
> > Last time we asked to agree on a roadmap, this group decided it wasn't
> > something that it wanted to do. If we are now able to agree on a roadmap
> > with some sort of regular release schedule (even just having approx dates
> > for a release is good enough) then I can see how I can reprioritise our
> > current work, and get some more help for DeltaSpike, and hopefully get us
> > closer to 1.0, which is really what I think we are all after (I'm not
> sure
> > if I will succeed, but right now it's not really worth me even trying).
> >
> > Pete
> >
> > On 24 Mar 2013, at 18:33, Romain Manni-Bucau <rm...@gmail.com>
> > wrote:
> >
> > > I did a JUG this week with a part on DS and was the main question asked
> > > with those words "when will it be usable?"...kind of sad. Releasing
> even
> > in
> > > alpha/beta is better IMO.
> > > Le 24 mars 2013 19:29, "Jason Porter" <li...@gmail.com> a
> écrit
> > :
> > >
> > >> +1 glad I'm not the only one asking for a roadmap now.
> > >> —
> > >> Sent from Mailbox for iPhone
> > >>
> > >> On Sun, Mar 24, 2013 at 11:54 AM, Romain Manni-Bucau
> > >> <rm...@gmail.com> wrote:
> > >>
> > >>> Do we already have a roadmap? I think we should define one by
> iteration
> > >>> (+handle a backlog if we want).
> > >>> I can help on cdi query part if needed (jsf is still a bit too new
> for
> > >> me).
> > >>> Le 24 mars 2013 18:49, "Gerhard Petracek" <
> gerhard.petracek@gmail.com>
> > a
> > >>> écrit :
> > >>>> hi john,
> > >>>>
> > >>>> we can't keep it currently (i'm also unhappy about it), because if
> > only
> > >> 2-3
> > >>>> people help on a >regular< basis [1], you have to wait until they
> have
> > >>>> time.
> > >>>> it isn't only about unassigned issues. e.g. not that many help with
> > >> writing
> > >>>> tests and examples, writing/reviewing javadoc and documentation.
> > >>>>
> > >>>> even the graduation process takes (very) long.
> > >>>> that might be a big blocker for some users.
> > >>>> at least codi had several users way before v1 (and for sure even
> more
> > >> after
> > >>>> v1).
> > >>>> however, we would lose more users, if we release v1 which isn't
> ready.
> > >>>>
> > >>>>> imo< our goal for v1 should be >at least< everything (which we know
> > >>>> already) we need for improving the java-ee web-profile as well as a
> > >> stable
> > >>>> api and spi.
> > >>>>
> > >>>> regards,
> > >>>> gerhard
> > >>>>
> > >>>> [1] https://github.com/apache/incubator-deltaspike/contributors
> > >>>>
> > >>>>
> > >>>>
> > >>>> 2013/3/24 Romain Manni-Bucau <rm...@gmail.com>
> > >>>>
> > >>>>> I get you and think we agree behund words. My main issue is our 0.4
> > is
> > >>>> not
> > >>>>> ready to be released and still doesnt contain what users are
> waiting
> > >>>> for...
> > >>>>>
> > >>>>> When i spoke about > 1.0 just understand when last release answer
> > >> basic
> > >>>>> needs
> > >>>>> Le 24 mars 2013 16:49, "John D. Ament" <jo...@gmail.com> a
> > >> écrit
> > >>>> :
> > >>>>>
> > >>>>>> Romain,
> > >>>>>>
> > >>>>>> I'm not sure what to tell you. One of our founding statements was
> > >>>>> release
> > >>>>>> early and often. I'm not sure why we haven't stuck to that.
> > >>>>> Personally, I
> > >>>>>> think we have failed to do that. We probably have too many
> features
> > >>>> in a
> > >>>>>> single release/ not much release planning/attempt to release
> > >> everything
> > >>>>> as
> > >>>>>> one big release rather than more modular in nature. Those are
> just
> > >>>>>> thoughts.
> > >>>>>>
> > >>>>>> As I already stated, I don't want this in 0.4. But I don't think
> > >> it's
> > >>>>>> appropriate to stick this in after 1.0, who knows when that will
> > >> be. I
> > >>>>>> would love to see this in 0.5, already have prototypes working.
> My
> > >>>>> biggest
> > >>>>>> issue, as I was trying to raise in the other thread, is that when
> > >>>> people
> > >>>>>> look at the issue list out there, generally the candidates to work
> > >> on
> > >>>> are
> > >>>>>> the unassigned issues. If 80% of what we have out there is
> > >> assigned,
> > >>>>> then
> > >>>>>> it's assumed someone's work on it. If it's assigned to someone
> and
> > >>>>> they're
> > >>>>>> not working on it, that's probably an issue that needs to be
> > >> addressed.
> > >>>>> As
> > >>>>>> far as I can tell, of the 10 unassigned issues out there, none of
> > >> them
> > >>>>> are
> > >>>>>> comprehensible enough (other than the one I already worked on) to
> be
> > >>>>> worked
> > >>>>>> through. So I'm not sure, maybe it's an issue of perception, but
> I
> > >>>> don't
> > >>>>>> think we have a large pile of open work for future releases.
> > >>>>>>
> > >>>>>> John
> > >>>>>>
> > >>>>>>
> > >>>>>> On Sun, Mar 24, 2013 at 11:19 AM, Romain Manni-Bucau
> > >>>>>> <rm...@gmail.com>wrote:
> > >>>>>>
> > >>>>>>> Sure but we cant start everything, finishing nothing...our rare
> > >>>>> releases
> > >>>>>>> are already a pain for users.
> > >>>>>>>
> > >>>>>>> We need jsf + if possible cdi query for 0.4 IMO then i agree rest
> > >>>>> helpers
> > >>>>>>> are a must have (some tools around jaxrs client part can be
> great)
> > >>>>> etc...
> > >>>>>>> Le 24 mars 2013 16:13, "John D. Ament" <jo...@gmail.com>
> a
> > >>>>> écrit
> > >>>>>> :
> > >>>>>>>
> > >>>>>>>> Romain,
> > >>>>>>>>
> > >>>>>>>> My only issue with this is that I don't think we've mapped out
> > >> what
> > >>>>> the
> > >>>>>>>> common use cases are (at least based on the email I sent out).
> > >> If
> > >>>>>> we're
> > >>>>>>>> favoring JSF, we're neglecting the growing population of REST
> > >> APIs
> > >>>>> for
> > >>>>>>> rich
> > >>>>>>>> javascript clients (from UI).
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau
> > >>>>>>>> <rm...@gmail.com>wrote:
> > >>>>>>>>
> > >>>>>>>>> yes but JMS is clearly not the most used
> > >>>>>>>>>
> > >>>>>>>>> can't we push it for the > 1.0?
> > >>>>>>>>>
> > >>>>>>>>> users really wait the first 1.0 to use DS and adding JMS now
> > >>>> simply
> > >>>>>>> looks
> > >>>>>>>>> like forgetting more common use cases
> > >>>>>>>>>
> > >>>>>>>>> *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/23 Gerhard Petracek <ge...@gmail.com>
> > >>>>>>>>>
> > >>>>>>>>>> hi @ all,
> > >>>>>>>>>>
> > >>>>>>>>>> imo it's more a basic question.
> > >>>>>>>>>> if we do it for jms 2, we also have to (/should) do it for
> > >>>> other
> > >>>>>>>>>> specifications like bv 1.1
> > >>>>>>>>>>
> > >>>>>>>>>> regards,
> > >>>>>>>>>> gerhard
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
> > >>>>>>>>>>
> > >>>>>>>>>>> Ill rephrase a bit. I m rather -0 about it and -1 since a
> > >> lot
> > >>>>> of
> > >>>>>>>> others
> > >>>>>>>>>>> stuff are needed before.
> > >>>>>>>>>>> Le 21 mars 2013 22:50, "Arne Limburg" <
> > >>>>>>> arne.limburg@openknowledge.de
> > >>>>>>>>>
> > >>>>>>>>> a
> > >>>>>>>>>>> écrit :
> > >>>>>>>>>>>
> > >>>>>>>>>>>> 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 <jo...@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
> > >>>>>>>>>>>>>> <rm...@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 <jo...@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
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> >
> >
>
>
> --
> Nicklas Karlsson, +358 40 5062266
> Vaakunatie 10 as 7, 20780 Kaarina
>
Re: DISCUSS DeltaSpike-324
Posted by Nicklas Karlsson <ni...@gmail.com>.
I'm currently in the process of porting an application from Seam3 to
DeltaSpike, with a clear roadmap I might be able to spend some work hours
in getting stuff forward.
On Mon, Mar 25, 2013 at 3:58 PM, Pete Muir <pm...@redhat.com> wrote:
> Hi all,
>
> At the moment it's really hard for Red Hat to fund more people to work on
> DeltaSpike. Without a clear roadmap, and a regular release schedule (e.g.
> time boxed) it's really hard for us to justify more people for DeltaSpike
> as we can't see how many people we should offer to get to the features our
> customers need, nor can we see when those features will be available for
> customers to start using.
>
> Last time we asked to agree on a roadmap, this group decided it wasn't
> something that it wanted to do. If we are now able to agree on a roadmap
> with some sort of regular release schedule (even just having approx dates
> for a release is good enough) then I can see how I can reprioritise our
> current work, and get some more help for DeltaSpike, and hopefully get us
> closer to 1.0, which is really what I think we are all after (I'm not sure
> if I will succeed, but right now it's not really worth me even trying).
>
> Pete
>
> On 24 Mar 2013, at 18:33, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > I did a JUG this week with a part on DS and was the main question asked
> > with those words "when will it be usable?"...kind of sad. Releasing even
> in
> > alpha/beta is better IMO.
> > Le 24 mars 2013 19:29, "Jason Porter" <li...@gmail.com> a écrit
> :
> >
> >> +1 glad I'm not the only one asking for a roadmap now.
> >> —
> >> Sent from Mailbox for iPhone
> >>
> >> On Sun, Mar 24, 2013 at 11:54 AM, Romain Manni-Bucau
> >> <rm...@gmail.com> wrote:
> >>
> >>> Do we already have a roadmap? I think we should define one by iteration
> >>> (+handle a backlog if we want).
> >>> I can help on cdi query part if needed (jsf is still a bit too new for
> >> me).
> >>> Le 24 mars 2013 18:49, "Gerhard Petracek" <ge...@gmail.com>
> a
> >>> écrit :
> >>>> hi john,
> >>>>
> >>>> we can't keep it currently (i'm also unhappy about it), because if
> only
> >> 2-3
> >>>> people help on a >regular< basis [1], you have to wait until they have
> >>>> time.
> >>>> it isn't only about unassigned issues. e.g. not that many help with
> >> writing
> >>>> tests and examples, writing/reviewing javadoc and documentation.
> >>>>
> >>>> even the graduation process takes (very) long.
> >>>> that might be a big blocker for some users.
> >>>> at least codi had several users way before v1 (and for sure even more
> >> after
> >>>> v1).
> >>>> however, we would lose more users, if we release v1 which isn't ready.
> >>>>
> >>>>> imo< our goal for v1 should be >at least< everything (which we know
> >>>> already) we need for improving the java-ee web-profile as well as a
> >> stable
> >>>> api and spi.
> >>>>
> >>>> regards,
> >>>> gerhard
> >>>>
> >>>> [1] https://github.com/apache/incubator-deltaspike/contributors
> >>>>
> >>>>
> >>>>
> >>>> 2013/3/24 Romain Manni-Bucau <rm...@gmail.com>
> >>>>
> >>>>> I get you and think we agree behund words. My main issue is our 0.4
> is
> >>>> not
> >>>>> ready to be released and still doesnt contain what users are waiting
> >>>> for...
> >>>>>
> >>>>> When i spoke about > 1.0 just understand when last release answer
> >> basic
> >>>>> needs
> >>>>> Le 24 mars 2013 16:49, "John D. Ament" <jo...@gmail.com> a
> >> écrit
> >>>> :
> >>>>>
> >>>>>> Romain,
> >>>>>>
> >>>>>> I'm not sure what to tell you. One of our founding statements was
> >>>>> release
> >>>>>> early and often. I'm not sure why we haven't stuck to that.
> >>>>> Personally, I
> >>>>>> think we have failed to do that. We probably have too many features
> >>>> in a
> >>>>>> single release/ not much release planning/attempt to release
> >> everything
> >>>>> as
> >>>>>> one big release rather than more modular in nature. Those are just
> >>>>>> thoughts.
> >>>>>>
> >>>>>> As I already stated, I don't want this in 0.4. But I don't think
> >> it's
> >>>>>> appropriate to stick this in after 1.0, who knows when that will
> >> be. I
> >>>>>> would love to see this in 0.5, already have prototypes working. My
> >>>>> biggest
> >>>>>> issue, as I was trying to raise in the other thread, is that when
> >>>> people
> >>>>>> look at the issue list out there, generally the candidates to work
> >> on
> >>>> are
> >>>>>> the unassigned issues. If 80% of what we have out there is
> >> assigned,
> >>>>> then
> >>>>>> it's assumed someone's work on it. If it's assigned to someone and
> >>>>> they're
> >>>>>> not working on it, that's probably an issue that needs to be
> >> addressed.
> >>>>> As
> >>>>>> far as I can tell, of the 10 unassigned issues out there, none of
> >> them
> >>>>> are
> >>>>>> comprehensible enough (other than the one I already worked on) to be
> >>>>> worked
> >>>>>> through. So I'm not sure, maybe it's an issue of perception, but I
> >>>> don't
> >>>>>> think we have a large pile of open work for future releases.
> >>>>>>
> >>>>>> John
> >>>>>>
> >>>>>>
> >>>>>> On Sun, Mar 24, 2013 at 11:19 AM, Romain Manni-Bucau
> >>>>>> <rm...@gmail.com>wrote:
> >>>>>>
> >>>>>>> Sure but we cant start everything, finishing nothing...our rare
> >>>>> releases
> >>>>>>> are already a pain for users.
> >>>>>>>
> >>>>>>> We need jsf + if possible cdi query for 0.4 IMO then i agree rest
> >>>>> helpers
> >>>>>>> are a must have (some tools around jaxrs client part can be great)
> >>>>> etc...
> >>>>>>> Le 24 mars 2013 16:13, "John D. Ament" <jo...@gmail.com> a
> >>>>> écrit
> >>>>>> :
> >>>>>>>
> >>>>>>>> Romain,
> >>>>>>>>
> >>>>>>>> My only issue with this is that I don't think we've mapped out
> >> what
> >>>>> the
> >>>>>>>> common use cases are (at least based on the email I sent out).
> >> If
> >>>>>> we're
> >>>>>>>> favoring JSF, we're neglecting the growing population of REST
> >> APIs
> >>>>> for
> >>>>>>> rich
> >>>>>>>> javascript clients (from UI).
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau
> >>>>>>>> <rm...@gmail.com>wrote:
> >>>>>>>>
> >>>>>>>>> yes but JMS is clearly not the most used
> >>>>>>>>>
> >>>>>>>>> can't we push it for the > 1.0?
> >>>>>>>>>
> >>>>>>>>> users really wait the first 1.0 to use DS and adding JMS now
> >>>> simply
> >>>>>>> looks
> >>>>>>>>> like forgetting more common use cases
> >>>>>>>>>
> >>>>>>>>> *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/23 Gerhard Petracek <ge...@gmail.com>
> >>>>>>>>>
> >>>>>>>>>> hi @ all,
> >>>>>>>>>>
> >>>>>>>>>> imo it's more a basic question.
> >>>>>>>>>> if we do it for jms 2, we also have to (/should) do it for
> >>>> other
> >>>>>>>>>> specifications like bv 1.1
> >>>>>>>>>>
> >>>>>>>>>> regards,
> >>>>>>>>>> gerhard
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
> >>>>>>>>>>
> >>>>>>>>>>> Ill rephrase a bit. I m rather -0 about it and -1 since a
> >> lot
> >>>>> of
> >>>>>>>> others
> >>>>>>>>>>> stuff are needed before.
> >>>>>>>>>>> Le 21 mars 2013 22:50, "Arne Limburg" <
> >>>>>>> arne.limburg@openknowledge.de
> >>>>>>>>>
> >>>>>>>>> a
> >>>>>>>>>>> écrit :
> >>>>>>>>>>>
> >>>>>>>>>>>> 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 <jo...@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
> >>>>>>>>>>>>>> <rm...@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 <jo...@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
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
>
>
--
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina
Re: DISCUSS DeltaSpike-324
Posted by Pete Muir <pm...@redhat.com>.
Hi all,
At the moment it's really hard for Red Hat to fund more people to work on DeltaSpike. Without a clear roadmap, and a regular release schedule (e.g. time boxed) it's really hard for us to justify more people for DeltaSpike as we can't see how many people we should offer to get to the features our customers need, nor can we see when those features will be available for customers to start using.
Last time we asked to agree on a roadmap, this group decided it wasn't something that it wanted to do. If we are now able to agree on a roadmap with some sort of regular release schedule (even just having approx dates for a release is good enough) then I can see how I can reprioritise our current work, and get some more help for DeltaSpike, and hopefully get us closer to 1.0, which is really what I think we are all after (I'm not sure if I will succeed, but right now it's not really worth me even trying).
Pete
On 24 Mar 2013, at 18:33, Romain Manni-Bucau <rm...@gmail.com> wrote:
> I did a JUG this week with a part on DS and was the main question asked
> with those words "when will it be usable?"...kind of sad. Releasing even in
> alpha/beta is better IMO.
> Le 24 mars 2013 19:29, "Jason Porter" <li...@gmail.com> a écrit :
>
>> +1 glad I'm not the only one asking for a roadmap now.
>> —
>> Sent from Mailbox for iPhone
>>
>> On Sun, Mar 24, 2013 at 11:54 AM, Romain Manni-Bucau
>> <rm...@gmail.com> wrote:
>>
>>> Do we already have a roadmap? I think we should define one by iteration
>>> (+handle a backlog if we want).
>>> I can help on cdi query part if needed (jsf is still a bit too new for
>> me).
>>> Le 24 mars 2013 18:49, "Gerhard Petracek" <ge...@gmail.com> a
>>> écrit :
>>>> hi john,
>>>>
>>>> we can't keep it currently (i'm also unhappy about it), because if only
>> 2-3
>>>> people help on a >regular< basis [1], you have to wait until they have
>>>> time.
>>>> it isn't only about unassigned issues. e.g. not that many help with
>> writing
>>>> tests and examples, writing/reviewing javadoc and documentation.
>>>>
>>>> even the graduation process takes (very) long.
>>>> that might be a big blocker for some users.
>>>> at least codi had several users way before v1 (and for sure even more
>> after
>>>> v1).
>>>> however, we would lose more users, if we release v1 which isn't ready.
>>>>
>>>>> imo< our goal for v1 should be >at least< everything (which we know
>>>> already) we need for improving the java-ee web-profile as well as a
>> stable
>>>> api and spi.
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>> [1] https://github.com/apache/incubator-deltaspike/contributors
>>>>
>>>>
>>>>
>>>> 2013/3/24 Romain Manni-Bucau <rm...@gmail.com>
>>>>
>>>>> I get you and think we agree behund words. My main issue is our 0.4 is
>>>> not
>>>>> ready to be released and still doesnt contain what users are waiting
>>>> for...
>>>>>
>>>>> When i spoke about > 1.0 just understand when last release answer
>> basic
>>>>> needs
>>>>> Le 24 mars 2013 16:49, "John D. Ament" <jo...@gmail.com> a
>> écrit
>>>> :
>>>>>
>>>>>> Romain,
>>>>>>
>>>>>> I'm not sure what to tell you. One of our founding statements was
>>>>> release
>>>>>> early and often. I'm not sure why we haven't stuck to that.
>>>>> Personally, I
>>>>>> think we have failed to do that. We probably have too many features
>>>> in a
>>>>>> single release/ not much release planning/attempt to release
>> everything
>>>>> as
>>>>>> one big release rather than more modular in nature. Those are just
>>>>>> thoughts.
>>>>>>
>>>>>> As I already stated, I don't want this in 0.4. But I don't think
>> it's
>>>>>> appropriate to stick this in after 1.0, who knows when that will
>> be. I
>>>>>> would love to see this in 0.5, already have prototypes working. My
>>>>> biggest
>>>>>> issue, as I was trying to raise in the other thread, is that when
>>>> people
>>>>>> look at the issue list out there, generally the candidates to work
>> on
>>>> are
>>>>>> the unassigned issues. If 80% of what we have out there is
>> assigned,
>>>>> then
>>>>>> it's assumed someone's work on it. If it's assigned to someone and
>>>>> they're
>>>>>> not working on it, that's probably an issue that needs to be
>> addressed.
>>>>> As
>>>>>> far as I can tell, of the 10 unassigned issues out there, none of
>> them
>>>>> are
>>>>>> comprehensible enough (other than the one I already worked on) to be
>>>>> worked
>>>>>> through. So I'm not sure, maybe it's an issue of perception, but I
>>>> don't
>>>>>> think we have a large pile of open work for future releases.
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>> On Sun, Mar 24, 2013 at 11:19 AM, Romain Manni-Bucau
>>>>>> <rm...@gmail.com>wrote:
>>>>>>
>>>>>>> Sure but we cant start everything, finishing nothing...our rare
>>>>> releases
>>>>>>> are already a pain for users.
>>>>>>>
>>>>>>> We need jsf + if possible cdi query for 0.4 IMO then i agree rest
>>>>> helpers
>>>>>>> are a must have (some tools around jaxrs client part can be great)
>>>>> etc...
>>>>>>> Le 24 mars 2013 16:13, "John D. Ament" <jo...@gmail.com> a
>>>>> écrit
>>>>>> :
>>>>>>>
>>>>>>>> Romain,
>>>>>>>>
>>>>>>>> My only issue with this is that I don't think we've mapped out
>> what
>>>>> the
>>>>>>>> common use cases are (at least based on the email I sent out).
>> If
>>>>>> we're
>>>>>>>> favoring JSF, we're neglecting the growing population of REST
>> APIs
>>>>> for
>>>>>>> rich
>>>>>>>> javascript clients (from UI).
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau
>>>>>>>> <rm...@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> yes but JMS is clearly not the most used
>>>>>>>>>
>>>>>>>>> can't we push it for the > 1.0?
>>>>>>>>>
>>>>>>>>> users really wait the first 1.0 to use DS and adding JMS now
>>>> simply
>>>>>>> looks
>>>>>>>>> like forgetting more common use cases
>>>>>>>>>
>>>>>>>>> *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/23 Gerhard Petracek <ge...@gmail.com>
>>>>>>>>>
>>>>>>>>>> hi @ all,
>>>>>>>>>>
>>>>>>>>>> imo it's more a basic question.
>>>>>>>>>> if we do it for jms 2, we also have to (/should) do it for
>>>> other
>>>>>>>>>> specifications like bv 1.1
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>> gerhard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>> Ill rephrase a bit. I m rather -0 about it and -1 since a
>> lot
>>>>> of
>>>>>>>> others
>>>>>>>>>>> stuff are needed before.
>>>>>>>>>>> Le 21 mars 2013 22:50, "Arne Limburg" <
>>>>>>> arne.limburg@openknowledge.de
>>>>>>>>>
>>>>>>>>> a
>>>>>>>>>>> écrit :
>>>>>>>>>>>
>>>>>>>>>>>> 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 <jo...@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
>>>>>>>>>>>>>> <rm...@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 <jo...@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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
Re: DISCUSS DeltaSpike-324
Posted by Gerhard Petracek <ge...@gmail.com>.
hi adrian,
yes, i also know several projects which use codi + ds 0.3 (in production)
and they are happy with it.
(most of them move to ds feature by feature without issues.)
regards,
gerhard
2013/3/24 Adrian Gonzalez <ad...@yahoo.fr>
> Hello,
>
> I'm a DS user (and I'm not the only one I think).
>
> Just to let you know how I use it (if this can help someone) : DS 0.3 with
> a mix of CODI and 2/3 classes from Seam [1].
>
> Quite happy for now (I'm using DS Exception handling - with custom REST
> and JSF extensions from Seam 3, Config).
>
>
> From CODI, I use WindowScoped, ConversationScoped and ViewAccessScoped.
>
> From Seam 3, I use a modified version JSF ExceptionHandling (to integrate
> to DS Exception Handling), UIInputContainer (completely optional, but I
> like it), and REST Exception Handling.
> Only JSF ExceptionHandling is really mandatory IMO.
>
> For the rest of my application CMT EJB Stateless (tx) and
> @PersistenceContext (no extended).
>
> I'll remove CODI when CODI scopes are ported to DS which should be DS 0.4
> if I'm correct.
>
>
> Best regards,
>
> [1] Most notably :
> https://github.com/seam/faces/tree/develop/impl/src/main/java/org/jboss/seam/faces/exception
>
>
> ________________________________
> De : Romain Manni-Bucau <rm...@gmail.com>
> À : deltaspike-dev@incubator.apache.org
> Envoyé le : Dimanche 24 mars 2013 19h33
> Objet : Re: DISCUSS DeltaSpike-324
>
> I did a JUG this week with a part on DS and was the main question asked
> with those words "when will it be usable?"...kind of sad. Releasing even in
> alpha/beta is better IMO.
> Le 24 mars 2013 19:29, "Jason Porter" <li...@gmail.com> a écrit :
>
> > +1 glad I'm not the only one asking for a roadmap now.
> > —
> > Sent from Mailbox for iPhone
> >
> > On Sun, Mar 24, 2013 at 11:54 AM, Romain Manni-Bucau
> > <rm...@gmail.com> wrote:
> >
> > > Do we already have a roadmap? I think we should define one by iteration
> > > (+handle a backlog if we want).
> > > I can help on cdi query part if needed (jsf is still a bit too new for
> > me).
> > > Le 24 mars 2013 18:49, "Gerhard Petracek" <ge...@gmail.com>
> a
> > > écrit :
> > >> hi john,
> > >>
> > >> we can't keep it currently (i'm also unhappy about it), because if
> only
> > 2-3
> > >> people help on a >regular< basis [1], you have to wait until they have
> > >> time.
> > >> it isn't only about unassigned issues. e.g. not that many help with
> > writing
> > >> tests and examples, writing/reviewing javadoc and documentation.
> > >>
> > >> even the graduation process takes (very) long.
> > >> that might be a big blocker for some users.
> > >> at least codi had several users way before v1 (and for sure even more
> > after
> > >> v1).
> > >> however, we would lose more users, if we release v1 which isn't ready.
> > >>
> > >> >imo< our goal for v1 should be >at least< everything (which we know
> > >> already) we need for improving the java-ee web-profile as well as a
> > stable
> > >> api and spi.
> > >>
> > >> regards,
> > >> gerhard
> > >>
> > >> [1] https://github.com/apache/incubator-deltaspike/contributors
> > >>
> > >>
> > >>
> > >> 2013/3/24 Romain Manni-Bucau <rm...@gmail.com>
> > >>
> > >> > I get you and think we agree behund words. My main issue is our 0.4
> is
> > >> not
> > >> > ready to be released and still doesnt contain what users are waiting
> > >> for...
> > >> >
> > >> > When i spoke about > 1.0 just understand when last release answer
> > basic
> > >> > needs
> > >> > Le 24 mars 2013 16:49, "John D. Ament" <jo...@gmail.com> a
> > écrit
> > >> :
> > >> >
> > >> > > Romain,
> > >> > >
> > >> > > I'm not sure what to tell you. One of our founding statements was
> > >> > release
> > >> > > early and often. I'm not sure why we haven't stuck to that.
> > >> > Personally, I
> > >> > > think we have failed to do that. We probably have too many
> features
> > >> in a
> > >> > > single release/ not much release planning/attempt to release
> > everything
> > >> > as
> > >> > > one big release rather than more modular in nature. Those are
> just
> > >> > > thoughts.
> > >> > >
> > >> > > As I already stated, I don't want this in 0.4. But I don't think
> > it's
> > >> > > appropriate to stick this in after 1.0, who knows when that will
> > be. I
> > >> > > would love to see this in 0.5, already have prototypes working.
> My
> > >> > biggest
> > >> > > issue, as I was trying to raise in the other thread, is that when
> > >> people
> > >> > > look at the issue list out there, generally the candidates to work
> > on
> > >> are
> > >> > > the unassigned issues. If 80% of what we have out there is
> > assigned,
> > >> > then
> > >> > > it's assumed someone's work on it. If it's assigned to someone
> and
> > >> > they're
> > >> > > not working on it, that's probably an issue that needs to be
> > addressed.
> > >> > As
> > >> > > far as I can tell, of the 10 unassigned issues out there, none of
> > them
> > >> > are
> > >> > > comprehensible enough (other than the one I already worked on) to
> be
> > >> > worked
> > >> > > through. So I'm not sure, maybe it's an issue of perception, but
> I
> > >> don't
> > >> > > think we have a large pile of open work for future releases.
> > >> > >
> > >> > > John
> > >> > >
> > >> > >
> > >> > > On Sun, Mar 24, 2013 at 11:19 AM, Romain Manni-Bucau
> > >> > > <rm...@gmail.com>wrote:
> > >> > >
> > >> > > > Sure but we cant start everything, finishing nothing...our rare
> > >> > releases
> > >> > > > are already a pain for users.
> > >> > > >
> > >> > > > We need jsf + if possible cdi query for 0.4 IMO then i agree
> rest
> > >> > helpers
> > >> > > > are a must have (some tools around jaxrs client part can be
> great)
> > >> > etc...
> > >> > > > Le 24 mars 2013 16:13, "John D. Ament" <jo...@gmail.com>
> a
> > >> > écrit
> > >> > > :
> > >> > > >
> > >> > > > > Romain,
> > >> > > > >
> > >> > > > > My only issue with this is that I don't think we've mapped out
> > what
> > >> > the
> > >> > > > > common use cases are (at least based on the email I sent out).
> > If
> > >> > > we're
> > >> > > > > favoring JSF, we're neglecting the growing population of REST
> > APIs
> > >> > for
> > >> > > > rich
> > >> > > > > javascript clients (from UI).
> > >> > > > >
> > >> > > > >
> > >> > > > > On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau
> > >> > > > > <rm...@gmail.com>wrote:
> > >> > > > >
> > >> > > > > > yes but JMS is clearly not the most used
> > >> > > > > >
> > >> > > > > > can't we push it for the > 1.0?
> > >> > > > > >
> > >> > > > > > users really wait the first 1.0 to use DS and adding JMS now
> > >> simply
> > >> > > > looks
> > >> > > > > > like forgetting more common use cases
> > >> > > > > >
> > >> > > > > > *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/23 Gerhard Petracek <ge...@gmail.com>
> > >> > > > > >
> > >> > > > > > > hi @ all,
> > >> > > > > > >
> > >> > > > > > > imo it's more a basic question.
> > >> > > > > > > if we do it for jms 2, we also have to (/should) do it for
> > >> other
> > >> > > > > > > specifications like bv 1.1
> > >> > > > > > >
> > >> > > > > > > regards,
> > >> > > > > > > gerhard
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
> > >> > > > > > >
> > >> > > > > > > > Ill rephrase a bit. I m rather -0 about it and -1 since
> a
> > lot
> > >> > of
> > >> > > > > others
> > >> > > > > > > > stuff are needed before.
> > >> > > > > > > > Le 21 mars 2013 22:50, "Arne Limburg" <
> > >> > > > arne.limburg@openknowledge.de
> > >> > > > > >
> > >> > > > > > a
> > >> > > > > > > > écrit :
> > >> > > > > > > >
> > >> > > > > > > > > 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 <jo...@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
> > >> > > > > > > > > >> <rm...@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 <jo...@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
> > >> > > > > > > > > >>> >
> > >> > > > > > > > > >>>
> > >> > > > > > > > > >>
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
>
Re: DISCUSS DeltaSpike-324
Posted by Adrian Gonzalez <ad...@yahoo.fr>.
Hello,
I'm a DS user (and I'm not the only one I think).
Just to let you know how I use it (if this can help someone) : DS 0.3 with a mix of CODI and 2/3 classes from Seam [1].
Quite happy for now (I'm using DS Exception handling - with custom REST and JSF extensions from Seam 3, Config).
From CODI, I use WindowScoped, ConversationScoped and ViewAccessScoped.
From Seam 3, I use a modified version JSF ExceptionHandling (to integrate to DS Exception Handling), UIInputContainer (completely optional, but I like it), and REST Exception Handling.
Only JSF ExceptionHandling is really mandatory IMO.
For the rest of my application CMT EJB Stateless (tx) and @PersistenceContext (no extended).
I'll remove CODI when CODI scopes are ported to DS which should be DS 0.4 if I'm correct.
Best regards,
[1] Most notably : https://github.com/seam/faces/tree/develop/impl/src/main/java/org/jboss/seam/faces/exception
________________________________
De : Romain Manni-Bucau <rm...@gmail.com>
À : deltaspike-dev@incubator.apache.org
Envoyé le : Dimanche 24 mars 2013 19h33
Objet : Re: DISCUSS DeltaSpike-324
I did a JUG this week with a part on DS and was the main question asked
with those words "when will it be usable?"...kind of sad. Releasing even in
alpha/beta is better IMO.
Le 24 mars 2013 19:29, "Jason Porter" <li...@gmail.com> a écrit :
> +1 glad I'm not the only one asking for a roadmap now.
> —
> Sent from Mailbox for iPhone
>
> On Sun, Mar 24, 2013 at 11:54 AM, Romain Manni-Bucau
> <rm...@gmail.com> wrote:
>
> > Do we already have a roadmap? I think we should define one by iteration
> > (+handle a backlog if we want).
> > I can help on cdi query part if needed (jsf is still a bit too new for
> me).
> > Le 24 mars 2013 18:49, "Gerhard Petracek" <ge...@gmail.com> a
> > écrit :
> >> hi john,
> >>
> >> we can't keep it currently (i'm also unhappy about it), because if only
> 2-3
> >> people help on a >regular< basis [1], you have to wait until they have
> >> time.
> >> it isn't only about unassigned issues. e.g. not that many help with
> writing
> >> tests and examples, writing/reviewing javadoc and documentation.
> >>
> >> even the graduation process takes (very) long.
> >> that might be a big blocker for some users.
> >> at least codi had several users way before v1 (and for sure even more
> after
> >> v1).
> >> however, we would lose more users, if we release v1 which isn't ready.
> >>
> >> >imo< our goal for v1 should be >at least< everything (which we know
> >> already) we need for improving the java-ee web-profile as well as a
> stable
> >> api and spi.
> >>
> >> regards,
> >> gerhard
> >>
> >> [1] https://github.com/apache/incubator-deltaspike/contributors
> >>
> >>
> >>
> >> 2013/3/24 Romain Manni-Bucau <rm...@gmail.com>
> >>
> >> > I get you and think we agree behund words. My main issue is our 0.4 is
> >> not
> >> > ready to be released and still doesnt contain what users are waiting
> >> for...
> >> >
> >> > When i spoke about > 1.0 just understand when last release answer
> basic
> >> > needs
> >> > Le 24 mars 2013 16:49, "John D. Ament" <jo...@gmail.com> a
> écrit
> >> :
> >> >
> >> > > Romain,
> >> > >
> >> > > I'm not sure what to tell you. One of our founding statements was
> >> > release
> >> > > early and often. I'm not sure why we haven't stuck to that.
> >> > Personally, I
> >> > > think we have failed to do that. We probably have too many features
> >> in a
> >> > > single release/ not much release planning/attempt to release
> everything
> >> > as
> >> > > one big release rather than more modular in nature. Those are just
> >> > > thoughts.
> >> > >
> >> > > As I already stated, I don't want this in 0.4. But I don't think
> it's
> >> > > appropriate to stick this in after 1.0, who knows when that will
> be. I
> >> > > would love to see this in 0.5, already have prototypes working. My
> >> > biggest
> >> > > issue, as I was trying to raise in the other thread, is that when
> >> people
> >> > > look at the issue list out there, generally the candidates to work
> on
> >> are
> >> > > the unassigned issues. If 80% of what we have out there is
> assigned,
> >> > then
> >> > > it's assumed someone's work on it. If it's assigned to someone and
> >> > they're
> >> > > not working on it, that's probably an issue that needs to be
> addressed.
> >> > As
> >> > > far as I can tell, of the 10 unassigned issues out there, none of
> them
> >> > are
> >> > > comprehensible enough (other than the one I already worked on) to be
> >> > worked
> >> > > through. So I'm not sure, maybe it's an issue of perception, but I
> >> don't
> >> > > think we have a large pile of open work for future releases.
> >> > >
> >> > > John
> >> > >
> >> > >
> >> > > On Sun, Mar 24, 2013 at 11:19 AM, Romain Manni-Bucau
> >> > > <rm...@gmail.com>wrote:
> >> > >
> >> > > > Sure but we cant start everything, finishing nothing...our rare
> >> > releases
> >> > > > are already a pain for users.
> >> > > >
> >> > > > We need jsf + if possible cdi query for 0.4 IMO then i agree rest
> >> > helpers
> >> > > > are a must have (some tools around jaxrs client part can be great)
> >> > etc...
> >> > > > Le 24 mars 2013 16:13, "John D. Ament" <jo...@gmail.com> a
> >> > écrit
> >> > > :
> >> > > >
> >> > > > > Romain,
> >> > > > >
> >> > > > > My only issue with this is that I don't think we've mapped out
> what
> >> > the
> >> > > > > common use cases are (at least based on the email I sent out).
> If
> >> > > we're
> >> > > > > favoring JSF, we're neglecting the growing population of REST
> APIs
> >> > for
> >> > > > rich
> >> > > > > javascript clients (from UI).
> >> > > > >
> >> > > > >
> >> > > > > On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau
> >> > > > > <rm...@gmail.com>wrote:
> >> > > > >
> >> > > > > > yes but JMS is clearly not the most used
> >> > > > > >
> >> > > > > > can't we push it for the > 1.0?
> >> > > > > >
> >> > > > > > users really wait the first 1.0 to use DS and adding JMS now
> >> simply
> >> > > > looks
> >> > > > > > like forgetting more common use cases
> >> > > > > >
> >> > > > > > *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/23 Gerhard Petracek <ge...@gmail.com>
> >> > > > > >
> >> > > > > > > hi @ all,
> >> > > > > > >
> >> > > > > > > imo it's more a basic question.
> >> > > > > > > if we do it for jms 2, we also have to (/should) do it for
> >> other
> >> > > > > > > specifications like bv 1.1
> >> > > > > > >
> >> > > > > > > regards,
> >> > > > > > > gerhard
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
> >> > > > > > >
> >> > > > > > > > Ill rephrase a bit. I m rather -0 about it and -1 since a
> lot
> >> > of
> >> > > > > others
> >> > > > > > > > stuff are needed before.
> >> > > > > > > > Le 21 mars 2013 22:50, "Arne Limburg" <
> >> > > > arne.limburg@openknowledge.de
> >> > > > > >
> >> > > > > > a
> >> > > > > > > > écrit :
> >> > > > > > > >
> >> > > > > > > > > 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 <jo...@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
> >> > > > > > > > > >> <rm...@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 <jo...@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
> >> > > > > > > > > >>> >
> >> > > > > > > > > >>>
> >> > > > > > > > > >>
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
Re: DISCUSS DeltaSpike-324
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I did a JUG this week with a part on DS and was the main question asked
with those words "when will it be usable?"...kind of sad. Releasing even in
alpha/beta is better IMO.
Le 24 mars 2013 19:29, "Jason Porter" <li...@gmail.com> a écrit :
> +1 glad I'm not the only one asking for a roadmap now.
> —
> Sent from Mailbox for iPhone
>
> On Sun, Mar 24, 2013 at 11:54 AM, Romain Manni-Bucau
> <rm...@gmail.com> wrote:
>
> > Do we already have a roadmap? I think we should define one by iteration
> > (+handle a backlog if we want).
> > I can help on cdi query part if needed (jsf is still a bit too new for
> me).
> > Le 24 mars 2013 18:49, "Gerhard Petracek" <ge...@gmail.com> a
> > écrit :
> >> hi john,
> >>
> >> we can't keep it currently (i'm also unhappy about it), because if only
> 2-3
> >> people help on a >regular< basis [1], you have to wait until they have
> >> time.
> >> it isn't only about unassigned issues. e.g. not that many help with
> writing
> >> tests and examples, writing/reviewing javadoc and documentation.
> >>
> >> even the graduation process takes (very) long.
> >> that might be a big blocker for some users.
> >> at least codi had several users way before v1 (and for sure even more
> after
> >> v1).
> >> however, we would lose more users, if we release v1 which isn't ready.
> >>
> >> >imo< our goal for v1 should be >at least< everything (which we know
> >> already) we need for improving the java-ee web-profile as well as a
> stable
> >> api and spi.
> >>
> >> regards,
> >> gerhard
> >>
> >> [1] https://github.com/apache/incubator-deltaspike/contributors
> >>
> >>
> >>
> >> 2013/3/24 Romain Manni-Bucau <rm...@gmail.com>
> >>
> >> > I get you and think we agree behund words. My main issue is our 0.4 is
> >> not
> >> > ready to be released and still doesnt contain what users are waiting
> >> for...
> >> >
> >> > When i spoke about > 1.0 just understand when last release answer
> basic
> >> > needs
> >> > Le 24 mars 2013 16:49, "John D. Ament" <jo...@gmail.com> a
> écrit
> >> :
> >> >
> >> > > Romain,
> >> > >
> >> > > I'm not sure what to tell you. One of our founding statements was
> >> > release
> >> > > early and often. I'm not sure why we haven't stuck to that.
> >> > Personally, I
> >> > > think we have failed to do that. We probably have too many features
> >> in a
> >> > > single release/ not much release planning/attempt to release
> everything
> >> > as
> >> > > one big release rather than more modular in nature. Those are just
> >> > > thoughts.
> >> > >
> >> > > As I already stated, I don't want this in 0.4. But I don't think
> it's
> >> > > appropriate to stick this in after 1.0, who knows when that will
> be. I
> >> > > would love to see this in 0.5, already have prototypes working. My
> >> > biggest
> >> > > issue, as I was trying to raise in the other thread, is that when
> >> people
> >> > > look at the issue list out there, generally the candidates to work
> on
> >> are
> >> > > the unassigned issues. If 80% of what we have out there is
> assigned,
> >> > then
> >> > > it's assumed someone's work on it. If it's assigned to someone and
> >> > they're
> >> > > not working on it, that's probably an issue that needs to be
> addressed.
> >> > As
> >> > > far as I can tell, of the 10 unassigned issues out there, none of
> them
> >> > are
> >> > > comprehensible enough (other than the one I already worked on) to be
> >> > worked
> >> > > through. So I'm not sure, maybe it's an issue of perception, but I
> >> don't
> >> > > think we have a large pile of open work for future releases.
> >> > >
> >> > > John
> >> > >
> >> > >
> >> > > On Sun, Mar 24, 2013 at 11:19 AM, Romain Manni-Bucau
> >> > > <rm...@gmail.com>wrote:
> >> > >
> >> > > > Sure but we cant start everything, finishing nothing...our rare
> >> > releases
> >> > > > are already a pain for users.
> >> > > >
> >> > > > We need jsf + if possible cdi query for 0.4 IMO then i agree rest
> >> > helpers
> >> > > > are a must have (some tools around jaxrs client part can be great)
> >> > etc...
> >> > > > Le 24 mars 2013 16:13, "John D. Ament" <jo...@gmail.com> a
> >> > écrit
> >> > > :
> >> > > >
> >> > > > > Romain,
> >> > > > >
> >> > > > > My only issue with this is that I don't think we've mapped out
> what
> >> > the
> >> > > > > common use cases are (at least based on the email I sent out).
> If
> >> > > we're
> >> > > > > favoring JSF, we're neglecting the growing population of REST
> APIs
> >> > for
> >> > > > rich
> >> > > > > javascript clients (from UI).
> >> > > > >
> >> > > > >
> >> > > > > On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau
> >> > > > > <rm...@gmail.com>wrote:
> >> > > > >
> >> > > > > > yes but JMS is clearly not the most used
> >> > > > > >
> >> > > > > > can't we push it for the > 1.0?
> >> > > > > >
> >> > > > > > users really wait the first 1.0 to use DS and adding JMS now
> >> simply
> >> > > > looks
> >> > > > > > like forgetting more common use cases
> >> > > > > >
> >> > > > > > *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/23 Gerhard Petracek <ge...@gmail.com>
> >> > > > > >
> >> > > > > > > hi @ all,
> >> > > > > > >
> >> > > > > > > imo it's more a basic question.
> >> > > > > > > if we do it for jms 2, we also have to (/should) do it for
> >> other
> >> > > > > > > specifications like bv 1.1
> >> > > > > > >
> >> > > > > > > regards,
> >> > > > > > > gerhard
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
> >> > > > > > >
> >> > > > > > > > Ill rephrase a bit. I m rather -0 about it and -1 since a
> lot
> >> > of
> >> > > > > others
> >> > > > > > > > stuff are needed before.
> >> > > > > > > > Le 21 mars 2013 22:50, "Arne Limburg" <
> >> > > > arne.limburg@openknowledge.de
> >> > > > > >
> >> > > > > > a
> >> > > > > > > > écrit :
> >> > > > > > > >
> >> > > > > > > > > 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 <jo...@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
> >> > > > > > > > > >> <rm...@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 <jo...@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
> >> > > > > > > > > >>> >
> >> > > > > > > > > >>>
> >> > > > > > > > > >>
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
Re: DISCUSS DeltaSpike-324
Posted by Jason Porter <li...@gmail.com>.
+1 glad I'm not the only one asking for a roadmap now.
—
Sent from Mailbox for iPhone
On Sun, Mar 24, 2013 at 11:54 AM, Romain Manni-Bucau
<rm...@gmail.com> wrote:
> Do we already have a roadmap? I think we should define one by iteration
> (+handle a backlog if we want).
> I can help on cdi query part if needed (jsf is still a bit too new for me).
> Le 24 mars 2013 18:49, "Gerhard Petracek" <ge...@gmail.com> a
> écrit :
>> hi john,
>>
>> we can't keep it currently (i'm also unhappy about it), because if only 2-3
>> people help on a >regular< basis [1], you have to wait until they have
>> time.
>> it isn't only about unassigned issues. e.g. not that many help with writing
>> tests and examples, writing/reviewing javadoc and documentation.
>>
>> even the graduation process takes (very) long.
>> that might be a big blocker for some users.
>> at least codi had several users way before v1 (and for sure even more after
>> v1).
>> however, we would lose more users, if we release v1 which isn't ready.
>>
>> >imo< our goal for v1 should be >at least< everything (which we know
>> already) we need for improving the java-ee web-profile as well as a stable
>> api and spi.
>>
>> regards,
>> gerhard
>>
>> [1] https://github.com/apache/incubator-deltaspike/contributors
>>
>>
>>
>> 2013/3/24 Romain Manni-Bucau <rm...@gmail.com>
>>
>> > I get you and think we agree behund words. My main issue is our 0.4 is
>> not
>> > ready to be released and still doesnt contain what users are waiting
>> for...
>> >
>> > When i spoke about > 1.0 just understand when last release answer basic
>> > needs
>> > Le 24 mars 2013 16:49, "John D. Ament" <jo...@gmail.com> a écrit
>> :
>> >
>> > > Romain,
>> > >
>> > > I'm not sure what to tell you. One of our founding statements was
>> > release
>> > > early and often. I'm not sure why we haven't stuck to that.
>> > Personally, I
>> > > think we have failed to do that. We probably have too many features
>> in a
>> > > single release/ not much release planning/attempt to release everything
>> > as
>> > > one big release rather than more modular in nature. Those are just
>> > > thoughts.
>> > >
>> > > As I already stated, I don't want this in 0.4. But I don't think it's
>> > > appropriate to stick this in after 1.0, who knows when that will be. I
>> > > would love to see this in 0.5, already have prototypes working. My
>> > biggest
>> > > issue, as I was trying to raise in the other thread, is that when
>> people
>> > > look at the issue list out there, generally the candidates to work on
>> are
>> > > the unassigned issues. If 80% of what we have out there is assigned,
>> > then
>> > > it's assumed someone's work on it. If it's assigned to someone and
>> > they're
>> > > not working on it, that's probably an issue that needs to be addressed.
>> > As
>> > > far as I can tell, of the 10 unassigned issues out there, none of them
>> > are
>> > > comprehensible enough (other than the one I already worked on) to be
>> > worked
>> > > through. So I'm not sure, maybe it's an issue of perception, but I
>> don't
>> > > think we have a large pile of open work for future releases.
>> > >
>> > > John
>> > >
>> > >
>> > > On Sun, Mar 24, 2013 at 11:19 AM, Romain Manni-Bucau
>> > > <rm...@gmail.com>wrote:
>> > >
>> > > > Sure but we cant start everything, finishing nothing...our rare
>> > releases
>> > > > are already a pain for users.
>> > > >
>> > > > We need jsf + if possible cdi query for 0.4 IMO then i agree rest
>> > helpers
>> > > > are a must have (some tools around jaxrs client part can be great)
>> > etc...
>> > > > Le 24 mars 2013 16:13, "John D. Ament" <jo...@gmail.com> a
>> > écrit
>> > > :
>> > > >
>> > > > > Romain,
>> > > > >
>> > > > > My only issue with this is that I don't think we've mapped out what
>> > the
>> > > > > common use cases are (at least based on the email I sent out). If
>> > > we're
>> > > > > favoring JSF, we're neglecting the growing population of REST APIs
>> > for
>> > > > rich
>> > > > > javascript clients (from UI).
>> > > > >
>> > > > >
>> > > > > On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau
>> > > > > <rm...@gmail.com>wrote:
>> > > > >
>> > > > > > yes but JMS is clearly not the most used
>> > > > > >
>> > > > > > can't we push it for the > 1.0?
>> > > > > >
>> > > > > > users really wait the first 1.0 to use DS and adding JMS now
>> simply
>> > > > looks
>> > > > > > like forgetting more common use cases
>> > > > > >
>> > > > > > *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/23 Gerhard Petracek <ge...@gmail.com>
>> > > > > >
>> > > > > > > hi @ all,
>> > > > > > >
>> > > > > > > imo it's more a basic question.
>> > > > > > > if we do it for jms 2, we also have to (/should) do it for
>> other
>> > > > > > > specifications like bv 1.1
>> > > > > > >
>> > > > > > > regards,
>> > > > > > > gerhard
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
>> > > > > > >
>> > > > > > > > Ill rephrase a bit. I m rather -0 about it and -1 since a lot
>> > of
>> > > > > others
>> > > > > > > > stuff are needed before.
>> > > > > > > > Le 21 mars 2013 22:50, "Arne Limburg" <
>> > > > arne.limburg@openknowledge.de
>> > > > > >
>> > > > > > a
>> > > > > > > > écrit :
>> > > > > > > >
>> > > > > > > > > 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 <jo...@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
>> > > > > > > > > >> <rm...@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 <jo...@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
>> > > > > > > > > >>> >
>> > > > > > > > > >>>
>> > > > > > > > > >>
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
Re: DISCUSS DeltaSpike-324
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Do we already have a roadmap? I think we should define one by iteration
(+handle a backlog if we want).
I can help on cdi query part if needed (jsf is still a bit too new for me).
Le 24 mars 2013 18:49, "Gerhard Petracek" <ge...@gmail.com> a
écrit :
> hi john,
>
> we can't keep it currently (i'm also unhappy about it), because if only 2-3
> people help on a >regular< basis [1], you have to wait until they have
> time.
> it isn't only about unassigned issues. e.g. not that many help with writing
> tests and examples, writing/reviewing javadoc and documentation.
>
> even the graduation process takes (very) long.
> that might be a big blocker for some users.
> at least codi had several users way before v1 (and for sure even more after
> v1).
> however, we would lose more users, if we release v1 which isn't ready.
>
> >imo< our goal for v1 should be >at least< everything (which we know
> already) we need for improving the java-ee web-profile as well as a stable
> api and spi.
>
> regards,
> gerhard
>
> [1] https://github.com/apache/incubator-deltaspike/contributors
>
>
>
> 2013/3/24 Romain Manni-Bucau <rm...@gmail.com>
>
> > I get you and think we agree behund words. My main issue is our 0.4 is
> not
> > ready to be released and still doesnt contain what users are waiting
> for...
> >
> > When i spoke about > 1.0 just understand when last release answer basic
> > needs
> > Le 24 mars 2013 16:49, "John D. Ament" <jo...@gmail.com> a écrit
> :
> >
> > > Romain,
> > >
> > > I'm not sure what to tell you. One of our founding statements was
> > release
> > > early and often. I'm not sure why we haven't stuck to that.
> > Personally, I
> > > think we have failed to do that. We probably have too many features
> in a
> > > single release/ not much release planning/attempt to release everything
> > as
> > > one big release rather than more modular in nature. Those are just
> > > thoughts.
> > >
> > > As I already stated, I don't want this in 0.4. But I don't think it's
> > > appropriate to stick this in after 1.0, who knows when that will be. I
> > > would love to see this in 0.5, already have prototypes working. My
> > biggest
> > > issue, as I was trying to raise in the other thread, is that when
> people
> > > look at the issue list out there, generally the candidates to work on
> are
> > > the unassigned issues. If 80% of what we have out there is assigned,
> > then
> > > it's assumed someone's work on it. If it's assigned to someone and
> > they're
> > > not working on it, that's probably an issue that needs to be addressed.
> > As
> > > far as I can tell, of the 10 unassigned issues out there, none of them
> > are
> > > comprehensible enough (other than the one I already worked on) to be
> > worked
> > > through. So I'm not sure, maybe it's an issue of perception, but I
> don't
> > > think we have a large pile of open work for future releases.
> > >
> > > John
> > >
> > >
> > > On Sun, Mar 24, 2013 at 11:19 AM, Romain Manni-Bucau
> > > <rm...@gmail.com>wrote:
> > >
> > > > Sure but we cant start everything, finishing nothing...our rare
> > releases
> > > > are already a pain for users.
> > > >
> > > > We need jsf + if possible cdi query for 0.4 IMO then i agree rest
> > helpers
> > > > are a must have (some tools around jaxrs client part can be great)
> > etc...
> > > > Le 24 mars 2013 16:13, "John D. Ament" <jo...@gmail.com> a
> > écrit
> > > :
> > > >
> > > > > Romain,
> > > > >
> > > > > My only issue with this is that I don't think we've mapped out what
> > the
> > > > > common use cases are (at least based on the email I sent out). If
> > > we're
> > > > > favoring JSF, we're neglecting the growing population of REST APIs
> > for
> > > > rich
> > > > > javascript clients (from UI).
> > > > >
> > > > >
> > > > > On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau
> > > > > <rm...@gmail.com>wrote:
> > > > >
> > > > > > yes but JMS is clearly not the most used
> > > > > >
> > > > > > can't we push it for the > 1.0?
> > > > > >
> > > > > > users really wait the first 1.0 to use DS and adding JMS now
> simply
> > > > looks
> > > > > > like forgetting more common use cases
> > > > > >
> > > > > > *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/23 Gerhard Petracek <ge...@gmail.com>
> > > > > >
> > > > > > > hi @ all,
> > > > > > >
> > > > > > > imo it's more a basic question.
> > > > > > > if we do it for jms 2, we also have to (/should) do it for
> other
> > > > > > > specifications like bv 1.1
> > > > > > >
> > > > > > > regards,
> > > > > > > gerhard
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
> > > > > > >
> > > > > > > > Ill rephrase a bit. I m rather -0 about it and -1 since a lot
> > of
> > > > > others
> > > > > > > > stuff are needed before.
> > > > > > > > Le 21 mars 2013 22:50, "Arne Limburg" <
> > > > arne.limburg@openknowledge.de
> > > > > >
> > > > > > a
> > > > > > > > écrit :
> > > > > > > >
> > > > > > > > > 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 <jo...@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
> > > > > > > > > >> <rm...@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 <jo...@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
> > > > > > > > > >>> >
> > > > > > > > > >>>
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: DISCUSS DeltaSpike-324
Posted by Gerhard Petracek <ge...@gmail.com>.
hi john,
we can't keep it currently (i'm also unhappy about it), because if only 2-3
people help on a >regular< basis [1], you have to wait until they have time.
it isn't only about unassigned issues. e.g. not that many help with writing
tests and examples, writing/reviewing javadoc and documentation.
even the graduation process takes (very) long.
that might be a big blocker for some users.
at least codi had several users way before v1 (and for sure even more after
v1).
however, we would lose more users, if we release v1 which isn't ready.
>imo< our goal for v1 should be >at least< everything (which we know
already) we need for improving the java-ee web-profile as well as a stable
api and spi.
regards,
gerhard
[1] https://github.com/apache/incubator-deltaspike/contributors
2013/3/24 Romain Manni-Bucau <rm...@gmail.com>
> I get you and think we agree behund words. My main issue is our 0.4 is not
> ready to be released and still doesnt contain what users are waiting for...
>
> When i spoke about > 1.0 just understand when last release answer basic
> needs
> Le 24 mars 2013 16:49, "John D. Ament" <jo...@gmail.com> a écrit :
>
> > Romain,
> >
> > I'm not sure what to tell you. One of our founding statements was
> release
> > early and often. I'm not sure why we haven't stuck to that.
> Personally, I
> > think we have failed to do that. We probably have too many features in a
> > single release/ not much release planning/attempt to release everything
> as
> > one big release rather than more modular in nature. Those are just
> > thoughts.
> >
> > As I already stated, I don't want this in 0.4. But I don't think it's
> > appropriate to stick this in after 1.0, who knows when that will be. I
> > would love to see this in 0.5, already have prototypes working. My
> biggest
> > issue, as I was trying to raise in the other thread, is that when people
> > look at the issue list out there, generally the candidates to work on are
> > the unassigned issues. If 80% of what we have out there is assigned,
> then
> > it's assumed someone's work on it. If it's assigned to someone and
> they're
> > not working on it, that's probably an issue that needs to be addressed.
> As
> > far as I can tell, of the 10 unassigned issues out there, none of them
> are
> > comprehensible enough (other than the one I already worked on) to be
> worked
> > through. So I'm not sure, maybe it's an issue of perception, but I don't
> > think we have a large pile of open work for future releases.
> >
> > John
> >
> >
> > On Sun, Mar 24, 2013 at 11:19 AM, Romain Manni-Bucau
> > <rm...@gmail.com>wrote:
> >
> > > Sure but we cant start everything, finishing nothing...our rare
> releases
> > > are already a pain for users.
> > >
> > > We need jsf + if possible cdi query for 0.4 IMO then i agree rest
> helpers
> > > are a must have (some tools around jaxrs client part can be great)
> etc...
> > > Le 24 mars 2013 16:13, "John D. Ament" <jo...@gmail.com> a
> écrit
> > :
> > >
> > > > Romain,
> > > >
> > > > My only issue with this is that I don't think we've mapped out what
> the
> > > > common use cases are (at least based on the email I sent out). If
> > we're
> > > > favoring JSF, we're neglecting the growing population of REST APIs
> for
> > > rich
> > > > javascript clients (from UI).
> > > >
> > > >
> > > > On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau
> > > > <rm...@gmail.com>wrote:
> > > >
> > > > > yes but JMS is clearly not the most used
> > > > >
> > > > > can't we push it for the > 1.0?
> > > > >
> > > > > users really wait the first 1.0 to use DS and adding JMS now simply
> > > looks
> > > > > like forgetting more common use cases
> > > > >
> > > > > *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/23 Gerhard Petracek <ge...@gmail.com>
> > > > >
> > > > > > hi @ all,
> > > > > >
> > > > > > imo it's more a basic question.
> > > > > > if we do it for jms 2, we also have to (/should) do it for other
> > > > > > specifications like bv 1.1
> > > > > >
> > > > > > regards,
> > > > > > gerhard
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
> > > > > >
> > > > > > > Ill rephrase a bit. I m rather -0 about it and -1 since a lot
> of
> > > > others
> > > > > > > stuff are needed before.
> > > > > > > Le 21 mars 2013 22:50, "Arne Limburg" <
> > > arne.limburg@openknowledge.de
> > > > >
> > > > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > > 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 <jo...@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
> > > > > > > > >> <rm...@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 <jo...@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
> > > > > > > > >>> >
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: DISCUSS DeltaSpike-324
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I get you and think we agree behund words. My main issue is our 0.4 is not
ready to be released and still doesnt contain what users are waiting for...
When i spoke about > 1.0 just understand when last release answer basic
needs
Le 24 mars 2013 16:49, "John D. Ament" <jo...@gmail.com> a écrit :
> Romain,
>
> I'm not sure what to tell you. One of our founding statements was release
> early and often. I'm not sure why we haven't stuck to that. Personally, I
> think we have failed to do that. We probably have too many features in a
> single release/ not much release planning/attempt to release everything as
> one big release rather than more modular in nature. Those are just
> thoughts.
>
> As I already stated, I don't want this in 0.4. But I don't think it's
> appropriate to stick this in after 1.0, who knows when that will be. I
> would love to see this in 0.5, already have prototypes working. My biggest
> issue, as I was trying to raise in the other thread, is that when people
> look at the issue list out there, generally the candidates to work on are
> the unassigned issues. If 80% of what we have out there is assigned, then
> it's assumed someone's work on it. If it's assigned to someone and they're
> not working on it, that's probably an issue that needs to be addressed. As
> far as I can tell, of the 10 unassigned issues out there, none of them are
> comprehensible enough (other than the one I already worked on) to be worked
> through. So I'm not sure, maybe it's an issue of perception, but I don't
> think we have a large pile of open work for future releases.
>
> John
>
>
> On Sun, Mar 24, 2013 at 11:19 AM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
> > Sure but we cant start everything, finishing nothing...our rare releases
> > are already a pain for users.
> >
> > We need jsf + if possible cdi query for 0.4 IMO then i agree rest helpers
> > are a must have (some tools around jaxrs client part can be great) etc...
> > Le 24 mars 2013 16:13, "John D. Ament" <jo...@gmail.com> a écrit
> :
> >
> > > Romain,
> > >
> > > My only issue with this is that I don't think we've mapped out what the
> > > common use cases are (at least based on the email I sent out). If
> we're
> > > favoring JSF, we're neglecting the growing population of REST APIs for
> > rich
> > > javascript clients (from UI).
> > >
> > >
> > > On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau
> > > <rm...@gmail.com>wrote:
> > >
> > > > yes but JMS is clearly not the most used
> > > >
> > > > can't we push it for the > 1.0?
> > > >
> > > > users really wait the first 1.0 to use DS and adding JMS now simply
> > looks
> > > > like forgetting more common use cases
> > > >
> > > > *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/23 Gerhard Petracek <ge...@gmail.com>
> > > >
> > > > > hi @ all,
> > > > >
> > > > > imo it's more a basic question.
> > > > > if we do it for jms 2, we also have to (/should) do it for other
> > > > > specifications like bv 1.1
> > > > >
> > > > > regards,
> > > > > gerhard
> > > > >
> > > > >
> > > > >
> > > > > 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
> > > > >
> > > > > > Ill rephrase a bit. I m rather -0 about it and -1 since a lot of
> > > others
> > > > > > stuff are needed before.
> > > > > > Le 21 mars 2013 22:50, "Arne Limburg" <
> > arne.limburg@openknowledge.de
> > > >
> > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > 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 <jo...@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
> > > > > > > >> <rm...@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 <jo...@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
> > > > > > > >>> >
> > > > > > > >>>
> > > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: DISCUSS DeltaSpike-324
Posted by "John D. Ament" <jo...@gmail.com>.
Romain,
I'm not sure what to tell you. One of our founding statements was release
early and often. I'm not sure why we haven't stuck to that. Personally, I
think we have failed to do that. We probably have too many features in a
single release/ not much release planning/attempt to release everything as
one big release rather than more modular in nature. Those are just
thoughts.
As I already stated, I don't want this in 0.4. But I don't think it's
appropriate to stick this in after 1.0, who knows when that will be. I
would love to see this in 0.5, already have prototypes working. My biggest
issue, as I was trying to raise in the other thread, is that when people
look at the issue list out there, generally the candidates to work on are
the unassigned issues. If 80% of what we have out there is assigned, then
it's assumed someone's work on it. If it's assigned to someone and they're
not working on it, that's probably an issue that needs to be addressed. As
far as I can tell, of the 10 unassigned issues out there, none of them are
comprehensible enough (other than the one I already worked on) to be worked
through. So I'm not sure, maybe it's an issue of perception, but I don't
think we have a large pile of open work for future releases.
John
On Sun, Mar 24, 2013 at 11:19 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> Sure but we cant start everything, finishing nothing...our rare releases
> are already a pain for users.
>
> We need jsf + if possible cdi query for 0.4 IMO then i agree rest helpers
> are a must have (some tools around jaxrs client part can be great) etc...
> Le 24 mars 2013 16:13, "John D. Ament" <jo...@gmail.com> a écrit :
>
> > Romain,
> >
> > My only issue with this is that I don't think we've mapped out what the
> > common use cases are (at least based on the email I sent out). If we're
> > favoring JSF, we're neglecting the growing population of REST APIs for
> rich
> > javascript clients (from UI).
> >
> >
> > On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau
> > <rm...@gmail.com>wrote:
> >
> > > yes but JMS is clearly not the most used
> > >
> > > can't we push it for the > 1.0?
> > >
> > > users really wait the first 1.0 to use DS and adding JMS now simply
> looks
> > > like forgetting more common use cases
> > >
> > > *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/23 Gerhard Petracek <ge...@gmail.com>
> > >
> > > > hi @ all,
> > > >
> > > > imo it's more a basic question.
> > > > if we do it for jms 2, we also have to (/should) do it for other
> > > > specifications like bv 1.1
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
> > > >
> > > > > Ill rephrase a bit. I m rather -0 about it and -1 since a lot of
> > others
> > > > > stuff are needed before.
> > > > > Le 21 mars 2013 22:50, "Arne Limburg" <
> arne.limburg@openknowledge.de
> > >
> > > a
> > > > > écrit :
> > > > >
> > > > > > 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 <jo...@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
> > > > > > >> <rm...@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 <jo...@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
> > > > > > >>> >
> > > > > > >>>
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: DISCUSS DeltaSpike-324
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Sure but we cant start everything, finishing nothing...our rare releases
are already a pain for users.
We need jsf + if possible cdi query for 0.4 IMO then i agree rest helpers
are a must have (some tools around jaxrs client part can be great) etc...
Le 24 mars 2013 16:13, "John D. Ament" <jo...@gmail.com> a écrit :
> Romain,
>
> My only issue with this is that I don't think we've mapped out what the
> common use cases are (at least based on the email I sent out). If we're
> favoring JSF, we're neglecting the growing population of REST APIs for rich
> javascript clients (from UI).
>
>
> On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
> > yes but JMS is clearly not the most used
> >
> > can't we push it for the > 1.0?
> >
> > users really wait the first 1.0 to use DS and adding JMS now simply looks
> > like forgetting more common use cases
> >
> > *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/23 Gerhard Petracek <ge...@gmail.com>
> >
> > > hi @ all,
> > >
> > > imo it's more a basic question.
> > > if we do it for jms 2, we also have to (/should) do it for other
> > > specifications like bv 1.1
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
> > >
> > > > Ill rephrase a bit. I m rather -0 about it and -1 since a lot of
> others
> > > > stuff are needed before.
> > > > Le 21 mars 2013 22:50, "Arne Limburg" <arne.limburg@openknowledge.de
> >
> > a
> > > > écrit :
> > > >
> > > > > 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 <jo...@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
> > > > > >> <rm...@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 <jo...@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
> > > > > >>> >
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: DISCUSS DeltaSpike-324
Posted by "John D. Ament" <jo...@gmail.com>.
Romain,
My only issue with this is that I don't think we've mapped out what the
common use cases are (at least based on the email I sent out). If we're
favoring JSF, we're neglecting the growing population of REST APIs for rich
javascript clients (from UI).
On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> yes but JMS is clearly not the most used
>
> can't we push it for the > 1.0?
>
> users really wait the first 1.0 to use DS and adding JMS now simply looks
> like forgetting more common use cases
>
> *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/23 Gerhard Petracek <ge...@gmail.com>
>
> > hi @ all,
> >
> > imo it's more a basic question.
> > if we do it for jms 2, we also have to (/should) do it for other
> > specifications like bv 1.1
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
> >
> > > Ill rephrase a bit. I m rather -0 about it and -1 since a lot of others
> > > stuff are needed before.
> > > Le 21 mars 2013 22:50, "Arne Limburg" <ar...@openknowledge.de>
> a
> > > écrit :
> > >
> > > > 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 <st...@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 <jo...@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
> > > > >> <rm...@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 <jo...@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
> > > > >>> >
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: DISCUSS DeltaSpike-324
Posted by Romain Manni-Bucau <rm...@gmail.com>.
yes but JMS is clearly not the most used
can't we push it for the > 1.0?
users really wait the first 1.0 to use DS and adding JMS now simply looks
like forgetting more common use cases
*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/23 Gerhard Petracek <ge...@gmail.com>
> hi @ all,
>
> imo it's more a basic question.
> if we do it for jms 2, we also have to (/should) do it for other
> specifications like bv 1.1
>
> regards,
> gerhard
>
>
>
> 2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
>
> > Ill rephrase a bit. I m rather -0 about it and -1 since a lot of others
> > stuff are needed before.
> > Le 21 mars 2013 22:50, "Arne Limburg" <ar...@openknowledge.de> a
> > écrit :
> >
> > > 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 <st...@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 <jo...@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
> > > >> <rm...@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 <jo...@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
> > > >>> >
> > > >>>
> > > >>
> > >
> > >
> >
>
Re: DISCUSS DeltaSpike-324
Posted by Gerhard Petracek <ge...@gmail.com>.
hi @ all,
imo it's more a basic question.
if we do it for jms 2, we also have to (/should) do it for other
specifications like bv 1.1
regards,
gerhard
2013/3/21 Romain Manni-Bucau <rm...@gmail.com>
> Ill rephrase a bit. I m rather -0 about it and -1 since a lot of others
> stuff are needed before.
> Le 21 mars 2013 22:50, "Arne Limburg" <ar...@openknowledge.de> a
> écrit :
>
> > 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 <st...@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 <jo...@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
> > >> <rm...@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 <jo...@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
> > >>> >
> > >>>
> > >>
> >
> >
>
Re: DISCUSS DeltaSpike-324
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Ill rephrase a bit. I m rather -0 about it and -1 since a lot of others
stuff are needed before.
Le 21 mars 2013 22:50, "Arne Limburg" <ar...@openknowledge.de> a
écrit :
> 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 <st...@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 <jo...@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
> >> <rm...@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 <jo...@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
> >>> >
> >>>
> >>
>
>
Re: DISCUSS DeltaSpike-324
Posted by "John D. Ament" <jo...@gmail.com>.
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 <st...@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 <jo...@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
> >> <rm...@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 <jo...@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
> >>> >
> >>>
> >>
>
>
Re: DISCUSS DeltaSpike-324
Posted by "John D. Ament" <jo...@gmail.com>.
On Thu, Mar 21, 2013 at 5:34 PM, Mark Struberg <st...@yahoo.de> wrote:
> I tend to lean towards +1 simply because EE-7 containers will take another
> year (or 2) to become used in projects.
>
>
Agreed. I think a lot of people learned lessons jumping in to GF3 quickly
after release for EE 6.
> I just think we should first close a few tasks before we open new ones.
>
+1 as well. Only wanted to start discussion. I don't think we should try
to include this in 0.4 (BTW - when's 0.4 coming out?)
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
> > From: John D. Ament <jo...@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
> > <rm...@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 <jo...@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
> >> >
> >>
> >
>
Re: DISCUSS DeltaSpike-324
Posted by Jason Porter <li...@gmail.com>.
That's typically more pain for a user, and may cause issues with a service contract. I say we implement this is DS for those who need it.
—
Sent from Mailbox for iPhone
On Thu, Mar 21, 2013 at 3:50 PM, Arne Limburg
<ar...@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 <st...@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 <jo...@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
>>> <rm...@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 <jo...@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
>>>> >
>>>>
>>>
Re: DISCUSS DeltaSpike-324
Posted by Arne Limburg <ar...@openknowledge.de>.
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 <st...@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 <jo...@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
>> <rm...@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 <jo...@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
>>> >
>>>
>>
Re: DISCUSS DeltaSpike-324
Posted by Mark Struberg <st...@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 <jo...@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
> <rm...@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 <jo...@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
>> >
>>
>
Re: DISCUSS DeltaSpike-324
Posted by "John D. Ament" <jo...@gmail.com>.
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
<rm...@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 <jo...@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
> >
>
Re: DISCUSS DeltaSpike-324
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <jo...@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
>