from:"John D. Ament"


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13613703#comment-13613703
 ] 

John D. Ament commented on DELTASPIKE-263:
--

[~cmoulliard] No one's saying close this/don't do it.  I was asking if you had 
availability to work on it for 0.4.

[~gpetracek] I believe you mean https://issues.jboss.org/browse/CDI-18 which 
appears to be resolved now in 1.1.

 Generate binaries of DeltaSpike project
 ---

 Key: DELTASPIKE-263
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-263
 Project: DeltaSpike
  Issue Type: New Feature
Affects Versions: 0.3-incubating
Reporter: Charles Moulliard
Assignee: Charles Moulliard
 Fix For: 0.4-incubating




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DELTASPIKE-263) Generate binaries of DeltaSpike project


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13613739#comment-13613739
 ] 

John D. Ament commented on DELTASPIKE-263:
--

[~gpetracek] it seems like we're trying to cover two different issues.  This is 
simply to create binaries.  If there are issues with CDI in EARs I don't see 
how that's relevant.

I'd rather this issue simply focus on providing DS binaries.

 Generate binaries of DeltaSpike project
 ---

 Key: DELTASPIKE-263
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-263
 Project: DeltaSpike
  Issue Type: New Feature
Affects Versions: 0.3-incubating
Reporter: Charles Moulliard
Assignee: Charles Moulliard
 Fix For: 0.4-incubating




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Heading towards a 0.4 release

2013-03-26 Thread John D. Ament

Jason,

Does that mean we are no longer bringing XML config to DeltaSpike, even
though it was already voted in?


On Tue, Mar 26, 2013 at 9:10 AM, Jason Porter lightguard...@gmail.comwrote:

 Wrt xml-config, I'll be working on configuring cdi via osgi blueprint,
 over in the Aries project. If we want to port over the seam config stuff,
 we can certainly do that too.
 —
 Sent from Mailbox for iPhone

 On Tue, Mar 26, 2013 at 4:42 AM, Romain Manni-Bucau rmannibu...@gmail.com
 
 wrote:

  @Gerhard: the point about proxy was i thought it was not straight forward
  since some people will not want to bring any additional lib for it
 (because
  they use only interfaces and proxy libs can conflcts). Wonder if handling
  it with a dep optional couldn't do the trick too.
  *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/26 Gerhard Petracek gerhard.petra...@gmail.com
  @ romain:
  imo it doesn't make sense to remove something (and add it later on
 again),
  if it's just a matter of few hours (to do it immediately).
  anybody is welcome to work on DS-333.
 
  @ DS-288
  it's almost done and as i mentioned earlier i'll finish it once DS-289
 is
  done.
  (yes we need it for 0.4)
 
  @ xml-config
  afair we had an agreement already, but nobody worked on it.
 
  regards,
  gerhard
 
 
 
  2013/3/26 John D. Ament john.d.am...@gmail.com
 
   I think leaving proxy support to full interface only for now makes
 sense,
   we can enrich this further in another release.  How about we close 113
  as a
   reduced scope and open a new issue for remaining items?  I see you
  already
   did some Gerhard, but we still have abstract classes as a case as
 well.
  
   Gerhard, can you also comment on 288? Do we need this in 0.4 or can it
   wait?
  
   Romain, I didn't quite get you.  Are you saying you're on hold on this
  one
   (dependent on something?).
  
   Does anyone believe we need Seam XML Config in 0.4? (DS-269 to 272).
  I'd
   prefer to move it.
  
   For DS-105, it looks like consensus is to keep it since it's needed
 for
   older Weld versions. If so can we close as will not fix?
  
   Jason P - Can you look at DS-132/134? Do we need these?  There are
 other
   catch like issues out there.  Are they needed?
  
   Mark S - You have 12 issues assigned to you :/
  
   BTW I created a new filter - only open issues [1]
  
   John
  
   [1] https://issues.apache.org/jira/issues/?filter=12323789
  
  
   On Mon, Mar 25, 2013 at 12:49 PM, Romain Manni-Bucau
   rmannibu...@gmail.comwrote:
  
Hi
   
DS-60: we are a bunch o wait after it
   
DS-113: think we can push partial bean to another release and keep
interface handling for this iteration (well if you import asm part
  right
now it can work but then the question will be which shade version? a
   proxy
as in cxf?)
   
other are not blocker IMO
   
   
*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/25 Gerhard Petracek gerhard.petra...@gmail.com
   
 hi john,

 @ examples:
 we haven't discussed what our goal is here

 @ DS-60
 imo we should do it for 0.5 (and release 0.5 short after 0.4)

 @ DS-113
 we have to change the proxy-lib and move it to an own module
 (i'll create the module today)

 @ DS-263
 not needed, but nice to have - +1
 (you can have a look at the setup we used in codi for it to know
 what
   you
 need)

 @ DS-278
 i re-opened it because we should find a better approach imo.
 however, it isn't a real blocker

 regards,
 gerhard



 2013/3/25 John D. Ament john.d.am...@gmail.com

  All,
 
  Based on the flurry of threads, I wanted to help get things
 started
   to
 move
  towards a 0.4 release.  I created the filter at [1] to show our
   current
  progress.
 
  We currently have 50 issues fixed in 0.4, with 27 unresolved for
  the
  release.  Some of these issues stick out, with me thinking that
  we've
  actually completed them but perhaps need some finalization
 (note:
   I'll
 use
  the abbreviation DS for the DELTASPIKE key in JIRA which is
 TL;DR)
 
  DS-306 - I see examples.  Do we need more?
  DS-60 - I believe we have started integrating CDI Query.  Should
  this
 have
  spawned child tasks?
  DS-113 - Gerhard took the reigns on this one and apparently it
  works
just
  like the Seam3 version.  Can this be closed?
 
 
  Some low hanging fruit:
 
  DS-263 - I

[jira] [Updated] (DELTASPIKE-271) Import Seam Config from Solder


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-271:
-

Fix Version/s: (was: 0.4-incubating)
   0.5-incubating

 Import Seam Config from Solder
 --

 Key: DELTASPIKE-271
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-271
 Project: DeltaSpike
  Issue Type: Sub-task
  Components: Configuration
Affects Versions: 0.4-incubating
Reporter: Jason Porter
 Fix For: 0.5-incubating




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DELTASPIKE-270) Create api and impl spaces for the module


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-270:
-

Fix Version/s: (was: 0.4-incubating)
   0.5-incubating

 Create api and impl spaces for the module
 -

 Key: DELTASPIKE-270
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-270
 Project: DeltaSpike
  Issue Type: Sub-task
  Components: Configuration
Affects Versions: 0.4-incubating
Reporter: Jason Porter
 Fix For: 0.5-incubating




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DELTASPIKE-272) Copy documentation from Seam Solder for configuration


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-272:
-

Fix Version/s: (was: 0.4-incubating)
   0.5-incubating

 Copy documentation from Seam Solder for configuration
 -

 Key: DELTASPIKE-272
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-272
 Project: DeltaSpike
  Issue Type: Sub-task
  Components: Configuration
Affects Versions: 0.4-incubating
Reporter: Jason Porter
 Fix For: 0.5-incubating




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Heading towards a 0.4 release

2013-03-26 Thread John D. Ament

Ok.  How about the open catch issues? Do you feel any of those are needed
for 0.4?


On Tue, Mar 26, 2013 at 9:28 AM, Jason Porter lightguard...@gmail.comwrote:

 The last time I asked about it the responses seemed lukewarm, so I figured
 it wasn't something people really cared about. We could certainly add it in
 post 0.4 if there really is a desire for it.
 —
 Sent from Mailbox for iPhone

 On Tue, Mar 26, 2013 at 7:23 AM, John D. Ament john.d.am...@gmail.com
 wrote:

  Jason,
  Does that mean we are no longer bringing XML config to DeltaSpike, even
  though it was already voted in?
  On Tue, Mar 26, 2013 at 9:10 AM, Jason Porter lightguard...@gmail.com
 wrote:
  Wrt xml-config, I'll be working on configuring cdi via osgi blueprint,
  over in the Aries project. If we want to port over the seam config
 stuff,
  we can certainly do that too.
  —
  Sent from Mailbox for iPhone
 
  On Tue, Mar 26, 2013 at 4:42 AM, Romain Manni-Bucau 
 rmannibu...@gmail.com
  
  wrote:
 
   @Gerhard: the point about proxy was i thought it was not straight
 forward
   since some people will not want to bring any additional lib for it
  (because
   they use only interfaces and proxy libs can conflcts). Wonder if
 handling
   it with a dep optional couldn't do the trick too.
   *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/26 Gerhard Petracek gerhard.petra...@gmail.com
   @ romain:
   imo it doesn't make sense to remove something (and add it later on
  again),
   if it's just a matter of few hours (to do it immediately).
   anybody is welcome to work on DS-333.
  
   @ DS-288
   it's almost done and as i mentioned earlier i'll finish it once
 DS-289
  is
   done.
   (yes we need it for 0.4)
  
   @ xml-config
   afair we had an agreement already, but nobody worked on it.
  
   regards,
   gerhard
  
  
  
   2013/3/26 John D. Ament john.d.am...@gmail.com
  
I think leaving proxy support to full interface only for now makes
  sense,
we can enrich this further in another release.  How about we close
 113
   as a
reduced scope and open a new issue for remaining items?  I see you
   already
did some Gerhard, but we still have abstract classes as a case as
  well.
   
Gerhard, can you also comment on 288? Do we need this in 0.4 or
 can it
wait?
   
Romain, I didn't quite get you.  Are you saying you're on hold on
 this
   one
(dependent on something?).
   
Does anyone believe we need Seam XML Config in 0.4? (DS-269 to
 272).
   I'd
prefer to move it.
   
For DS-105, it looks like consensus is to keep it since it's needed
  for
older Weld versions. If so can we close as will not fix?
   
Jason P - Can you look at DS-132/134? Do we need these?  There are
  other
catch like issues out there.  Are they needed?
   
Mark S - You have 12 issues assigned to you :/
   
BTW I created a new filter - only open issues [1]
   
John
   
[1] https://issues.apache.org/jira/issues/?filter=12323789
   
   
On Mon, Mar 25, 2013 at 12:49 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
   
 Hi

 DS-60: we are a bunch o wait after it

 DS-113: think we can push partial bean to another release and
 keep
 interface handling for this iteration (well if you import asm
 part
   right
 now it can work but then the question will be which shade
 version? a
proxy
 as in cxf?)

 other are not blocker IMO


 *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/25 Gerhard Petracek gerhard.petra...@gmail.com

  hi john,
 
  @ examples:
  we haven't discussed what our goal is here
 
  @ DS-60
  imo we should do it for 0.5 (and release 0.5 short after 0.4)
 
  @ DS-113
  we have to change the proxy-lib and move it to an own module
  (i'll create the module today)
 
  @ DS-263
  not needed, but nice to have - +1
  (you can have a look at the setup we used in codi for it to
 know
  what
you
  need)
 
  @ DS-278
  i re-opened it because we should find a better approach imo.
  however, it isn't a real blocker
 
  regards,
  gerhard
 
 
 
  2013/3/25 John D. Ament john.d.am...@gmail.com
 
   All,
  
   Based on the flurry of threads, I wanted to help get things
  started
to
  move
   towards a 0.4 release.  I created the filter at [1] to show
 our
current
   progress.
  
   We currently have 50 issues fixed in 0.4

[jira] [Updated] (DELTASPIKE-269) Add XML Config from Seam


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-269:
-

Fix Version/s: (was: 0.4-incubating)
   0.5-incubating

 Add XML Config from Seam
 

 Key: DELTASPIKE-269
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-269
 Project: DeltaSpike
  Issue Type: Task
  Components: Configuration
Affects Versions: 0.4-incubating
Reporter: Jason Porter
Assignee: Jason Porter
 Fix For: 0.5-incubating


 Umbrella issue for adding in Seam Config

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DELTASPIKE-105) remove workarounds for weld


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-105.
--

Resolution: Won't Fix

Consensus was that the work arounds are needed for older Weld versions.

 remove workarounds for weld
 ---

 Key: DELTASPIKE-105
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-105
 Project: DeltaSpike
  Issue Type: Sub-task
  Components: CdiControl
Affects Versions: 0.2-incubating
Reporter: Gerhard Petracek
Assignee: Ales Justin
 Fix For: 0.4-incubating


 currently we have 2 workarounds which need to be removed as soon as we have a 
 released version of weld which fixes the following issues:
 #1 the application scope doesn't get restarted autom. after it is invalidated 
 and it can't be started manually (reason: IsolatedStaticSingleton.object is 
 null after calling applicationContext#invalidate and causes a NPE as soon as 
 the scope gets accessed again)
 the workaround is in ContextController#stopApplicationScope
 #2 AbstractSharedContext#isActive always returns true
 the workaround is in ContainerCtrlTckTest#reStartContexts
 ContainerCtrlTckTest#reStartContexts has to pass without workarounds

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Heading towards a 0.4 release

2013-03-26 Thread John D. Ament

I moved the XML config to 0.5

I resolver DS-105 since no additional comments on it and general consensus
was that it was needed for backwards compatibility.


On Tue, Mar 26, 2013 at 9:40 AM, John D. Ament john.d.am...@gmail.comwrote:

 Ok.  How about the open catch issues? Do you feel any of those are needed
 for 0.4?


 On Tue, Mar 26, 2013 at 9:28 AM, Jason Porter lightguard...@gmail.comwrote:

 The last time I asked about it the responses seemed lukewarm, so I
 figured it wasn't something people really cared about. We could certainly
 add it in post 0.4 if there really is a desire for it.
 —
 Sent from Mailbox for iPhone

 On Tue, Mar 26, 2013 at 7:23 AM, John D. Ament john.d.am...@gmail.com
 wrote:

  Jason,
  Does that mean we are no longer bringing XML config to DeltaSpike, even
  though it was already voted in?
  On Tue, Mar 26, 2013 at 9:10 AM, Jason Porter lightguard...@gmail.com
 wrote:
  Wrt xml-config, I'll be working on configuring cdi via osgi blueprint,
  over in the Aries project. If we want to port over the seam config
 stuff,
  we can certainly do that too.
  —
  Sent from Mailbox for iPhone
 
  On Tue, Mar 26, 2013 at 4:42 AM, Romain Manni-Bucau 
 rmannibu...@gmail.com
  
  wrote:
 
   @Gerhard: the point about proxy was i thought it was not straight
 forward
   since some people will not want to bring any additional lib for it
  (because
   they use only interfaces and proxy libs can conflcts). Wonder if
 handling
   it with a dep optional couldn't do the trick too.
   *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/26 Gerhard Petracek gerhard.petra...@gmail.com
   @ romain:
   imo it doesn't make sense to remove something (and add it later on
  again),
   if it's just a matter of few hours (to do it immediately).
   anybody is welcome to work on DS-333.
  
   @ DS-288
   it's almost done and as i mentioned earlier i'll finish it once
 DS-289
  is
   done.
   (yes we need it for 0.4)
  
   @ xml-config
   afair we had an agreement already, but nobody worked on it.
  
   regards,
   gerhard
  
  
  
   2013/3/26 John D. Ament john.d.am...@gmail.com
  
I think leaving proxy support to full interface only for now makes
  sense,
we can enrich this further in another release.  How about we
 close 113
   as a
reduced scope and open a new issue for remaining items?  I see you
   already
did some Gerhard, but we still have abstract classes as a case as
  well.
   
Gerhard, can you also comment on 288? Do we need this in 0.4 or
 can it
wait?
   
Romain, I didn't quite get you.  Are you saying you're on hold on
 this
   one
(dependent on something?).
   
Does anyone believe we need Seam XML Config in 0.4? (DS-269 to
 272).
   I'd
prefer to move it.
   
For DS-105, it looks like consensus is to keep it since it's
 needed
  for
older Weld versions. If so can we close as will not fix?
   
Jason P - Can you look at DS-132/134? Do we need these?  There are
  other
catch like issues out there.  Are they needed?
   
Mark S - You have 12 issues assigned to you :/
   
BTW I created a new filter - only open issues [1]
   
John
   
[1] https://issues.apache.org/jira/issues/?filter=12323789
   
   
On Mon, Mar 25, 2013 at 12:49 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
   
 Hi

 DS-60: we are a bunch o wait after it

 DS-113: think we can push partial bean to another release and
 keep
 interface handling for this iteration (well if you import asm
 part
   right
 now it can work but then the question will be which shade
 version? a
proxy
 as in cxf?)

 other are not blocker IMO


 *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/25 Gerhard Petracek gerhard.petra...@gmail.com

  hi john,
 
  @ examples:
  we haven't discussed what our goal is here
 
  @ DS-60
  imo we should do it for 0.5 (and release 0.5 short after
 0.4)
 
  @ DS-113
  we have to change the proxy-lib and move it to an own module
  (i'll create the module today)
 
  @ DS-263
  not needed, but nice to have - +1
  (you can have a look at the setup we used in codi for it to
 know
  what
you
  need)
 
  @ DS-278
  i re-opened it because we should find a better approach imo.
  however, it isn't a real blocker
 
  regards,
  gerhard
 
 
 
  2013/3/25 John D. Ament john.d.am...@gmail.com
 
   All

Re: DISCUSS DeltaSpike-324

2013-03-25 Thread John D. Ament

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 cody.le...@gmail.com wrote:

 +1
 On Mar 25, 2013 8:04 AM, Nicklas Karlsson nicka...@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 rmannibu...@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 lightguard...@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
rmannibu...@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.petra...@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 rmannibu...@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 john.d.am...@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

[jira] [Updated] (DELTASPIKE-289) implement WindowContext


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-289:
-

Fix Version/s: 0.4-incubating

 implement WindowContext
 ---

 Key: DELTASPIKE-289
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-289
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Core, JSF-Module
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 Introduce a way to manage different beans depending on a 'window' or browser 
 tab notion.
 A WindowContext stores all the information for a single 'window' or browser 
 tab. The WindowContextManager keeps all open WindowContexts (for a session) 
 and allows to set or determine the one which got activated for the current 
 Thread.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Heading towards a 0.4 release

2013-03-25 Thread John D. Ament

All,

Based on the flurry of threads, I wanted to help get things started to move
towards a 0.4 release.  I created the filter at [1] to show our current
progress.

We currently have 50 issues fixed in 0.4, with 27 unresolved for the
release.  Some of these issues stick out, with me thinking that we've
actually completed them but perhaps need some finalization (note: I'll use
the abbreviation DS for the DELTASPIKE key in JIRA which is TL;DR)

DS-306 - I see examples.  Do we need more?
DS-60 - I believe we have started integrating CDI Query.  Should this have
spawned child tasks?
DS-113 - Gerhard took the reigns on this one and apparently it works just
like the Seam3 version.  Can this be closed?


Some low hanging fruit:

DS-263 - I was actually looking for something like this as well.  I've been
playing with JBoss modules a lot and think having a binary release would
help add DS as a JBoss Module.  If this isn't complete, do we need it in
0.4?

DS-278 - If not done, seems easy enough to add.

DS-288 - Seems like another needed feature, but wasn't too difficult in
either CODI or Seam3.

DS-289 - Ironically, this one isn't even scheduled for 0.4 but is a blocker
for the release.  I'll update it as such.

If you have something in the list below that shouldn't be (e.g. it's not
needed for 0.4) we should get it rescheduled.  Since previously only 289
was declared needed for 0.4 we should be looking at everything else.

John

[1]: https://issues.apache.org/jira/issues/?filter=12323788

[jira] [Created] (DELTASPIKE-328) Create ClientWindow API

John D. Ament created DELTASPIKE-328:


 Summary: Create ClientWindow API
 Key: DELTASPIKE-328
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-328
 Project: DeltaSpike
  Issue Type: Sub-task
Reporter: John D. Ament
 Fix For: 0.4-incubating


To mirror JSF 2.2 feature, need to create a ClientWindow API.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (DELTASPIKE-329) Create a WindowContextManager

John D. Ament created DELTASPIKE-329:


 Summary: Create a WindowContextManager
 Key: DELTASPIKE-329
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-329
 Project: DeltaSpike
  Issue Type: Sub-task
Reporter: John D. Ament
 Fix For: 0.4-incubating


Need to add a WindowContextManager to handle all of the client windows.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (DELTASPIKE-330) Create a new WindowScope to represent beans that are bound to a browser window

John D. Ament created DELTASPIKE-330:


 Summary: Create a new WindowScope to represent beans that are 
bound to a browser window
 Key: DELTASPIKE-330
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-330
 Project: DeltaSpike
  Issue Type: Sub-task
Reporter: John D. Ament
 Fix For: 0.4-incubating


Need to add a WindowScope to bind beans to a window context/browser window.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: DeltaSpike Roadmap

2013-03-25 Thread John D. Ament

I believe all of the major JSF component libraries support some type of
form validation using BV.

On Mon, Mar 25, 2013 at 12:19 PM, Thomas Andraschko
andraschko.tho...@gmail.com wrote:

Any news about s:validateForm?
As i said, it's great feature of seam3 and would perfectly fit DS (IMO).

I could also add it to DS if no one have enough time... :)

2012/12/17 Gerhard Petracek gerhard.petra...@gmail.com

there is a reason why it is just an add-on ;)
and yes, if you would do it with the jsf2-api, it would be a bit easier.
but you can use this add-on also for jsf 1.x and some users who don't
like
to use seam are happy with it.
however, i just mentioned it as an example to show that cdi isn't needed
to
implement such a functionality.

regards,
gerhard

2012/12/17 Lincoln Baxter, III lincolnbax...@gmail.com

Also, note that the use-cases for s:validateForm and the latter
example
are different in their usage. IMO, s:validateForm is much more
declarative and simple than the example provided from extval.

Just write a validator and attach it like you would normal to a
component
in the view, wherever you want to use it. You can also re-use
form-validators using this method, instead of using some (in my
opinion)
strange view-filtering logic in the FormValidator annotation.

s:validateForm is/was one of the most well recieved feature of Seam
Faces, and I think it deserves serious consideration. Can you do form
validation other ways? absolutely, but this way is pretty compelling
based
on the feedback we got. It also ties in very normally with the way in
which
JSF handles validation and components, which is not something that I
can
speak about with regard to extval, but I can say that seam faces does
this
nicely.

~Lincoln

On Mon, Dec 17, 2012 at 4:37 PM, Thomas Andraschko
andraschko.tho...@gmail.com wrote:

Please do not mix both :)
We had the discussion about commons bv constrains. s:validateForm is
completely different compared to bv constraints.
s:validateForm does not fit the project for common bv constraints.

2012/12/17 Karl Kildén karl.kil...@gmail.com

Looks really nice I understand finally :-)

In retrospect I don't know why I didn't check the docs myself,
probably
because I read most of the discussion on the phone to begin with.

I then agree with the many suggestions regarding doing it as a
parallel
project. Perhaps that module could have a sub module for CDI users
that
included producers and such.

Best regards / Karl

2012/12/17 Gerhard Petracek gerhard.petra...@gmail.com

hi karl,

it's implemented via a producer - see [1].
but you don't really need cdi for it - see e.g. [2].

regards,
gerhard

[1] http://s.apache.org/ury
[2]

http://os890.blogspot.co.at/2010/06/multi-field-form-validation-with-jsr.html

2012/12/17 Thomas Andraschko andraschko.tho...@gmail.com

As far as i understand, validateAll just validates all
components
but
you
can't use custom logic.

Checkout the seam docu here:

http://docs.jboss.org/seam/3/faces/latest/reference/en-US/html/components.html

2012/12/17 Karl Kildén karl.kil...@gmail.com

Hrmm still not sure I understand. First off didn't Pete just
say
it
was
just a JSF-validator? It also sounds and reads just like
validateAll
from
omnifaces?

What is lacking that you would like to see solved by CDI? And
is
it a
natural fit for CDI extensions rather then BV / JSF
extensions?

Best regards / Karl

2012/12/17 Thomas Andraschko andraschko.tho...@gmail.com

Hi,

they are nice but i can't see a replacement for
s:validateForm.
IMO s:validateForm is really a simple solution for
cross-field
validation,
which is CDI based.

Regards,
THomas

2012/12/17 Karl Kildén karl.kil...@gmail.com

Well these are the validators from omnifaces as per my
previous
recommendation:

- RequiredCheckboxValidator

https://showcase-omnifaces.rhcloud.com/showcase/validators/RequiredCheckboxValidator.xhtml

- validateAll

https://showcase-omnifaces.rhcloud.com/showcase/validators/validateAll.xhtml

- validateAllOrNone

https://showcase-omnifaces.rhcloud.com/showcase/validators/validateAllOrNone.xhtml

Re: DeltaSpike Roadmap

2013-03-25 Thread John D. Ament

+1 Mark

That's what I was thinking of. (jsf runtimes, not component libraries).


On Mon, Mar 25, 2013 at 5:20 PM, Mark Struberg strub...@yahoo.de wrote:

 with JSF-2 this is now almost obsolete, isn't?
 JSF-2 has f:validateBean which works perfectly fine.

 LieGrue,
 strub




 - Original Message -
  From: Thomas Andraschko andraschko.tho...@gmail.com
  To: deltaspike-dev@incubator.apache.org
  Cc:
  Sent: Monday, March 25, 2013 5:31 PM
  Subject: Re: DeltaSpike Roadmap
 
  Are you sure? PrimeFaces does not have one. I only know richfaces'
  graphValidator and it's IMO not that easy and cool as s:validateForm.
 
  2013/3/25 John D. Ament john.d.am...@gmail.com
 
   I believe all of the major JSF component libraries support some type of
   form validation using BV.
 
 
   On Mon, Mar 25, 2013 at 12:19 PM, Thomas Andraschko 
   andraschko.tho...@gmail.com wrote:
 
Any news about s:validateForm?
As i said, it's great feature of seam3 and would perfectly fit DS
  (IMO).
   
I could also add it to DS if no one have enough time... :)
   
2012/12/17 Gerhard Petracek gerhard.petra...@gmail.com
   
 there is a reason why it is just an add-on ;)
 and yes, if you would do it with the jsf2-api, it would be a bit
   easier.
 but you can use this add-on also for jsf 1.x and some users who
  don't
like
 to use seam are happy with it.
 however, i just mentioned it as an example to show that cdi
  isn't
   needed
to
 implement such a functionality.

 regards,
 gerhard



 2012/12/17 Lincoln Baxter, III lincolnbax...@gmail.com

  Also, note that the use-cases for s:validateForm and
  the latter
example
  are different in their usage. IMO, s:validateForm is
  much more
  declarative and simple than the example provided from
  extval.
 
  Just write a validator and attach it like you would normal
  to a
component
  in the view, wherever you want to use it. You can also
  re-use
  form-validators using this method, instead of using some (in
  my
opinion)
  strange view-filtering logic in the FormValidator
  annotation.
 
  s:validateForm is/was one of the most well recieved
  feature of Seam
  Faces, and I think it deserves serious consideration. Can
  you do form
  validation other ways? absolutely, but this way is pretty
  compelling
 based
  on the feedback we got. It also ties in very normally with
  the way in
 which
  JSF handles validation and components, which is not
  something that I
can
  speak about with regard to extval, but I can say that seam
  faces does
 this
  nicely.
 
  ~Lincoln
 
 
  On Mon, Dec 17, 2012 at 4:37 PM, Thomas Andraschko 
  andraschko.tho...@gmail.com wrote:
 
   Please do not mix both :)
   We had the discussion about commons bv constrains.
  s:validateForm
   is
   completely different compared to bv constraints.
   s:validateForm does not fit the project for common bv
  constraints.
  
   2012/12/17 Karl Kildén karl.kil...@gmail.com
  
Looks really nice I understand finally :-)
   
In retrospect I don't know why I didn't
  check the docs myself,
 probably
because I read most of the discussion on the phone
  to begin with.
   
I then agree with the many suggestions regarding
  doing it as a
 parallel
project. Perhaps that module could have a  sub
  module for CDI
   users
  that
included producers and such.
   
Best regards / Karl
   
   
   
   
2012/12/17 Gerhard Petracek
  gerhard.petra...@gmail.com
   
 hi karl,

 it's implemented via a producer - see
  [1].
 but you don't really need cdi for it -
  see e.g. [2].

 regards,
 gerhard

 [1] http://s.apache.org/ury
 [2]


   
  
 

   
 
 
 http://os890.blogspot.co.at/2010/06/multi-field-form-validation-with-jsr.html



 2012/12/17 Thomas Andraschko
  andraschko.tho...@gmail.com

  As far as i understand, validateAll just
  validates all
components
  but
you
  can't use custom logic.
 
  Checkout the seam docu here:
 
 

   
  
 

   
 
 
 http://docs.jboss.org/seam/3/faces/latest/reference/en-US/html/components.html
 
  2012/12/17 Karl Kildén
  karl.kil...@gmail.com
 
   Hrmm still not sure I understand.
  First off didn't Pete
   just
 say
  it
was
   just a JSF-validator? It also
  sounds and reads just like
   validateAll
 from
   omnifaces?
  
   What is lacking that you would like
  to see solved by CDI?
   And
 is
   it a
   natural fit for CDI

Re: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top Level Project

2013-03-25 Thread John D. Ament

Sorry, but -1

In my opinion, there are clearly disconnects between the former CODI team
and the former Seam3 team that are showing to be true blockers to being a
cohesive community.  There has been no real merger of the two communities
to form DeltaSpike.  DeltaSpike has failed to release early and often.

I believe for this podling to graduate, we need to become a single team and
work on becoming that single team.

John


On Mon, Mar 25, 2013 at 5:35 PM, Mark Struberg strub...@yahoo.de wrote:

 Lords and Ladies.

 Please find attached the PROPOSAL for graduating DeltaSpike out of the
 Incubator and establishing it as TLP.

 [+1] yea, all fine and I like it
 [+0] no blocker, but I don't care
 [-1] nah there's a blocker in there. Abort and re-roll because of ${reason}

 The internal VOTE is open for 72h. After that we gonna tally and forward
 the VOTE to the IPMC to VOTE about the recommendation. Once this is done,
 the board might consider our wish in the upcoming board meeting.

 LieGrue,
 strub


 ---

 Proposed Board Resolution Report
 X. Establish the Apache DeltaSpike Project

 WHEREAS, the Board of Directors deems it to be in the best
 interests of the Foundation and consistent with the
 Foundation's purpose to establish a Project Management
 Committee charged with the creation and maintenance of
 open-source software related to creating a set
 of portable CDI (JSR-299) Extensions
 for distribution at no charge to the public.

 NOW, THEREFORE, BE IT RESOLVED, that a Project Management
 Committee (PMC), to be known as the Apache DeltaSpike Project,
 be and hereby is established pursuant to Bylaws of the
 Foundation; and be it further

 RESOLVED, that the Apache DeltaSpike Project be and hereby is
 responsible for the creation and maintenance of open-source
 software related to creating a set of portable CDI Extensions;
 and be it further

 RESOLVED, that the office of Vice President, Apache DeltaSpike be
 and hereby is created, the person holding such office to
 serve at the direction of the Board of Directors as the chair
 of the Apache DeltaSpike Project, and to have primary responsibility
 for management of the projects within the scope of
 responsibility of the Apache DeltaSpike Project; and be it further

 RESOLVED, that the persons listed immediately below be and
 hereby are appointed to serve as the initial members of the
 Apache DeltaSpike Project:

 Gerhard Petracek gpetracek at apache.org
 Mark Struberg struberg at apache.org
 Pete Muir pmuir at redhat.com
 Jason Porter lightguard.jp at gmail.com
 Shane Bryzak sbryzak at gmail.com
 Rudy de Busscher rdebusscher at apache.org
 Christian Kaltepoth christian at kaltepoth.de
 Arne Limburg arne.limburg at openknowledge.de
 Charles Moulliard cmoulliard at gmail.com
 Cody Lerum cody.lerum at gmail.com
 Romain Mannu-Buccau rmannibucau at gmail.com
 Matthew Jason Benson mbenson at apache.org
 Jim Jagielski jim at apache.org
 David Blevins dblevins at apache.org
 Ken Finnigan ken at kenfinnigan.me
 John D. Ament johndament at apache.org

 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Mark Struberg
 be appointed to the office of Vice President, Apache DeltaSpike, to
 serve in accordance with and subject to the direction of the
 Board of Directors and the Bylaws of the Foundation until
 death, resignation, retirement, removal or disqualification,
 or until a successor is appointed; and be it further

 RESOLVED, that the initial Apache DeltaSpike PMC be and hereby is
 tasked with the creation of a set of bylaws intended to
 encourage open development and increased participation in the
 Apache DeltaSpike Project; and be it further

 RESOLVED, that the Apache DeltaSpike Project be and hereby
 is tasked with the migration and rationalization of the Apache
 Incubator DeltaSpike podling; and be it further

 RESOLVED, that all responsibilities pertaining to the Apache
 Incubator DeltaSpike podling encumbered upon the Apache Incubator
 Project are hereafter discharged.



 https://cwiki.apache.org/confluence/display/DeltaSpike/Graduation+Proposal

Re: DISCUSS DeltaSpike-324

2013-03-25 Thread John D. Ament

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 strub...@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 cody.le...@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 nicka...@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
  rmannibu...@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
  lightguard...@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
 rmannibu...@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.petra...@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
  rmannibu...@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
  john.d.am...@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

Re: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top Level Project

2013-03-25 Thread John D. Ament

Mark,

My vote isn't a -1 to DeltaSpike, she's just not ready to blossom yet.
 Maybe another month or two :-)

I will point out an issue which I don't think we've resolved yet per the
documentation on incubator.a.o

http://incubator.apache.org/guides/graduation.html#requirements

- We have not established whether DS is a suitable name; e.g.
https://issues.apache.org/jira/issues/?jql=project%20%3D%20PODLINGNAMESEARCH
has
no entry for DeltaSpike.  Also we have not forwarded the vote thread to
general@i.a.o to let them know we're thinking about it.

However, most of my comments are around this section of graduation:
http://incubator.apache.org/guides/graduation.html#community - I don't
believe we've done this too well.  There are only three developers I see on
the  list that were not on
http://wiki.apache.org/incubator/DeltaSpikeProposal - In fact we now have
16 vs the original 21 proposed (technically does that mean we shrank?)

Three releases is good.  I think I even saw a podling attempt to graduate
that only released their parent POM a couple times :-)

Since this is procedural, I'm assuming we're following majority, per
http://www.apache.org/foundation/voting.html .  I don't believe we need
100% consensus in the matter then, correct?

John


On Mon, Mar 25, 2013 at 5:57 PM, Mark Struberg strub...@yahoo.de wrote:



 Hi John!

 I'm not sure I understand what you mean.

 The DeltaSpike project now runs for 1 year. The list of initial committers
 are all the people who contributed to it in one form or the other. Means
 code drops, documentation, etc. There are exactly 2 people from the CODI
 Team in DeltaSpike. These are Gerhard and me. The rest is from either the
 Seam team or from other teams around the whole CDI area. In my opinion the
 community works together pretty well. Of course, I would be happy if there
 are more commits and contributions from the other folks. There is a pretty
 stable set of 5+ regular committers.


 We also have had 3 releases so far. We just had a bit of a break because I
 was very busy in my dayjob and Gerhard was busy too. And we are short
 before our 4th release. I'd say this is quite ok. (Even if I'd be happier
 if we would improve our release rate).


 LieGrue,
 strub

 
  From: John D. Ament john.d.am...@gmail.com
 To: deltaspike-us...@incubator.apache.org; Mark Struberg 
 strub...@yahoo.de
 Cc: deltaspike deltaspike-dev@incubator.apache.org
 Sent: Monday, March 25, 2013 10:45 PM
 Subject: Re: [VOTE] Recommending DeltaSpike for Graduation to an Apache
 Top Level Project
 
 
 Sorry, but -1
 
 
 In my opinion, there are clearly disconnects between the former CODI team
 and the former Seam3 team that are showing to be true blockers to being a
 cohesive community.  There has been no real merger of the two communities
 to form DeltaSpike.  DeltaSpike has failed to release early and often.
 
 
 I believe for this podling to graduate, we need to become a single team
 and work on becoming that single team.
 
 
 John
 
 
 
 On Mon, Mar 25, 2013 at 5:35 PM, Mark Struberg strub...@yahoo.de wrote:
 
 Lords and Ladies.
 
 Please find attached the PROPOSAL for graduating DeltaSpike out of the
 Incubator and establishing it as TLP.
 
 [+1] yea, all fine and I like it
 [+0] no blocker, but I don't care
 [-1] nah there's a blocker in there. Abort and re-roll because of
 ${reason}
 
 The internal VOTE is open for 72h. After that we gonna tally and forward
 the VOTE to the IPMC to VOTE about the recommendation. Once this is done,
 the board might consider our wish in the upcoming board meeting.
 
 LieGrue,
 strub
 
 
 ---
 
 Proposed Board Resolution Report
 X. Establish the Apache DeltaSpike Project
 
 WHEREAS, the Board of Directors deems it to be in the best
 interests of the Foundation and consistent with the
 Foundation's purpose to establish a Project Management
 Committee charged with the creation and maintenance of
 open-source software related to creating a set
 of portable CDI (JSR-299) Extensions
 for distribution at no charge to the public.
 
 NOW, THEREFORE, BE IT RESOLVED, that a Project Management
 Committee (PMC), to be known as the Apache DeltaSpike Project,
 be and hereby is established pursuant to Bylaws of the
 Foundation; and be it further
 
 RESOLVED, that the Apache DeltaSpike Project be and hereby is
 responsible for the creation and maintenance of open-source
 software related to creating a set of portable CDI Extensions;
 and be it further
 
 RESOLVED, that the office of Vice President, Apache DeltaSpike be
 and hereby is created, the person holding such office to
 serve at the direction of the Board of Directors as the chair
 of the Apache DeltaSpike Project, and to have primary responsibility
 for management of the projects within the scope of
 responsibility of the Apache DeltaSpike Project; and be it further
 
 RESOLVED, that the persons listed immediately below be and
 hereby are appointed to serve as the initial

[jira] [Updated] (DELTASPIKE-278) add 'category' to Message API


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-278:
-

Fix Version/s: (was: 0.4-incubating)
   0.5-incubating

 add 'category' to Message API
 -

 Key: DELTASPIKE-278
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-278
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Core
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.5-incubating


 Sometimes we need different versions of a rendered message. This could be a 
 shortText vs a longText for example. Or in JSF it's the summary vs detail 
 message.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: DISCUSS DeltaSpike-324

2013-03-24 Thread John D. Ament

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
rmannibu...@gmail.comwrote:

 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 gerhard.petra...@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 rmannibu...@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.limb...@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 strub...@yahoo.de:
   
I tend to lean towards +1 simply because EE-7 containers will take
another year (or 2) to become used in projects.

I just think we should first close a few tasks before we open new
  ones.

LieGrue,
strub




- Original Message -
 From: John D. Ament john.d.am...@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
 rmannibu...@gmail.comwrote:

  Hi

  i'm globally -1 for redoing something which will exist somewhere
   else
  (basically if somebody wants JavaEE just let him use JavaEE, CDI
 doesn't
  need the full stack IMO). Was my point for JPA, more again on
 JMS.

  It is great to add feature before the specs not once it is (or
   almost)
  done.

  Maybe i didnt fully get what you want to do so maybe share some
pastebin to
  be sure we speak about the same stuff.

  *Romain Manni-Bucau*
  *Twitter: @rmannibucau https://twitter.com/rmannibucau*
  *Blog: **http://rmannibucau.wordpress.com/*
  http://rmannibucau.wordpress.com/
  *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
  *Github: https://github.com/rmannibucau*



  2013/3/21 John D. Ament john.d.am...@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

Re: DISCUSS DeltaSpike-324

2013-03-24 Thread John D. Ament

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
rmannibu...@gmail.comwrote:

 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.am...@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
  rmannibu...@gmail.comwrote:
 
   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 gerhard.petra...@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 rmannibu...@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.limb...@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 
 strub...@yahoo.de
  :
 
  I tend to lean towards +1 simply because EE-7 containers will
 take
  another year (or 2) to become used in projects.
  
  I just think we should first close a few tasks before we open
 new
ones.
  
  LieGrue,
  strub
  
  
  
  
  - Original Message -
   From: John D. Ament john.d.am...@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

[jira] [Resolved] (DELTASPIKE-326) Introduce isScannable to ConfigSource

2013-03-24 Thread John D. Ament (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-326.
--

Resolution: Fixed

Committed changes.

 Introduce isScannable to ConfigSource
 -

 Key: DELTASPIKE-326
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-326
 Project: DeltaSpike
  Issue Type: Improvement
Reporter: John D. Ament
Assignee: John D. Ament
 Fix For: 0.4-incubating


 Introduce an isScannable method (possibly an interface that ConfigSource will 
 extend) that will represent whether or not this source is scannable.  A 
 scannable source can have all of its properties listed out.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DELTASPIKE-273) Provide a way to obtain all property names or map of properties

2013-03-24 Thread John D. Ament (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13612347#comment-13612347
 ] 

John D. Ament commented on DELTASPIKE-273:
--

Added isScannable.

 Provide a way to obtain all property names or map of properties
 ---

 Key: DELTASPIKE-273
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-273
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Configuration
Reporter: Łukasz Dywicki
Assignee: John D. Ament
 Fix For: 0.4-incubating

 Attachments: DELTASPIKE-273.patch


 ConfigResolver API provides a way to resolve singular property or multivalued 
 property, however there is lack of method which allows to read all properties 
 discovered from all ConfigSources.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DELTASPIKE-273) Provide a way to obtain all property names or map of properties

2013-03-24 Thread John D. Ament (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-273.
--

Resolution: Fixed

 Provide a way to obtain all property names or map of properties
 ---

 Key: DELTASPIKE-273
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-273
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Configuration
Reporter: Łukasz Dywicki
Assignee: John D. Ament
 Fix For: 0.4-incubating

 Attachments: DELTASPIKE-273.patch


 ConfigResolver API provides a way to resolve singular property or multivalued 
 property, however there is lack of method which allows to read all properties 
 discovered from all ConfigSources.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Pending items for release

2013-03-23 Thread John D. Ament

Gerhard,

Do you agree w/ Cody's synopsis?  I think mimic is what you're trying to
describe, but threw me off when you said aligned; I assumed you meant be
dependent on.


On Fri, Mar 22, 2013 at 9:16 AM, Gerhard Petracek 
gerhard.petra...@gmail.com wrote:

 hi john,

 no - we will just create our own interface like ClientWindow and provide a
 default implementation.
 (for jsf 2.2+ we just provide an own module with an adapter which delegates
 to javax.faces.lifecycle.ClientWindow.)

 regards,
 gerhard



 2013/3/22 John D. Ament john.d.am...@gmail.com

  I'm not sure I follow.  We're dependent on JEE7 releases to release DS
 0.4?
  I hope we're not really thinking this...
 
 
  On Thu, Mar 21, 2013 at 9:40 PM, Gerhard Petracek 
  gerhard.petra...@gmail.com wrote:
 
   hi john,
  
   no - it will be a new implementation aligned with the new ClientWindow
  api
   (of jsf 2.2).
   afterwards i finish my tickets (which need it) and then we are ready
 for
  a
   release.
   imo the rest is nice to have for v0.4
  
   regards,
   gerhard
  
  
  
   2013/3/22 John D. Ament john.d.am...@gmail.com
  
Gerhard,
   
But currently it's assigned to Mark. So to outsiders, who maybe
 haven't
been playing close court, someone's already handling it.
   
Since CODI has a Window Scope, I'm assuming that it's simply a port
  from
CODI to DS.
   
John
   
   
On Thu, Mar 21, 2013 at 9:21 PM, Gerhard Petracek 
gerhard.petra...@gmail.com wrote:
   
 hi john,

 [1] is the most blocking one we need for v0.4.

 regards,
 gerhard

 [1] https://issues.apache.org/jira/browse/DELTASPIKE-289



 2013/3/22 John D. Ament john.d.am...@gmail.com

  All,
 
  When I look at open issues for DeltaSpike, all I see is under
 [1] ;
 looking
  at this list it's not clear which are ready to be done or which
  need
more
  info.  In addition when I look at [2] we end up with 50 open
  issues.
 
  V 0.3 was released in August 2012.  I'd like to help get DS to a
  0.4
  release.  So please help clarify what issues are in need of help.
 
  John
 
 
 
  [1]
 
 

   
  
 
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20DELTASPIKE%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20is%20EMPTY%20ORDER%20BY%20priority%20DESC
 
  [2]
 
 

   
  
 
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20DELTASPIKE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

[jira] [Created] (DELTASPIKE-326) Introduce isScannable to ConfigSource

2013-03-23 Thread John D. Ament (JIRA)

John D. Ament created DELTASPIKE-326:


 Summary: Introduce isScannable to ConfigSource
 Key: DELTASPIKE-326
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-326
 Project: DeltaSpike
  Issue Type: Improvement
Reporter: John D. Ament
Assignee: John D. Ament
 Fix For: 0.4-incubating


Introduce an isScannable method (possibly an interface that ConfigSource will 
extend) that will represent whether or not this source is scannable.  A 
scannable source can have all of its properties listed out.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Pending items for release

2013-03-22 Thread John D. Ament

I'm not sure I follow.  We're dependent on JEE7 releases to release DS 0.4?
I hope we're not really thinking this...


On Thu, Mar 21, 2013 at 9:40 PM, Gerhard Petracek 
gerhard.petra...@gmail.com wrote:

 hi john,

 no - it will be a new implementation aligned with the new ClientWindow api
 (of jsf 2.2).
 afterwards i finish my tickets (which need it) and then we are ready for a
 release.
 imo the rest is nice to have for v0.4

 regards,
 gerhard



 2013/3/22 John D. Ament john.d.am...@gmail.com

  Gerhard,
 
  But currently it's assigned to Mark. So to outsiders, who maybe haven't
  been playing close court, someone's already handling it.
 
  Since CODI has a Window Scope, I'm assuming that it's simply a port from
  CODI to DS.
 
  John
 
 
  On Thu, Mar 21, 2013 at 9:21 PM, Gerhard Petracek 
  gerhard.petra...@gmail.com wrote:
 
   hi john,
  
   [1] is the most blocking one we need for v0.4.
  
   regards,
   gerhard
  
   [1] https://issues.apache.org/jira/browse/DELTASPIKE-289
  
  
  
   2013/3/22 John D. Ament john.d.am...@gmail.com
  
All,
   
When I look at open issues for DeltaSpike, all I see is under [1] ;
   looking
at this list it's not clear which are ready to be done or which need
  more
info.  In addition when I look at [2] we end up with 50 open issues.
   
V 0.3 was released in August 2012.  I'd like to help get DS to a 0.4
release.  So please help clarify what issues are in need of help.
   
John
   
   
   
[1]
   
   
  
 
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20DELTASPIKE%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20is%20EMPTY%20ORDER%20BY%20priority%20DESC
   
[2]
   
   
  
 
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20DELTASPIKE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

[jira] [Commented] (DELTASPIKE-273) Provide a way to obtain all property names or map of properties


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13608914#comment-13608914
 ] 

John D. Ament commented on DELTASPIKE-273:
--

I think it's understood that if you have a slow config source pulling all 
properties from everywhere will result in slow resolution.  Doesn't meant this 
is a bad feature, just means you have to be responsible.

 Provide a way to obtain all property names or map of properties
 ---

 Key: DELTASPIKE-273
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-273
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Configuration
Reporter: Łukasz Dywicki
Assignee: John D. Ament
 Fix For: 0.4-incubating

 Attachments: DELTASPIKE-273.patch


 ConfigResolver API provides a way to resolve singular property or multivalued 
 property, however there is lack of method which allows to read all properties 
 discovered from all ConfigSources.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

DELTASPIKE-273

2013-03-21 Thread John D. Ament

All,

I'd like to open the floor to anyone else who may have some questions or
concerns about doing DS-273.  Personally its something I need in a project
I'm working on, seeing the bug open made it a good idea for me.

As Gerhard mentions, if you have a slow source it will be slow to respond
for resolution, but I think that's an understood limitation.  I would guess
that the typical usecase here is to be able to display a list of all system
configuration options from a single screen in an app, but only a hunch.

John

DISCUSS DeltaSpike-324

2013-03-21 Thread John D. Ament

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

[jira] [Assigned] (DELTASPIKE-324) Backport JMS2 Like functionality to DeltaSpike


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reassigned DELTASPIKE-324:


Assignee: John D. Ament

 Backport JMS2 Like functionality to DeltaSpike
 --

 Key: DELTASPIKE-324
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-324
 Project: DeltaSpike
  Issue Type: Improvement
Reporter: John D. Ament
Assignee: John D. Ament

 In JMS 2, a few new CDI compatible components were introduced.  They include:
 JMSContext - a CDI capable version of the JMS Session  Connection objects 
 that provides access to more lower level components.
 JMSProducer - A CDI capable version of MessageProducer that uses builder 
 pattern to create new Message objects.
 JMSConsumer - A CDI capable version of MessageConsumer that can retrieve 
 messages in a more type safe fashion.
 Introducing these features would be the first step in adopting a JMS module 
 in DeltaSpike.
 Javadocs can be found here:
 http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/index.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: DISCUSS DeltaSpike-324

2013-03-21 Thread John D. Ament

On Thu, Mar 21, 2013 at 5:34 PM, Mark Struberg strub...@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 john.d.am...@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
  rmannibu...@gmail.comwrote:
 
   Hi
 
   i'm globally -1 for redoing something which will exist somewhere else
   (basically if somebody wants JavaEE just let him use JavaEE, CDI
  doesn't
   need the full stack IMO). Was my point for JPA, more again on JMS.
 
   It is great to add feature before the specs not once it is (or almost)
   done.
 
   Maybe i didnt fully get what you want to do so maybe share some
 pastebin to
   be sure we speak about the same stuff.
 
   *Romain Manni-Bucau*
   *Twitter: @rmannibucau https://twitter.com/rmannibucau*
   *Blog: **http://rmannibucau.wordpress.com/*
   http://rmannibucau.wordpress.com/
   *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
   *Github: https://github.com/rmannibucau*
 
 
 
   2013/3/21 John D. Ament john.d.am...@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

2013-03-21 Thread John D. Ament

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.limb...@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 strub...@yahoo.de:

 I tend to lean towards +1 simply because EE-7 containers will take
 another year (or 2) to become used in projects.
 
 I just think we should first close a few tasks before we open new ones.
 
 LieGrue,
 strub
 
 
 
 
 - Original Message -
  From: John D. Ament john.d.am...@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
  rmannibu...@gmail.comwrote:
 
   Hi
 
   i'm globally -1 for redoing something which will exist somewhere else
   (basically if somebody wants JavaEE just let him use JavaEE, CDI
  doesn't
   need the full stack IMO). Was my point for JPA, more again on JMS.
 
   It is great to add feature before the specs not once it is (or almost)
   done.
 
   Maybe i didnt fully get what you want to do so maybe share some
 pastebin to
   be sure we speak about the same stuff.
 
   *Romain Manni-Bucau*
   *Twitter: @rmannibucau https://twitter.com/rmannibucau*
   *Blog: **http://rmannibucau.wordpress.com/*
   http://rmannibucau.wordpress.com/
   *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
   *Github: https://github.com/rmannibucau*
 
 
 
   2013/3/21 John D. Ament john.d.am...@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

[jira] [Commented] (DELTASPIKE-273) Provide a way to obtain all property names or map of properties


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609648#comment-13609648
 ] 

John D. Ament commented on DELTASPIKE-273:
--

I think perhaps we should discuss on the dev list so that JIRA doesn't become a 
mail archive (which is then archived by our dev mailing list..)

http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/DELTASPIKE-273-td4654621.html

 Provide a way to obtain all property names or map of properties
 ---

 Key: DELTASPIKE-273
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-273
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Configuration
Reporter: Łukasz Dywicki
Assignee: John D. Ament
 Fix For: 0.4-incubating

 Attachments: DELTASPIKE-273.patch


 ConfigResolver API provides a way to resolve singular property or multivalued 
 property, however there is lack of method which allows to read all properties 
 discovered from all ConfigSources.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Pending items for release

2013-03-21 Thread John D. Ament

All,

When I look at open issues for DeltaSpike, all I see is under [1] ; looking
at this list it's not clear which are ready to be done or which need more
info.  In addition when I look at [2] we end up with 50 open issues.

V 0.3 was released in August 2012.  I'd like to help get DS to a 0.4
release.  So please help clarify what issues are in need of help.

John



[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20DELTASPIKE%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20is%20EMPTY%20ORDER%20BY%20priority%20DESC

[2]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20DELTASPIKE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

[jira] [Comment Edited] (DELTASPIKE-273) Provide a way to obtain all property names or map of properties

[
https://issues.apache.org/jira/browse/DELTASPIKE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609760#comment-13609760
]

John D. Ament edited comment on DELTASPIKE-273 at 3/22/13 1:07 AM:
---

There are lots of cases where a framework will allow a developer to do
something bad. We can do our best to greatly discourage them for doing
something wrong, but ultimately the framework is going to choose what to do.
The app developer can then go back and point out the issue to the framework
when it occurs.

Perhaps if there is major concern (so far I only see a +1, a +1 from community
and a -0.5) in which case we can add a boolean isScannable that indicates
whether this config source should be scanned for lists of properties/property
values.

was (Author: johndament):
There are lots of cases where a framework will allow a developer to do
something bad. We can do our best to greatly discourage them for doing
something wrong, but ultimately

Provide a way to obtain all property names or map of properties
---

Key: DELTASPIKE-273
URL: https://issues.apache.org/jira/browse/DELTASPIKE-273
Project: DeltaSpike
Issue Type: Improvement
Components: Configuration
Reporter: Łukasz Dywicki
Assignee: John D. Ament
Fix For: 0.4-incubating

Attachments: DELTASPIKE-273.patch

ConfigResolver API provides a way to resolve singular property or multivalued
property, however there is lack of method which allows to read all properties
discovered from all ConfigSources.

Re: Pending items for release

2013-03-21 Thread John D. Ament

Gerhard,

But currently it's assigned to Mark. So to outsiders, who maybe haven't
been playing close court, someone's already handling it.

Since CODI has a Window Scope, I'm assuming that it's simply a port from
CODI to DS.

John


On Thu, Mar 21, 2013 at 9:21 PM, Gerhard Petracek 
gerhard.petra...@gmail.com wrote:

 hi john,

 [1] is the most blocking one we need for v0.4.

 regards,
 gerhard

 [1] https://issues.apache.org/jira/browse/DELTASPIKE-289



 2013/3/22 John D. Ament john.d.am...@gmail.com

  All,
 
  When I look at open issues for DeltaSpike, all I see is under [1] ;
 looking
  at this list it's not clear which are ready to be done or which need more
  info.  In addition when I look at [2] we end up with 50 open issues.
 
  V 0.3 was released in August 2012.  I'd like to help get DS to a 0.4
  release.  So please help clarify what issues are in need of help.
 
  John
 
 
 
  [1]
 
 
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20DELTASPIKE%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20is%20EMPTY%20ORDER%20BY%20priority%20DESC
 
  [2]
 
 
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20DELTASPIKE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

[jira] [Updated] (DELTASPIKE-273) Provide a way to obtain all property names or map of properties


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-273:
-

Assignee: John D. Ament

 Provide a way to obtain all property names or map of properties
 ---

 Key: DELTASPIKE-273
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-273
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Configuration
Reporter: Łukasz Dywicki
Assignee: John D. Ament
 Attachments: DELTASPIKE-273.patch


 ConfigResolver API provides a way to resolve singular property or multivalued 
 property, however there is lack of method which allows to read all properties 
 discovered from all ConfigSources.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: cdi-query, no news?

2013-03-20 Thread John D. Ament

 such
   extensibility +
no scopes for queries?
   
*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/14 Gerhard Petracek gerhard.petra...@gmail.com
   
 hi romain,

 no - it's more about the style we introduced e.g. for
  type-safe
   messages.

 regards,
 gerhard


 2013/3/14 Romain Manni-Bucau rmannibu...@gmail.com

  @Gerhard: hope you don't think of @RepoBinding at
  all...would
be
  too
much
  IMO. Would be great to support aliases/stereotype maybe
 but
   not
 the
 default
 
  Wdyt?
  Le 14 mars 2013 00:11, Gerhard Petracek 
   gerhard.petra...@gmail.com
a
  écrit :
 
   hi thomas,
  
   imo it should follow the basic style/s we have in other
   parts
   already
 (if
   possible).
  
   i guess the simple implementations in the test-module
 are
   too
   simple
to
  see
   the real benefit.
   - it would be nice if you add some drafts to a
 sub-page
  of
 [1].
   (the usage you would prefer and not as it is right
 now.)
  
   regards,
   gerhard
  
   [1]
  https://cwiki.apache.org/confluence/display/DeltaSpike/Drafts
  
  
  
   2013/3/13 Romain Manni-Bucau rmannibu...@gmail.com
  
i'd put it in to start since that's useful for JPA
 but
  it
   shouldn't
 use
   it
at all
   
a question (for next iteration if that's ok for
   everybody)
is
should
   repos
handle transaction or at least define it.
   
*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/13 John D. Ament john.d.am...@gmail.com
   
 Does this have any direct/indirect dependencies on
  JPA
  module?
 Should
this
 maybe become a part of the JPA module?


 On Wed, Mar 13, 2013 at 7:23 AM, Thomas Hug
 thomas@ctp-consulting.comwrote:

  Ok, I guess it's going to be Repository :)
 Updated
   the
   proposal
   branch
 and
  also moved things into a data package/module.
 
  Some remarks for the parts below:
 
  1) EntityManagerRepository wasn't present in the
   Solder
   implementation
-
  there it was possible to simply implement/extend
   EntityManager.
 The
 problem
  with the invocation handler is that it's not
  possible
to
restrict
  the
 bean
  type and exclude EntityManager (or I missed it).
 Otherwise
   I'd
  rather
get
  rid of this interface.
 
  2) WithEntityManager is definitely discussable.
 Not
   the
  full
  solution
and
  not consistent. Could be solved with e.g. putting
  qualifiers
on a
method
  returning an EntityManager (less intuitive) or
something
  like
the
  InvocationHandlerBinding.
 
  3) AbstractEntityRepository is just a convenience
   class
 for
  providing
  concrete query implementations.
 
  On Tue, Mar 12, 2013 at 9:40 PM, Gerhard
 Petracek 
  gerhard.petra...@gmail.com wrote:
 
   hi,
  
   currently we don't have one jira ticket per
 part/feature.
   that's what we used to have for everything we
imported.
  
   the first parts to discuss are imo
   EntityManagerDao,
WithEntityManager
  and
   AbstractEntityDao.
  
   regards,
   gerhard
  
  
  
   2013/3/12 Arne Limburg 
arne.limb...@openknowledge.de
  
+1 for repository, from me too
   
Gesendet mit meinem HTC

Re: Problems using Deltaspike JMX-Extensions together with JRebel

2013-03-20 Thread John D. Ament

But as a quick fix, he can also just set that property to true, right?
 Doesn't need a new build to do that.


On Wed, Mar 20, 2013 at 2:24 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 Hi,

 thanks for the report,

 it should be fixed on trunk with
 https://issues.apache.org/jira/browse/DELTASPIKE-323


 2013/3/20, Jörg Bauer joerg.ba...@nfon.net:
 
  Hey,
 
  i have problems using the JMX-extensions together with JRebel.
 
  The weld-plugin from jrebel tries to reregister the managed bean if i
 change
  a class that refers to the managed bean.
 
  Possible solutions:
  1. Always try to unregister bean before you do a new registration inside
 the
  MBeanServer
  2. Catch the exception (not sure what is going to happen with this bean,
  Still connected to the application ???)
 
  I also got this exception during he development of the managed bean
 without
  using JRebel. Every time i got an exception inside my managed operation i
  had to restart the complete application server (Glassfish).
 
  It would improve the usability of this great extension...
 
 
  INFO: [2013-03-20 17:31:47] JRebel: Reloading class
  'net.nfon.portal.vm.portal_user.UserDetailViewModel'.
  INFO: [2013-03-20 17:31:47] JRebel: Class
  'net.nfon.portal.vm.portal_user.UserDetailViewModel' has a new non-static
  field 'company', it will be null on existing instances
  INFO: [2013-03-20 17:31:47] JRebel: Class
  'net.nfon.portal.vm.portal_user.UserDetailViewModel' has a new non-static
  field 'userClassName', it will be null on existing instances
  INFO: [2013-03-20 17:31:47] JRebel: Reloading class
  'net.nfon.portal.vm.portal_user.UserDetailViewModel$1'.
  INFO: [2013-03-20 17:31:49] JRebel-Weld: Reconfiguring bean with name
 'null'
  [class net.nfon.portal.vm.portal_user.UserDetailViewModel]
  INFO: [2013-03-20 17:31:50] JRebel: An error occured in a JRebel plugin
  while handling a class reload event:
  SEVERE: org.jboss.weld.exceptions.DefinitionException: Exception List
 with 1
  exceptions:
  Exception 0 :
  javax.enterprise.event.ObserverException
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
  Method)
  at
 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
  at
 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  at
 java.lang.reflect.Constructor.newInstance(Constructor.java:525)
  at java.lang.Class.newInstance0(Class.java:374)
  at java.lang.Class.newInstance(Class.java:327)
  at
 
 org.jboss.weld.util.reflection.SecureReflections$16.work(SecureReflections.java:344)
  at
 
 org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
  at
 
 org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInstantiation(SecureReflectionAccess.java:173)
  at
 
 org.jboss.weld.util.reflection.SecureReflections.newInstance(SecureReflections.java:341)
  at
  org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:33)
  at
  org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:73)
  at
 
 org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:162)
  at
 
 org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:245)
  at
 
 org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:233)
  at
 
 org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:213)
  at
 
 org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:590)
  at
 
 org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:580)
  at
 
 org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:60)
  at
 
 org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:38)
  at
 
 org.jboss.weld.bootstrap.events.ProcessSessionBeanImpl.fire(ProcessSessionBeanImpl.java:35)
  at
 
 org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:126)
  at
 
 org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:217)
  at
 
 org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:358)
  at
  org.jboss.weld.bootstrap.WeldBootstrap.jrRescan(WeldBootstrap.java)
  at
 
 org.zeroturnaround.jrebel.weld.WeldReloader.reloadBeanDefinitionsInternal(WeldReloader.java:320)
  at
 
 org.zeroturnaround.jrebel.weld.WeldReloader.reloadBeanDefinitions(WeldReloader.java:302)
  at
 
 org.zeroturnaround.jrebel.weld.WeldReloader.onClassEvent(WeldReloader.java:159)
  at com.zeroturnaround.javarebel.SDKReloaderImpl.b(JRebel:136)
  at
 
 com.zeroturnaround.javarebel.SDKReloaderImpl.firePendingReloadListeners(JRebel:73)
  at

[jira] [Commented] (DELTASPIKE-273) Provide a way to obtain all property names or map of properties


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13608524#comment-13608524
 ] 

John D. Ament commented on DELTASPIKE-273:
--

Thanks! Merged in your changes.

 Provide a way to obtain all property names or map of properties
 ---

 Key: DELTASPIKE-273
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-273
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Configuration
Reporter: Łukasz Dywicki
Assignee: John D. Ament
 Attachments: DELTASPIKE-273.patch


 ConfigResolver API provides a way to resolve singular property or multivalued 
 property, however there is lack of method which allows to read all properties 
 discovered from all ConfigSources.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DELTASPIKE-273) Provide a way to obtain all property names or map of properties


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-273:
-

Fix Version/s: 0.4-incubating

 Provide a way to obtain all property names or map of properties
 ---

 Key: DELTASPIKE-273
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-273
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Configuration
Reporter: Łukasz Dywicki
Assignee: John D. Ament
 Fix For: 0.4-incubating

 Attachments: DELTASPIKE-273.patch


 ConfigResolver API provides a way to resolve singular property or multivalued 
 property, however there is lack of method which allows to read all properties 
 discovered from all ConfigSources.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DELTASPIKE-273) Provide a way to obtain all property names or map of properties


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-273.
--

Resolution: Fixed

Tested locally, seems ok.  No regression breaks.  Pushed.

 Provide a way to obtain all property names or map of properties
 ---

 Key: DELTASPIKE-273
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-273
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Configuration
Reporter: Łukasz Dywicki
Assignee: John D. Ament
 Fix For: 0.4-incubating

 Attachments: DELTASPIKE-273.patch


 ConfigResolver API provides a way to resolve singular property or multivalued 
 property, however there is lack of method which allows to read all properties 
 discovered from all ConfigSources.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DELTASPIKE-321) DefaultMessage.argument(Serializable...) should guard against empty arrays

2013-03-19 Thread John D. Ament (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606300#comment-13606300
 ] 

John D. Ament commented on DELTASPIKE-321:
--

Added two new methods to help support this use case.  I think your description 
and title differ in meaning a bit, but now there's an argumentArray method that 
you can pass your vararg'd reference to apply properly.

 DefaultMessage.argument(Serializable...) should guard against empty arrays
 --

 Key: DELTASPIKE-321
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-321
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Reporter: Nicklas Karlsson
Assignee: John D. Ament
 Fix For: 0.4-incubating


 If you have a method with ... parameters, it will be interpreted as an array. 
 If it is passed along to DefaultMessage.argument the object array is 
 interpreted as an object and added as such. Now that I mention it, wouldn't 
 the flow be the same even if the array came populated with data?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DELTASPIKE-321) DefaultMessage.argument(Serializable...) should guard against empty arrays

2013-03-19 Thread John D. Ament (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-321.
--

Resolution: Fixed

 DefaultMessage.argument(Serializable...) should guard against empty arrays
 --

 Key: DELTASPIKE-321
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-321
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Reporter: Nicklas Karlsson
Assignee: John D. Ament
 Fix For: 0.4-incubating


 If you have a method with ... parameters, it will be interpreted as an array. 
 If it is passed along to DefaultMessage.argument the object array is 
 interpreted as an object and added as such. Now that I mention it, wouldn't 
 the flow be the same even if the array came populated with data?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DELTASPIKE-321) DefaultMessage.argument(Serializable...) should guard against empty arrays


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-321:
-

Assignee: John D. Ament  (was: Mark Struberg)

 DefaultMessage.argument(Serializable...) should guard against empty arrays
 --

 Key: DELTASPIKE-321
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-321
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Affects Versions: 0.4-incubating
Reporter: Nicklas Karlsson
Assignee: John D. Ament

 If you have a method with ... parameters, it will be interpreted as an array. 
 If it is passed along to DefaultMessage.argument the object array is 
 interpreted as an object and added as such. Now that I mention it, wouldn't 
 the flow be the same even if the array came populated with data?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DELTASPIKE-321) DefaultMessage.argument(Serializable...) should guard against empty arrays


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605165#comment-13605165
 ] 

John D. Ament commented on DELTASPIKE-321:
--

Added a test, to reproduce the NPE

java.lang.NullPointerException
at java.util.Collections.addAll(Collections.java:3844)
at 
org.apache.deltaspike.core.impl.message.DefaultMessage.argument(DefaultMessage.java:65)

Commiting a Null check.

 DefaultMessage.argument(Serializable...) should guard against empty arrays
 --

 Key: DELTASPIKE-321
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-321
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Affects Versions: 0.4-incubating
Reporter: Nicklas Karlsson
Assignee: John D. Ament

 If you have a method with ... parameters, it will be interpreted as an array. 
 If it is passed along to DefaultMessage.argument the object array is 
 interpreted as an object and added as such. Now that I mention it, wouldn't 
 the flow be the same even if the array came populated with data?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DELTASPIKE-321) DefaultMessage.argument(Serializable...) should guard against empty arrays


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-321.
--

Resolution: Fixed

Fixed and validated (finally checked in too!)

 DefaultMessage.argument(Serializable...) should guard against empty arrays
 --

 Key: DELTASPIKE-321
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-321
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Reporter: Nicklas Karlsson
Assignee: John D. Ament
 Fix For: 0.4-incubating


 If you have a method with ... parameters, it will be interpreted as an array. 
 If it is passed along to DefaultMessage.argument the object array is 
 interpreted as an object and added as such. Now that I mention it, wouldn't 
 the flow be the same even if the array came populated with data?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DELTASPIKE-321) DefaultMessage.argument(Serializable...) should guard against empty arrays


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605548#comment-13605548
 ] 

John D. Ament commented on DELTASPIKE-321:
--

I'll check it again this evening.

 DefaultMessage.argument(Serializable...) should guard against empty arrays
 --

 Key: DELTASPIKE-321
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-321
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Reporter: Nicklas Karlsson
Assignee: John D. Ament
 Fix For: 0.4-incubating


 If you have a method with ... parameters, it will be interpreted as an array. 
 If it is passed along to DefaultMessage.argument the object array is 
 interpreted as an object and added as such. Now that I mention it, wouldn't 
 the flow be the same even if the array came populated with data?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DELTASPIKE-321) DefaultMessage.argument(Serializable...) should guard against empty arrays


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605573#comment-13605573
 ] 

John D. Ament commented on DELTASPIKE-321:
--

I believe this is a limitation of the syntax.  It's implicitly converted to an 
Object[] on the receiving method, so it goes in as a single argument.

I can add something to check to see if an argument is an array.

 DefaultMessage.argument(Serializable...) should guard against empty arrays
 --

 Key: DELTASPIKE-321
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-321
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Reporter: Nicklas Karlsson
Assignee: John D. Ament
 Fix For: 0.4-incubating


 If you have a method with ... parameters, it will be interpreted as an array. 
 If it is passed along to DefaultMessage.argument the object array is 
 interpreted as an object and added as such. Now that I mention it, wouldn't 
 the flow be the same even if the array came populated with data?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DELTASPIKE-321) DefaultMessage.argument(Serializable...) should guard against empty arrays


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605899#comment-13605899
 ] 

John D. Ament commented on DELTASPIKE-321:
--

What you're looking for isn't feasible.  When you pass varargs into a method it 
gets erased into an array.

This type of declaration is not valid: String... c = {a,b,c}, varargs 
only can go into method arguments.



 DefaultMessage.argument(Serializable...) should guard against empty arrays
 --

 Key: DELTASPIKE-321
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-321
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Reporter: Nicklas Karlsson
Assignee: John D. Ament
 Fix For: 0.4-incubating


 If you have a method with ... parameters, it will be interpreted as an array. 
 If it is passed along to DefaultMessage.argument the object array is 
 interpreted as an object and added as such. Now that I mention it, wouldn't 
 the flow be the same even if the array came populated with data?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DELTASPIKE-321) DefaultMessage.argument(Serializable...) should guard against empty arrays


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605903#comment-13605903
 ] 

John D. Ament commented on DELTASPIKE-321:
--

Also, cannot check to see if the elements are an array.  Cannot do T[] since 
there is no type yet.  Cannot check for every T for all possible types, just 
not feasible.  This also happens when you use String.format.

 DefaultMessage.argument(Serializable...) should guard against empty arrays
 --

 Key: DELTASPIKE-321
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-321
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Reporter: Nicklas Karlsson
Assignee: John D. Ament
 Fix For: 0.4-incubating


 If you have a method with ... parameters, it will be interpreted as an array. 
 If it is passed along to DefaultMessage.argument the object array is 
 interpreted as an object and added as such. Now that I mention it, wouldn't 
 the flow be the same even if the array came populated with data?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: DELTASPIKE-321

2013-03-18 Thread John D. Ament

Oops..

Looks like there's only one implementation of message.


On Mon, Mar 18, 2013 at 9:57 PM, John D. Ament john.d.am...@gmail.comwrote:

 All,

 Based on the above mentioned issue, I'd like to add the following two
 methods to the Message interface:

 public Message argument(Serializable[] arguments)

 public Message argument(CollectionSerializable arguments)

 This appears to be the standard way of handling this type of issue.  I'm
 just not sure of all the impact to doing this.  If I make this change, is
 anyone concerned that I touch their module to add these two methods?

 John

[jira] [Updated] (DELTASPIKE-319) JPA module fails to start transaction if a qualifier is not used under certain conditions

2013-03-12 Thread John D. Ament (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-319:
-

Fix Version/s: (was: 0.3-incubating)
   0.4-incubating
 Assignee: John D. Ament

I can take a look.  I think we should fail the deployment in this case, since 
most EM operations need an active transaction.

 JPA module fails to start transaction if a qualifier is not used under 
 certain conditions
 -

 Key: DELTASPIKE-319
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-319
 Project: DeltaSpike
  Issue Type: Bug
  Components: JPA-Module
Affects Versions: 0.3-incubating
Reporter: Gabriel Sosa
Assignee: John D. Ament
 Fix For: 0.4-incubating


 I stumbled upon this by coincidence and it gave me major headaches as it was 
 a bit hard to realize why and where it happened.
 I started using Picketlink 3.0.0.alpha1 and it provides an IdentityManager 
 that handles precisely that. Now the problem is that after looking at 
 Deltaspike's source code for a while, it does the following:
 On a method annotated with @Transactional:
 @Transactional
 public void myTransactionalMethod() {
 identityManager.createUser(foo);
 }
 As far as I understand, the module needs to know which EntityManager should 
 execute within a transaction, so basically it first scans the annotation 
 (@Transactional) looking for qualifiers, if it finds a qualifier, it performs 
 some checks then starts a transaction. If the annotation does not have a 
 qualifier, then it takes the class that has the @Transactional method, and 
 starts scanning its fields to find the EntityManager used and get its 
 qualifier, if it finds an EntityManager it will take its qualifier. This is 
 expected behaviour but the problem arises when the class calling the 
 transactional method does not have an EntityManager because it doesn't need 
 one. 
 Say in this scenario:
 Public class IdentityManager {
protected EntityManager doBlackMagicToGetAnEntityManager() {
//find an entitymanager.
}
public void createUser(String username) {
doBlackMagicToGetAnEntityManager().persist(new User(username));
}
 }
 @Named
 @RequestScoped
 public class VictimBean {
  @Inject
  IdentityManager identityManager;
  protected String name;
  @Transactional
  public void doCreate() {
 identityManager.createUser(this.name);
  }
 }
 Deltaspike will look for a qualifier, won't find it in Transactional. 
 Therefore, it will scan VictimBean looking for a qualifier for an 
 EntityManager, it won't find one, it won't open a transaction, the 
 application throws an exception because createUser(..) modifies the database 
 and is required to be executed within a transaction.
 Is this behavior expected? Because it is very unpredictable. I didn't really 
 see it coming.
 PicketLink requires me to use a @PicketLink qualifier in a field producer so 
 it can get an entity manager but I have this in my Resources bean, which 
 doesn't directly participate in that code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (DELTASPIKE-319) JPA module fails to start transaction if a qualifier is not used under certain conditions

2013-03-12 Thread John D. Ament (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reopened DELTASPIKE-319:
--


 JPA module fails to start transaction if a qualifier is not used under 
 certain conditions
 -

 Key: DELTASPIKE-319
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-319
 Project: DeltaSpike
  Issue Type: Bug
  Components: JPA-Module
Affects Versions: 0.3-incubating
Reporter: Gabriel Sosa
Assignee: John D. Ament
 Fix For: 0.4-incubating


 I stumbled upon this by coincidence and it gave me major headaches as it was 
 a bit hard to realize why and where it happened.
 I started using Picketlink 3.0.0.alpha1 and it provides an IdentityManager 
 that handles precisely that. Now the problem is that after looking at 
 Deltaspike's source code for a while, it does the following:
 On a method annotated with @Transactional:
 @Transactional
 public void myTransactionalMethod() {
 identityManager.createUser(foo);
 }
 As far as I understand, the module needs to know which EntityManager should 
 execute within a transaction, so basically it first scans the annotation 
 (@Transactional) looking for qualifiers, if it finds a qualifier, it performs 
 some checks then starts a transaction. If the annotation does not have a 
 qualifier, then it takes the class that has the @Transactional method, and 
 starts scanning its fields to find the EntityManager used and get its 
 qualifier, if it finds an EntityManager it will take its qualifier. This is 
 expected behaviour but the problem arises when the class calling the 
 transactional method does not have an EntityManager because it doesn't need 
 one. 
 Say in this scenario:
 Public class IdentityManager {
protected EntityManager doBlackMagicToGetAnEntityManager() {
//find an entitymanager.
}
public void createUser(String username) {
doBlackMagicToGetAnEntityManager().persist(new User(username));
}
 }
 @Named
 @RequestScoped
 public class VictimBean {
  @Inject
  IdentityManager identityManager;
  protected String name;
  @Transactional
  public void doCreate() {
 identityManager.createUser(this.name);
  }
 }
 Deltaspike will look for a qualifier, won't find it in Transactional. 
 Therefore, it will scan VictimBean looking for a qualifier for an 
 EntityManager, it won't find one, it won't open a transaction, the 
 application throws an exception because createUser(..) modifies the database 
 and is required to be executed within a transaction.
 Is this behavior expected? Because it is very unpredictable. I didn't really 
 see it coming.
 PicketLink requires me to use a @PicketLink qualifier in a field producer so 
 it can get an entity manager but I have this in my Resources bean, which 
 doesn't directly participate in that code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DELTASPIKE-319) Fail deployment of app with JPA module when EM not found in same class.

2013-03-12 Thread John D. Ament (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-319:
-

Summary: Fail deployment of app with JPA module when EM not found in same 
class.  (was: JPA module fails to start transaction if a qualifier is not used 
under certain conditions)

 Fail deployment of app with JPA module when EM not found in same class.
 ---

 Key: DELTASPIKE-319
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-319
 Project: DeltaSpike
  Issue Type: Bug
  Components: JPA-Module
Affects Versions: 0.3-incubating
Reporter: Gabriel Sosa
Assignee: John D. Ament
 Fix For: 0.4-incubating


 I stumbled upon this by coincidence and it gave me major headaches as it was 
 a bit hard to realize why and where it happened.
 I started using Picketlink 3.0.0.alpha1 and it provides an IdentityManager 
 that handles precisely that. Now the problem is that after looking at 
 Deltaspike's source code for a while, it does the following:
 On a method annotated with @Transactional:
 @Transactional
 public void myTransactionalMethod() {
 identityManager.createUser(foo);
 }
 As far as I understand, the module needs to know which EntityManager should 
 execute within a transaction, so basically it first scans the annotation 
 (@Transactional) looking for qualifiers, if it finds a qualifier, it performs 
 some checks then starts a transaction. If the annotation does not have a 
 qualifier, then it takes the class that has the @Transactional method, and 
 starts scanning its fields to find the EntityManager used and get its 
 qualifier, if it finds an EntityManager it will take its qualifier. This is 
 expected behaviour but the problem arises when the class calling the 
 transactional method does not have an EntityManager because it doesn't need 
 one. 
 Say in this scenario:
 Public class IdentityManager {
protected EntityManager doBlackMagicToGetAnEntityManager() {
//find an entitymanager.
}
public void createUser(String username) {
doBlackMagicToGetAnEntityManager().persist(new User(username));
}
 }
 @Named
 @RequestScoped
 public class VictimBean {
  @Inject
  IdentityManager identityManager;
  protected String name;
  @Transactional
  public void doCreate() {
 identityManager.createUser(this.name);
  }
 }
 Deltaspike will look for a qualifier, won't find it in Transactional. 
 Therefore, it will scan VictimBean looking for a qualifier for an 
 EntityManager, it won't find one, it won't open a transaction, the 
 application throws an exception because createUser(..) modifies the database 
 and is required to be executed within a transaction.
 Is this behavior expected? Because it is very unpredictable. I didn't really 
 see it coming.
 PicketLink requires me to use a @PicketLink qualifier in a field producer so 
 it can get an entity manager but I have this in my Resources bean, which 
 doesn't directly participate in that code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DELTASPIKE-295) JsfMessageProducer createJsfMessage return type should be parametrized


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13597047#comment-13597047
 ] 

John D. Ament commented on DELTASPIKE-295:
--

Mark, are you working this?  Otherwise I can commit the fix.

 JsfMessageProducer createJsfMessage return type should be parametrized
 --

 Key: DELTASPIKE-295
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-295
 Project: DeltaSpike
  Issue Type: Bug
  Components: JSF-Module
Affects Versions: 0.4-incubating
 Environment: Current 0.4-incubating snapshot, Weld 2.0.0.Beta1
Reporter: Marek Schmidt
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 The 
 {code}
 public JsfMessage createJsfMessage(InjectionPoint injectionPoint)
 {code}
 should probably be
 {code}
 public T JsfMessageT createJsfMessage(InjectionPoint injectionPoint)
 {code}
 instead.
 The problem manifests itself in Weld 2.0.0.Beta1:
 {noformat}
 Tests in error: 
   org.apache.deltaspike.test.jsf.impl.message.JsfMessageTest: Could not 
 deploy to container: {JBAS014671: Failed services = 
 {jboss.deployment.unit.\jsfMessageTest.war\.WeldService = 
 org.jboss.msc.service.StartException in service 
 jboss.deployment.unit.\jsfMessageTest.war\.WeldService: 
 org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied 
 dependencies for type [JsfMessageUserMessage] with qualifiers [@Default] at 
 injection point [[BackedAnnotatedField] @Inject private 
 org.apache.deltaspike.test.jsf.impl.message.beans.JsfMessageBackingBean.msg]}}
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (DELTASPIKE-295) JsfMessageProducer createJsfMessage return type should be parametrized


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reassigned DELTASPIKE-295:


Assignee: John D. Ament  (was: Mark Struberg)

 JsfMessageProducer createJsfMessage return type should be parametrized
 --

 Key: DELTASPIKE-295
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-295
 Project: DeltaSpike
  Issue Type: Bug
  Components: JSF-Module
Affects Versions: 0.4-incubating
 Environment: Current 0.4-incubating snapshot, Weld 2.0.0.Beta1
Reporter: Marek Schmidt
Assignee: John D. Ament
 Fix For: 0.4-incubating


 The 
 {code}
 public JsfMessage createJsfMessage(InjectionPoint injectionPoint)
 {code}
 should probably be
 {code}
 public T JsfMessageT createJsfMessage(InjectionPoint injectionPoint)
 {code}
 instead.
 The problem manifests itself in Weld 2.0.0.Beta1:
 {noformat}
 Tests in error: 
   org.apache.deltaspike.test.jsf.impl.message.JsfMessageTest: Could not 
 deploy to container: {JBAS014671: Failed services = 
 {jboss.deployment.unit.\jsfMessageTest.war\.WeldService = 
 org.jboss.msc.service.StartException in service 
 jboss.deployment.unit.\jsfMessageTest.war\.WeldService: 
 org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied 
 dependencies for type [JsfMessageUserMessage] with qualifiers [@Default] at 
 injection point [[BackedAnnotatedField] @Inject private 
 org.apache.deltaspike.test.jsf.impl.message.beans.JsfMessageBackingBean.msg]}}
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DELTASPIKE-295) JsfMessageProducer createJsfMessage return type should be parametrized


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13597073#comment-13597073
 ] 

John D. Ament commented on DELTASPIKE-295:
--

I have a fix in place but don't seem to have commit rights.
Anyways, I'm not sure Weld 2 is the target anymore, is it now Weld 1.2? Is 
there a profile I can check against?

I made the following changes:

public M JsfMessageM createJsfMessage
..
try
{
@SuppressWarnings(unchecked)
ClassM type = (ClassM) actualTypes[0];
return createJsfMessageFor(injectionPoint, type);
}
...
private M JsfMessageM createJsfMessageFor

but don't seem to see a Weld 1.2 profile.

 JsfMessageProducer createJsfMessage return type should be parametrized
 --

 Key: DELTASPIKE-295
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-295
 Project: DeltaSpike
  Issue Type: Bug
  Components: JSF-Module
Affects Versions: 0.4-incubating
 Environment: Current 0.4-incubating snapshot, Weld 2.0.0.Beta1
Reporter: Marek Schmidt
Assignee: John D. Ament
 Fix For: 0.4-incubating


 The 
 {code}
 public JsfMessage createJsfMessage(InjectionPoint injectionPoint)
 {code}
 should probably be
 {code}
 public T JsfMessageT createJsfMessage(InjectionPoint injectionPoint)
 {code}
 instead.
 The problem manifests itself in Weld 2.0.0.Beta1:
 {noformat}
 Tests in error: 
   org.apache.deltaspike.test.jsf.impl.message.JsfMessageTest: Could not 
 deploy to container: {JBAS014671: Failed services = 
 {jboss.deployment.unit.\jsfMessageTest.war\.WeldService = 
 org.jboss.msc.service.StartException in service 
 jboss.deployment.unit.\jsfMessageTest.war\.WeldService: 
 org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied 
 dependencies for type [JsfMessageUserMessage] with qualifiers [@Default] at 
 injection point [[BackedAnnotatedField] @Inject private 
 org.apache.deltaspike.test.jsf.impl.message.beans.JsfMessageBackingBean.msg]}}
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Push rights to the git repo?

2013-03-08 Thread John D. Ament

Nevermind, it apparently was truly a credential issue.  I was able to login
to JIRA using the credential I knew, but it stopped working in GIT.  Fixed
now.




On Fri, Mar 8, 2013 at 7:28 AM, John D. Ament john.d.am...@gmail.comwrote:

 As far as I know, my username is johndament and I've been a committer
 (who hasn't done much) since the start.  Yet I cannot push, receive
 Authentication failed.

 So please let me know what I might be doing wrong.  Am I not supposed to
 push as johndament?

[jira] [Resolved] (DELTASPIKE-295) JsfMessageProducer createJsfMessage return type should be parametrized


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-295.
--

Resolution: Fixed

Ran this on the JSF module

mvn clean install -PWeld -Dweld.version=1.2.0-SNAPSHOT -PJBossSnapshots

Which if I had to guess runs in Weld mode using Weld 1.2.  Seems to work fine.  
I'm going to mark this resolved, but feel free to comment if it's not doing 
what you expect.

 JsfMessageProducer createJsfMessage return type should be parametrized
 --

 Key: DELTASPIKE-295
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-295
 Project: DeltaSpike
  Issue Type: Bug
  Components: JSF-Module
Affects Versions: 0.4-incubating
 Environment: Current 0.4-incubating snapshot, Weld 2.0.0.Beta1
Reporter: Marek Schmidt
Assignee: John D. Ament
 Fix For: 0.4-incubating


 The 
 {code}
 public JsfMessage createJsfMessage(InjectionPoint injectionPoint)
 {code}
 should probably be
 {code}
 public T JsfMessageT createJsfMessage(InjectionPoint injectionPoint)
 {code}
 instead.
 The problem manifests itself in Weld 2.0.0.Beta1:
 {noformat}
 Tests in error: 
   org.apache.deltaspike.test.jsf.impl.message.JsfMessageTest: Could not 
 deploy to container: {JBAS014671: Failed services = 
 {jboss.deployment.unit.\jsfMessageTest.war\.WeldService = 
 org.jboss.msc.service.StartException in service 
 jboss.deployment.unit.\jsfMessageTest.war\.WeldService: 
 org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied 
 dependencies for type [JsfMessageUserMessage] with qualifiers [@Default] at 
 injection point [[BackedAnnotatedField] @Inject private 
 org.apache.deltaspike.test.jsf.impl.message.beans.JsfMessageBackingBean.msg]}}
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DELTASPIKE-295) JsfMessageProducer createJsfMessage return type should be parametrized