Re: Servlet Module - Do we really need @Web?

2014-02-17 Thread Romain Manni-Bucau
@Gerhard: loos too much to existing JMX APIs + managed doesn't mean
anything anymore today IMO
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-02-18 8:32 GMT+01:00 Gerhard Petracek :
> @thomas:
> maybe something like @Managed or @ManagedResource
>
> regards,
> gerhard
>
>
>
> 2014-02-18 7:17 GMT+01:00 Romain Manni-Bucau :
>
>> @DeltaSpike?
>> Le 18 févr. 2014 06:26, "Christian Kaltepoth"  a
>> écrit :
>>
>> > @Thomas: I also like the idea of a global qualifier like this. That's
>> > something I was already looking for when I created @Web back then. But
>> the
>> > most difficult question is what the name should be. Unfortunately I've no
>> > really good idea.
>> >
>> >
>> > 2014-02-15 15:26 GMT+01:00 Thomas Andraschko <
>> andraschko.tho...@gmail.com
>> > >:
>> >
>> > > +1
>> > > Any ideas about the name gerhard?
>> > >
>> > > Any veto about such a change?
>> > >
>> > >
>> > >
>> > >
>> > > 2014-02-15 11:29 GMT+01:00 Gerhard Petracek <
>> gerhard.petra...@gmail.com
>> > >:
>> > >
>> > > > i'm ok with changing it, if we do it for both.
>> > > > however, we would need a better name (imo without the project-name).
>> > > >
>> > > > regards,
>> > > > gerhard
>> > > >
>> > > >
>> > > >
>> > > > 2014-02-15 11:24 GMT+01:00 Thomas Andraschko <
>> > > andraschko.tho...@gmail.com
>> > > > >:
>> > > >
>> > > > > I found another case were something like
>> > > > > @DeltaSpike/@DeltaSpikeManaged/etc. would probably be a better
>> name:
>> > > > >
>> > > > > @JsfPhaseListener public class MyPhaseListener implements
>> > > PhaseListener {
>> > > > > ... }
>> > > > >
>> > > > > It's the same as with @Web.
>> > > > > We already know that it's an PhaseListener. So why name the
>> > annotation
>> > > > the
>> > > > > same again?
>> > > > > We also already know that a HttpServletRequest is something from
>> the
>> > > > Web...
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > 2014-01-07 17:44 GMT+01:00 Thomas Andraschko <
>> > > > andraschko.tho...@gmail.com
>> > > > > >:
>> > > > >
>> > > > > > In the CDI 1.1 specs (3.7), there are only following beans
>> defined:
>> > > > > > HttpServletRequest
>> > > > > > HttpSession
>> > > > > > ServletContext
>> > > > > >
>> > > > > > So if you are in a CDI 1.1 environment, it might be confusing
>> > because
>> > > > > some
>> > > > > > artifacts are available without @Web and some only with @Web.
>> > > > > > I will open a vote about it because i can't see a reason to keep
>> > @Web
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > 2014/1/5 Karl Kildén 
>> > > > > >
>> > > > > >> This is my summary:
>> > > > > >>
>> > > > > >> By following the discussion it seems to be seen as convenient vs
>> > > > > >> inconvenient and the vote is kinda even. What I would like to
>> see
>> > is
>> > > > > >> cohesion in Deltaspike overall. Either you use namespaces or you
>> > > > don't.
>> > > > > My
>> > > > > >> point is basically that it feels more like a project-wide
>> > decision.
>> > > > > >>
>> > > > > >> To summarize, when a spec or w/e is expected to introduce the
>> same
>> > > > > >> producer
>> > > > > >> different strategies can be used. So either the strategy as a
>> user
>> > > is
>> > > > to
>> > > > > >> a)
>> > > > > >> use the namespace and drop it when someone else provides it
>> (i.e a
>> > > > spec)
>> > > > > >> or
>> > > > > >> b) Trust Deltaspike to handle any conflicts.
>> > > > > >>
>> > > > > >> pros:
>> > > > > >> - No conflicts or conflict management.
>> > > > > >> - Users can use both variants for example if Deltaspike offers
>> > > extras.
>> > > > > >> Apparently already true for Servlet Module.
>> > > > > >> - Abolishes the idea of transparent replacement with the
>> argument
>> > > that
>> > > > > >> various enhancements might make it incompatible anyways.
>> > > > > >>
>> > > > > >> cons:
>> > > > > >> - Must remove namespace when Deltaspike is superfluous. No
>> > namespace
>> > > > and
>> > > > > >> automatic veto would make it more seamless.
>> > > > > >> - More verbose and not as pretty to use.
>> > > > > >> - Does not see incompatibly as a big problem. Reasoning is:  End
>> > > user
>> > > > > must
>> > > > > >> test application behavior after upgrade anyway and problems
>> should
>> > > be
>> > > > > >> minor.
>> > > > > >>
>> > > > > >> Btw i'm +0
>> > > > > >>
>> > > > > >>
>> > > > > >> On 4 January 2014 17:09, Gerhard Petracek <
>> > > gerhard.petra...@gmail.com
>> > > > > >> >wrote:
>> > > > > >>
>> > > > > >> > to summarize it:
>> > > > > >> > so far we haven't seen a real blocker for dropping the
>> > qualifier.
>> > > > > >> >
>> > > > > >> > regards,
>> > > > > >> > gerhard
>> > > > > >> >
>> > > > > >> >
>> > > > > >> >
>> > > > > >> > 2014/1/4 Romain Manni-Bucau 
>> > > > > >> >
>> > > > > >> > > never said it was blocking, just it shouldn't be done
>> blindly
>> > > and
>> > > > > docs
>> > > > > >> > 

[jira] [Reopened] (DELTASPIKE-399) Incorporate Solder's ResourceLoader features into DeltaSpike

2014-02-17 Thread Gerhard Petracek (JIRA)

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

Gerhard Petracek reopened DELTASPIKE-399:
-


since people start blocking changes after a 0.x release, we can't wait for 
(user-)feedback after the upcoming release.

open topics:
 - simplified implementation
 - different name

> Incorporate Solder's ResourceLoader features into DeltaSpike
> 
>
> Key: DELTASPIKE-399
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-399
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 0.4
>Reporter: Aaron Siri
>Assignee: John D. Ament
>Priority: Minor
> Fix For: 0.6
>
> Attachments: DELTASPIKE-399_merged_interface.patch
>
>
> Seam 3's Solder module had some nice resource loading functionality within 
> the org.jboss.solder.resourceLoader packages.  With it you could do the 
> following:
> // Load a properties file
> @Inject @Resource("app.properties")
> private Properties appProperties;
> or:
> @Inject
> private ResourceProvider resourceProvider
> public Properties getHostProperties() {
>String hostname = java.net.InetAddress.getLocalHost().getHostName();
>return resourceProvider.loadPropertiesBundle(hostname + ".properties");
> }



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (DELTASPIKE-515) optional adapter for MockedJsfTestContainer

2014-02-17 Thread Gerhard Petracek (JIRA)

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

Gerhard Petracek updated DELTASPIKE-515:


Attachment: (was: DELTASPIKE-5151.patch)

> optional adapter for MockedJsfTestContainer
> ---
>
> Key: DELTASPIKE-515
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-515
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: TestControl
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
> Fix For: 0.6
>
> Attachments: DELTASPIKE-515.patch
>
>
> myfaces-test v1.0.6+ will provide MockedJsfTestContainer -> with an adapter 
> we can delegate to it



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (DELTASPIKE-515) optional adapter for MockedJsfTestContainer

2014-02-17 Thread Gerhard Petracek (JIRA)

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

Gerhard Petracek updated DELTASPIKE-515:


Attachment: DELTASPIKE-515.patch

> optional adapter for MockedJsfTestContainer
> ---
>
> Key: DELTASPIKE-515
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-515
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: TestControl
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
> Fix For: 0.6
>
> Attachments: DELTASPIKE-515.patch
>
>
> myfaces-test v1.0.6+ will provide MockedJsfTestContainer -> with an adapter 
> we can delegate to it



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


Re: Servlet Module - Do we really need @Web?

2014-02-17 Thread Gerhard Petracek
@thomas:
maybe something like @Managed or @ManagedResource

regards,
gerhard



2014-02-18 7:17 GMT+01:00 Romain Manni-Bucau :

> @DeltaSpike?
> Le 18 févr. 2014 06:26, "Christian Kaltepoth"  a
> écrit :
>
> > @Thomas: I also like the idea of a global qualifier like this. That's
> > something I was already looking for when I created @Web back then. But
> the
> > most difficult question is what the name should be. Unfortunately I've no
> > really good idea.
> >
> >
> > 2014-02-15 15:26 GMT+01:00 Thomas Andraschko <
> andraschko.tho...@gmail.com
> > >:
> >
> > > +1
> > > Any ideas about the name gerhard?
> > >
> > > Any veto about such a change?
> > >
> > >
> > >
> > >
> > > 2014-02-15 11:29 GMT+01:00 Gerhard Petracek <
> gerhard.petra...@gmail.com
> > >:
> > >
> > > > i'm ok with changing it, if we do it for both.
> > > > however, we would need a better name (imo without the project-name).
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2014-02-15 11:24 GMT+01:00 Thomas Andraschko <
> > > andraschko.tho...@gmail.com
> > > > >:
> > > >
> > > > > I found another case were something like
> > > > > @DeltaSpike/@DeltaSpikeManaged/etc. would probably be a better
> name:
> > > > >
> > > > > @JsfPhaseListener public class MyPhaseListener implements
> > > PhaseListener {
> > > > > ... }
> > > > >
> > > > > It's the same as with @Web.
> > > > > We already know that it's an PhaseListener. So why name the
> > annotation
> > > > the
> > > > > same again?
> > > > > We also already know that a HttpServletRequest is something from
> the
> > > > Web...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2014-01-07 17:44 GMT+01:00 Thomas Andraschko <
> > > > andraschko.tho...@gmail.com
> > > > > >:
> > > > >
> > > > > > In the CDI 1.1 specs (3.7), there are only following beans
> defined:
> > > > > > HttpServletRequest
> > > > > > HttpSession
> > > > > > ServletContext
> > > > > >
> > > > > > So if you are in a CDI 1.1 environment, it might be confusing
> > because
> > > > > some
> > > > > > artifacts are available without @Web and some only with @Web.
> > > > > > I will open a vote about it because i can't see a reason to keep
> > @Web
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2014/1/5 Karl Kildén 
> > > > > >
> > > > > >> This is my summary:
> > > > > >>
> > > > > >> By following the discussion it seems to be seen as convenient vs
> > > > > >> inconvenient and the vote is kinda even. What I would like to
> see
> > is
> > > > > >> cohesion in Deltaspike overall. Either you use namespaces or you
> > > > don't.
> > > > > My
> > > > > >> point is basically that it feels more like a project-wide
> > decision.
> > > > > >>
> > > > > >> To summarize, when a spec or w/e is expected to introduce the
> same
> > > > > >> producer
> > > > > >> different strategies can be used. So either the strategy as a
> user
> > > is
> > > > to
> > > > > >> a)
> > > > > >> use the namespace and drop it when someone else provides it
> (i.e a
> > > > spec)
> > > > > >> or
> > > > > >> b) Trust Deltaspike to handle any conflicts.
> > > > > >>
> > > > > >> pros:
> > > > > >> - No conflicts or conflict management.
> > > > > >> - Users can use both variants for example if Deltaspike offers
> > > extras.
> > > > > >> Apparently already true for Servlet Module.
> > > > > >> - Abolishes the idea of transparent replacement with the
> argument
> > > that
> > > > > >> various enhancements might make it incompatible anyways.
> > > > > >>
> > > > > >> cons:
> > > > > >> - Must remove namespace when Deltaspike is superfluous. No
> > namespace
> > > > and
> > > > > >> automatic veto would make it more seamless.
> > > > > >> - More verbose and not as pretty to use.
> > > > > >> - Does not see incompatibly as a big problem. Reasoning is:  End
> > > user
> > > > > must
> > > > > >> test application behavior after upgrade anyway and problems
> should
> > > be
> > > > > >> minor.
> > > > > >>
> > > > > >> Btw i'm +0
> > > > > >>
> > > > > >>
> > > > > >> On 4 January 2014 17:09, Gerhard Petracek <
> > > gerhard.petra...@gmail.com
> > > > > >> >wrote:
> > > > > >>
> > > > > >> > to summarize it:
> > > > > >> > so far we haven't seen a real blocker for dropping the
> > qualifier.
> > > > > >> >
> > > > > >> > regards,
> > > > > >> > gerhard
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > 2014/1/4 Romain Manni-Bucau 
> > > > > >> >
> > > > > >> > > never said it was blocking, just it shouldn't be done
> blindly
> > > and
> > > > > docs
> > > > > >> > > should be very explicit on it and potential conflict
> (usually
> > we
> > > > > don't
> > > > > >> > > care to not mention we don't use a qualifier, here we do).
> > > > > >> > > Romain Manni-Bucau
> > > > > >> > > Twitter: @rmannibucau
> > > > > >> > > Blog: http://rmannibucau.wordpress.com/
> > > > > >> > > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > > > >> > > Github: https://github.com/rmannibucau
> > > > > >> > >
> > > > > >> > >
> > > > > >> > >
> > > > > >

Re: Servlet Module - Do we really need @Web?

2014-02-17 Thread Romain Manni-Bucau
@DeltaSpike?
Le 18 févr. 2014 06:26, "Christian Kaltepoth"  a
écrit :

> @Thomas: I also like the idea of a global qualifier like this. That's
> something I was already looking for when I created @Web back then. But the
> most difficult question is what the name should be. Unfortunately I've no
> really good idea.
>
>
> 2014-02-15 15:26 GMT+01:00 Thomas Andraschko  >:
>
> > +1
> > Any ideas about the name gerhard?
> >
> > Any veto about such a change?
> >
> >
> >
> >
> > 2014-02-15 11:29 GMT+01:00 Gerhard Petracek  >:
> >
> > > i'm ok with changing it, if we do it for both.
> > > however, we would need a better name (imo without the project-name).
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2014-02-15 11:24 GMT+01:00 Thomas Andraschko <
> > andraschko.tho...@gmail.com
> > > >:
> > >
> > > > I found another case were something like
> > > > @DeltaSpike/@DeltaSpikeManaged/etc. would probably be a better name:
> > > >
> > > > @JsfPhaseListener public class MyPhaseListener implements
> > PhaseListener {
> > > > ... }
> > > >
> > > > It's the same as with @Web.
> > > > We already know that it's an PhaseListener. So why name the
> annotation
> > > the
> > > > same again?
> > > > We also already know that a HttpServletRequest is something from the
> > > Web...
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 2014-01-07 17:44 GMT+01:00 Thomas Andraschko <
> > > andraschko.tho...@gmail.com
> > > > >:
> > > >
> > > > > In the CDI 1.1 specs (3.7), there are only following beans defined:
> > > > > HttpServletRequest
> > > > > HttpSession
> > > > > ServletContext
> > > > >
> > > > > So if you are in a CDI 1.1 environment, it might be confusing
> because
> > > > some
> > > > > artifacts are available without @Web and some only with @Web.
> > > > > I will open a vote about it because i can't see a reason to keep
> @Web
> > > > >
> > > > >
> > > > >
> > > > > 2014/1/5 Karl Kildén 
> > > > >
> > > > >> This is my summary:
> > > > >>
> > > > >> By following the discussion it seems to be seen as convenient vs
> > > > >> inconvenient and the vote is kinda even. What I would like to see
> is
> > > > >> cohesion in Deltaspike overall. Either you use namespaces or you
> > > don't.
> > > > My
> > > > >> point is basically that it feels more like a project-wide
> decision.
> > > > >>
> > > > >> To summarize, when a spec or w/e is expected to introduce the same
> > > > >> producer
> > > > >> different strategies can be used. So either the strategy as a user
> > is
> > > to
> > > > >> a)
> > > > >> use the namespace and drop it when someone else provides it (i.e a
> > > spec)
> > > > >> or
> > > > >> b) Trust Deltaspike to handle any conflicts.
> > > > >>
> > > > >> pros:
> > > > >> - No conflicts or conflict management.
> > > > >> - Users can use both variants for example if Deltaspike offers
> > extras.
> > > > >> Apparently already true for Servlet Module.
> > > > >> - Abolishes the idea of transparent replacement with the argument
> > that
> > > > >> various enhancements might make it incompatible anyways.
> > > > >>
> > > > >> cons:
> > > > >> - Must remove namespace when Deltaspike is superfluous. No
> namespace
> > > and
> > > > >> automatic veto would make it more seamless.
> > > > >> - More verbose and not as pretty to use.
> > > > >> - Does not see incompatibly as a big problem. Reasoning is:  End
> > user
> > > > must
> > > > >> test application behavior after upgrade anyway and problems should
> > be
> > > > >> minor.
> > > > >>
> > > > >> Btw i'm +0
> > > > >>
> > > > >>
> > > > >> On 4 January 2014 17:09, Gerhard Petracek <
> > gerhard.petra...@gmail.com
> > > > >> >wrote:
> > > > >>
> > > > >> > to summarize it:
> > > > >> > so far we haven't seen a real blocker for dropping the
> qualifier.
> > > > >> >
> > > > >> > regards,
> > > > >> > gerhard
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > 2014/1/4 Romain Manni-Bucau 
> > > > >> >
> > > > >> > > never said it was blocking, just it shouldn't be done blindly
> > and
> > > > docs
> > > > >> > > should be very explicit on it and potential conflict (usually
> we
> > > > don't
> > > > >> > > care to not mention we don't use a qualifier, here we do).
> > > > >> > > Romain Manni-Bucau
> > > > >> > > Twitter: @rmannibucau
> > > > >> > > Blog: http://rmannibucau.wordpress.com/
> > > > >> > > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > > >> > > Github: https://github.com/rmannibucau
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > 2014/1/4 Gerhard Petracek :
> > > > >> > > > it was just one of several possibilities you have.
> > > > >> > > > in any case, the special case you mentioned is still easy
> > enough
> > > > ->
> > > > >> > there
> > > > >> > > > is no issue/blocker imo.
> > > > >> > > >
> > > > >> > > > regards,
> > > > >> > > > gerhard
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > 2014/1/4 Romain Manni-Bucau 
> > > > >> > > >
> > > > >> > > >> so didnt get your comment on decorators...
> > > > >> > > >> R

Re: [DISCUSS] next release version? 0.6 or 1.0?

2014-02-17 Thread Christian Kaltepoth
+1 for pushing out 0.6 ASAP and 1.0 as soon as all the "must have" features
are complete.


2014-02-17 10:10 GMT+01:00 Mark Struberg :

> Oki, I can help a bit with ViewAccessScoped. Romain and Thomas, please fix
> the Tx stuff.
>
> In that case I'd say we gonna ship a 0.6 and then in 3 weeks move to 1.0.
>
> wdyt?
>
>
> LieGrue,
> strub
>
>
>
>
>
> On Monday, 17 February 2014, 10:06, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
>
> Hi
> >
> >
> >can we wait 1 or 2 weeks (no more) to see if we can sort out @Repo/@Tx
> >stuff? Basically I'm waiting after it for months and this is blocker
> >to be used ATM.
> >Romain Manni-Bucau
> >Twitter: @rmannibucau
> >Blog: http://rmannibucau.wordpress.com/
> >LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >Github: https://github.com/rmannibucau
> >
> >
> >
> >
> >2014-02-17 9:57 GMT+01:00 Mark Struberg :
> >> back 2 the topic, please!
> >>
> >> I'd say we should approach 1.0 NOW.
> >>
> >> DeltaSpike core and a few other modules is really rock solid already
> since a year or so. It is also used heavily in production already.
> >> There will always be some modules which are not so perfectly mature at
> times. E.g. if we will add a new module.
> >>
> >> Thus I already did propose a methology which would fix this shortcoming:
> >> We might introduce an 'ample page' which contains the status of each
> project - stable / ready /in progress
> >>
> >> You know, the traffic light thingy where green means the module (e.g.
> deltaspike-core) is stable and the API will not change or we will at least
> be backward compatible unless we do a major new version.
> >> Orange means that the module has been tested and looks good. Whereas
> red means that the api might change still.
> >>
> >> What road blockers do we have before 1.0?
> >> Please note that there is always something one can do better - but this
> should not hinder us from releasing until something is really broken.
> >> Also the documentation is *not* a show stopper - it is perfectly fine
> to ship this later as our CMS is completely asynchronous.
> >>
> >>
> >> So what BLOCKERS do you see before I go and press the release button?
> >> Like to do that on Wednesday...
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>
> >> On Sunday, 16 February 2014, 23:14, Ove Ranheim 
> wrote:
> >>
> >> That's reasonable enough.
> >>>
> >>>
> >>>On 16. feb. 2014, at 23:02, Jason Porter 
> wrote:
> >>>
>  Probably because we've become busy with some other projects and
> priorities :(--
>  Sent from Mailbox for iPhone
> 
>  On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim 
> wrote:
> 
> > The commit graph shows too few committers.. and I appreciate your
> work!
> > I also notice too few Redhat/JBoss Weld/Seam committers left on the
> project. How come?
> > /ove
> > On 16. feb. 2014, at 22:10, Gerhard Petracek <
> gerhard.petra...@gmail.com> wrote:
> >> hi ove,
> >>
> >> i was only talking about the commits.
> >>
> >> regards,
> >> gerhard
> >>
> >> http://www.irian.at
> >>
> >> Your JSF/JavaEE powerhouse -
> >> JavaEE Consulting, Development and
> >> Courses in English and German
> >>
> >> Professional Support for Apache MyFaces
> >>
> >>
> >>
> >> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko <
> andraschko.tho...@gmail.com>:
> >>
> >>> +1 Ove
> >>> We are really late for an 0.6. I would release 0.6 this/next month
> and
> >>> after that, lets finish 1.0.
> >>> We should fix all open issues and finish the documentation!
> >>>
> >>>
> >>>
> >
> >
> >
>



-- 
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal


Re: Servlet Module - Do we really need @Web?

2014-02-17 Thread Christian Kaltepoth
@Thomas: I also like the idea of a global qualifier like this. That's
something I was already looking for when I created @Web back then. But the
most difficult question is what the name should be. Unfortunately I've no
really good idea.


2014-02-15 15:26 GMT+01:00 Thomas Andraschko :

> +1
> Any ideas about the name gerhard?
>
> Any veto about such a change?
>
>
>
>
> 2014-02-15 11:29 GMT+01:00 Gerhard Petracek :
>
> > i'm ok with changing it, if we do it for both.
> > however, we would need a better name (imo without the project-name).
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2014-02-15 11:24 GMT+01:00 Thomas Andraschko <
> andraschko.tho...@gmail.com
> > >:
> >
> > > I found another case were something like
> > > @DeltaSpike/@DeltaSpikeManaged/etc. would probably be a better name:
> > >
> > > @JsfPhaseListener public class MyPhaseListener implements
> PhaseListener {
> > > ... }
> > >
> > > It's the same as with @Web.
> > > We already know that it's an PhaseListener. So why name the annotation
> > the
> > > same again?
> > > We also already know that a HttpServletRequest is something from the
> > Web...
> > >
> > >
> > >
> > >
> > >
> > > 2014-01-07 17:44 GMT+01:00 Thomas Andraschko <
> > andraschko.tho...@gmail.com
> > > >:
> > >
> > > > In the CDI 1.1 specs (3.7), there are only following beans defined:
> > > > HttpServletRequest
> > > > HttpSession
> > > > ServletContext
> > > >
> > > > So if you are in a CDI 1.1 environment, it might be confusing because
> > > some
> > > > artifacts are available without @Web and some only with @Web.
> > > > I will open a vote about it because i can't see a reason to keep @Web
> > > >
> > > >
> > > >
> > > > 2014/1/5 Karl Kildén 
> > > >
> > > >> This is my summary:
> > > >>
> > > >> By following the discussion it seems to be seen as convenient vs
> > > >> inconvenient and the vote is kinda even. What I would like to see is
> > > >> cohesion in Deltaspike overall. Either you use namespaces or you
> > don't.
> > > My
> > > >> point is basically that it feels more like a project-wide decision.
> > > >>
> > > >> To summarize, when a spec or w/e is expected to introduce the same
> > > >> producer
> > > >> different strategies can be used. So either the strategy as a user
> is
> > to
> > > >> a)
> > > >> use the namespace and drop it when someone else provides it (i.e a
> > spec)
> > > >> or
> > > >> b) Trust Deltaspike to handle any conflicts.
> > > >>
> > > >> pros:
> > > >> - No conflicts or conflict management.
> > > >> - Users can use both variants for example if Deltaspike offers
> extras.
> > > >> Apparently already true for Servlet Module.
> > > >> - Abolishes the idea of transparent replacement with the argument
> that
> > > >> various enhancements might make it incompatible anyways.
> > > >>
> > > >> cons:
> > > >> - Must remove namespace when Deltaspike is superfluous. No namespace
> > and
> > > >> automatic veto would make it more seamless.
> > > >> - More verbose and not as pretty to use.
> > > >> - Does not see incompatibly as a big problem. Reasoning is:  End
> user
> > > must
> > > >> test application behavior after upgrade anyway and problems should
> be
> > > >> minor.
> > > >>
> > > >> Btw i'm +0
> > > >>
> > > >>
> > > >> On 4 January 2014 17:09, Gerhard Petracek <
> gerhard.petra...@gmail.com
> > > >> >wrote:
> > > >>
> > > >> > to summarize it:
> > > >> > so far we haven't seen a real blocker for dropping the qualifier.
> > > >> >
> > > >> > regards,
> > > >> > gerhard
> > > >> >
> > > >> >
> > > >> >
> > > >> > 2014/1/4 Romain Manni-Bucau 
> > > >> >
> > > >> > > never said it was blocking, just it shouldn't be done blindly
> and
> > > docs
> > > >> > > should be very explicit on it and potential conflict (usually we
> > > don't
> > > >> > > care to not mention we don't use a qualifier, here we do).
> > > >> > > Romain Manni-Bucau
> > > >> > > Twitter: @rmannibucau
> > > >> > > Blog: http://rmannibucau.wordpress.com/
> > > >> > > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > >> > > Github: https://github.com/rmannibucau
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > 2014/1/4 Gerhard Petracek :
> > > >> > > > it was just one of several possibilities you have.
> > > >> > > > in any case, the special case you mentioned is still easy
> enough
> > > ->
> > > >> > there
> > > >> > > > is no issue/blocker imo.
> > > >> > > >
> > > >> > > > regards,
> > > >> > > > gerhard
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > 2014/1/4 Romain Manni-Bucau 
> > > >> > > >
> > > >> > > >> so didnt get your comment on decorators...
> > > >> > > >> Romain Manni-Bucau
> > > >> > > >> Twitter: @rmannibucau
> > > >> > > >> Blog: http://rmannibucau.wordpress.com/
> > > >> > > >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > >> > > >> Github: https://github.com/rmannibucau
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >> 2014/1/4 Gerhard Petracek :
> > > >> > > >> > @romain:
> > > >> > > >> > you should do the wrapping lik

[jira] [Updated] (DELTASPIKE-523) align event-packages

2014-02-17 Thread Gerhard Petracek (JIRA)

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

Gerhard Petracek updated DELTASPIKE-523:


Description: 
exception-control isn't using an own "event" sub-package (like it is used in 
other parts)

furthermore, we are using the term "Broadcaster" instead of "Dispatch" (-> 
ExceptionHandlerDispatch should be aligned as well)

  was:exception-control isn't using an own "event" sub-package (like it is used 
in other parts)


> align event-packages
> 
>
> Key: DELTASPIKE-523
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-523
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Core, ExceptionControl-Module
>Affects Versions: 0.5
>Reporter: Gerhard Petracek
>Assignee: Jason Porter
>Priority: Blocker
> Fix For: 0.6
>
>
> exception-control isn't using an own "event" sub-package (like it is used in 
> other parts)
> furthermore, we are using the term "Broadcaster" instead of "Dispatch" (-> 
> ExceptionHandlerDispatch should be aligned as well)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Created] (DELTASPIKE-523) align event-packages

2014-02-17 Thread Gerhard Petracek (JIRA)
Gerhard Petracek created DELTASPIKE-523:
---

 Summary: align event-packages
 Key: DELTASPIKE-523
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-523
 Project: DeltaSpike
  Issue Type: Task
  Components: Core, ExceptionControl-Module
Affects Versions: 0.5
Reporter: Gerhard Petracek
Assignee: Jason Porter
Priority: Blocker
 Fix For: 0.6


exception-control isn't using an own "event" sub-package (like it is used in 
other parts)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (DELTASPIKE-515) optional adapter for MockedJsfTestContainer

2014-02-17 Thread Gerhard Petracek (JIRA)

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

Gerhard Petracek updated DELTASPIKE-515:


Attachment: DELTASPIKE-5151.patch

> optional adapter for MockedJsfTestContainer
> ---
>
> Key: DELTASPIKE-515
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-515
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: TestControl
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
> Fix For: 0.6
>
> Attachments: DELTASPIKE-5151.patch
>
>
> myfaces-test v1.0.6+ will provide MockedJsfTestContainer -> with an adapter 
> we can delegate to it



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


Re: [DISCUSS] next release version? 0.6 or 1.0?

2014-02-17 Thread Ove Ranheim
Hi Antoine, it's good to hear that more red hat committers are on its way :)

On 17 Feb 2014, at 16:22, Antoine Sabot-Durand  wrote:

> Yes Ove, too few Red Hat committers. But they’re will be one more when CDI 
> 1.2 will be out and work for preparing CDI 2.0 will be on track.
> 
> Antoine Sabot-Durand
> ———
> Twitter : @antoine_sd
> CDI co-spec lead & eco-system development
> Agorava tech lead
> 
> 
> Le 16 févr. 2014 à 22:38, Ove Ranheim  a écrit :
> 
>> The commit graph shows too few committers.. and I appreciate your work! 
>> 
>> I also notice too few Redhat/JBoss Weld/Seam committers left on the project. 
>> How come?
>> 
>> /ove
>> 
>> On 16. feb. 2014, at 22:10, Gerhard Petracek  
>> wrote:
>> 
>>> hi ove,
>>> 
>>> i was only talking about the commits.
>>> 
>>> regards,
>>> gerhard
>>> 
>>> http://www.irian.at
>>> 
>>> Your JSF/JavaEE powerhouse -
>>> JavaEE Consulting, Development and
>>> Courses in English and German
>>> 
>>> Professional Support for Apache MyFaces
>>> 
>>> 
>>> 
>>> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko :
>>> 
 +1 Ove
 We are really late for an 0.6. I would release 0.6 this/next month and
 after that, lets finish 1.0.
 We should fix all open issues and finish the documentation!
 
>> 
> 
> 
> 



Re: [DISCUSS] next release version? 0.6 or 1.0?

2014-02-17 Thread Cody Lerum
+1

On Mon, Feb 17, 2014 at 2:10 AM, Mark Struberg  wrote:
> Oki, I can help a bit with ViewAccessScoped. Romain and Thomas, please fix 
> the Tx stuff.
>
> In that case I'd say we gonna ship a 0.6 and then in 3 weeks move to 1.0.
>
> wdyt?
>
>
> LieGrue,
> strub
>
>
>
>
>
> On Monday, 17 February 2014, 10:06, Romain Manni-Bucau 
>  wrote:
>
> Hi
>>
>>
>>can we wait 1 or 2 weeks (no more) to see if we can sort out @Repo/@Tx
>>stuff? Basically I'm waiting after it for months and this is blocker
>>to be used ATM.
>>Romain Manni-Bucau
>>Twitter: @rmannibucau
>>Blog: http://rmannibucau.wordpress.com/
>>LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>Github: https://github.com/rmannibucau
>>
>>
>>
>>
>>2014-02-17 9:57 GMT+01:00 Mark Struberg :
>>> back 2 the topic, please!
>>>
>>> I'd say we should approach 1.0 NOW.
>>>
>>> DeltaSpike core and a few other modules is really rock solid already since 
>>> a year or so. It is also used heavily in production already.
>>> There will always be some modules which are not so perfectly mature at 
>>> times. E.g. if we will add a new module.
>>>
>>> Thus I already did propose a methology which would fix this shortcoming:
>>> We might introduce an 'ample page' which contains the status of each 
>>> project - stable / ready /in progress
>>>
>>> You know, the traffic light thingy where green means the module (e.g. 
>>> deltaspike-core) is stable and the API will not change or we will at least 
>>> be backward compatible unless we do a major new version.
>>> Orange means that the module has been tested and looks good. Whereas red 
>>> means that the api might change still.
>>>
>>> What road blockers do we have before 1.0?
>>> Please note that there is always something one can do better - but this 
>>> should not hinder us from releasing until something is really broken.
>>> Also the documentation is *not* a show stopper - it is perfectly fine to 
>>> ship this later as our CMS is completely asynchronous.
>>>
>>>
>>> So what BLOCKERS do you see before I go and press the release button?
>>> Like to do that on Wednesday...
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>> On Sunday, 16 February 2014, 23:14, Ove Ranheim  wrote:
>>>
>>> That's reasonable enough.


On 16. feb. 2014, at 23:02, Jason Porter  wrote:

> Probably because we've become busy with some other projects and 
> priorities :(--
> Sent from Mailbox for iPhone
>
> On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim  wrote:
>
>> The commit graph shows too few committers.. and I appreciate your work!
>> I also notice too few Redhat/JBoss Weld/Seam committers left on the 
>> project. How come?
>> /ove
>> On 16. feb. 2014, at 22:10, Gerhard Petracek 
>>  wrote:
>>> hi ove,
>>>
>>> i was only talking about the commits.
>>>
>>> regards,
>>> gerhard
>>>
>>> http://www.irian.at
>>>
>>> Your JSF/JavaEE powerhouse -
>>> JavaEE Consulting, Development and
>>> Courses in English and German
>>>
>>> Professional Support for Apache MyFaces
>>>
>>>
>>>
>>> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko 
>>> :
>>>
 +1 Ove
 We are really late for an 0.6. I would release 0.6 this/next month and
 after that, lets finish 1.0.
 We should fix all open issues and finish the documentation!



>>
>>
>>


Re: [DISCUSS] next release version? 0.6 or 1.0?

2014-02-17 Thread Antoine Sabot-Durand
Yes Ove, too few Red Hat committers. But they’re will be one more when CDI 1.2 
will be out and work for preparing CDI 2.0 will be on track.

Antoine Sabot-Durand
———
Twitter : @antoine_sd
CDI co-spec lead & eco-system development
Agorava tech lead


Le 16 févr. 2014 à 22:38, Ove Ranheim  a écrit :

> The commit graph shows too few committers.. and I appreciate your work! 
> 
> I also notice too few Redhat/JBoss Weld/Seam committers left on the project. 
> How come?
> 
> /ove
> 
> On 16. feb. 2014, at 22:10, Gerhard Petracek  
> wrote:
> 
>> hi ove,
>> 
>> i was only talking about the commits.
>> 
>> regards,
>> gerhard
>> 
>> http://www.irian.at
>> 
>> Your JSF/JavaEE powerhouse -
>> JavaEE Consulting, Development and
>> Courses in English and German
>> 
>> Professional Support for Apache MyFaces
>> 
>> 
>> 
>> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko :
>> 
>>> +1 Ove
>>> We are really late for an 0.6. I would release 0.6 this/next month and
>>> after that, lets finish 1.0.
>>> We should fix all open issues and finish the documentation!
>>> 
> 





Re: [DISCUSS] next release version? 0.6 or 1.0?

2014-02-17 Thread Jean-Louis MONTEIRO
Mark,

Dunno for the one week delay for 0.6 and 3 weeks delay for 1.0, but +1 to
go with an intermediate step (ie. 0.6).

JLouis


2014-02-17 13:14 GMT+01:00 Thomas Andraschko :

> +1 Mark
>
>
>
> 2014-02-17 13:08 GMT+01:00 Ove Ranheim :
>
> > +1 for this :)
> >
> >
> > 2014-02-17 10:10 GMT+01:00 Mark Struberg :
> >
> > > Oki, I can help a bit with ViewAccessScoped. Romain and Thomas, please
> > fix
> > > the Tx stuff.
> > >
> > > In that case I'd say we gonna ship a 0.6 and then in 3 weeks move to
> 1.0.
> > >
> > > wdyt?
> > >
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > >
> > >
> > > On Monday, 17 February 2014, 10:06, Romain Manni-Bucau <
> > > rmannibu...@gmail.com> wrote:
> > >
> > > Hi
> > > >
> > > >
> > > >can we wait 1 or 2 weeks (no more) to see if we can sort out @Repo/@Tx
> > > >stuff? Basically I'm waiting after it for months and this is blocker
> > > >to be used ATM.
> > > >Romain Manni-Bucau
> > > >Twitter: @rmannibucau
> > > >Blog: http://rmannibucau.wordpress.com/
> > > >LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > >Github: https://github.com/rmannibucau
> > > >
> > > >
> > > >
> > > >
> > > >2014-02-17 9:57 GMT+01:00 Mark Struberg :
> > > >> back 2 the topic, please!
> > > >>
> > > >> I'd say we should approach 1.0 NOW.
> > > >>
> > > >> DeltaSpike core and a few other modules is really rock solid already
> > > since a year or so. It is also used heavily in production already.
> > > >> There will always be some modules which are not so perfectly mature
> at
> > > times. E.g. if we will add a new module.
> > > >>
> > > >> Thus I already did propose a methology which would fix this
> > shortcoming:
> > > >> We might introduce an 'ample page' which contains the status of each
> > > project - stable / ready /in progress
> > > >>
> > > >> You know, the traffic light thingy where green means the module
> (e.g.
> > > deltaspike-core) is stable and the API will not change or we will at
> > least
> > > be backward compatible unless we do a major new version.
> > > >> Orange means that the module has been tested and looks good. Whereas
> > > red means that the api might change still.
> > > >>
> > > >> What road blockers do we have before 1.0?
> > > >> Please note that there is always something one can do better - but
> > this
> > > should not hinder us from releasing until something is really broken.
> > > >> Also the documentation is *not* a show stopper - it is perfectly
> fine
> > > to ship this later as our CMS is completely asynchronous.
> > > >>
> > > >>
> > > >> So what BLOCKERS do you see before I go and press the release
> button?
> > > >> Like to do that on Wednesday...
> > > >>
> > > >>
> > > >> LieGrue,
> > > >> strub
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Sunday, 16 February 2014, 23:14, Ove Ranheim  >
> > > wrote:
> > > >>
> > > >> That's reasonable enough.
> > > >>>
> > > >>>
> > > >>>On 16. feb. 2014, at 23:02, Jason Porter 
> > > wrote:
> > > >>>
> > >  Probably because we've become busy with some other projects and
> > > priorities :(--
> > >  Sent from Mailbox for iPhone
> > > 
> > >  On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim 
> > > wrote:
> > > 
> > > > The commit graph shows too few committers.. and I appreciate your
> > > work!
> > > > I also notice too few Redhat/JBoss Weld/Seam committers left on
> the
> > > project. How come?
> > > > /ove
> > > > On 16. feb. 2014, at 22:10, Gerhard Petracek <
> > > gerhard.petra...@gmail.com> wrote:
> > > >> hi ove,
> > > >>
> > > >> i was only talking about the commits.
> > > >>
> > > >> regards,
> > > >> gerhard
> > > >>
> > > >> http://www.irian.at
> > > >>
> > > >> Your JSF/JavaEE powerhouse -
> > > >> JavaEE Consulting, Development and
> > > >> Courses in English and German
> > > >>
> > > >> Professional Support for Apache MyFaces
> > > >>
> > > >>
> > > >>
> > > >> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko <
> > > andraschko.tho...@gmail.com>:
> > > >>
> > > >>> +1 Ove
> > > >>> We are really late for an 0.6. I would release 0.6 this/next
> > month
> > > and
> > > >>> after that, lets finish 1.0.
> > > >>> We should fix all open issues and finish the documentation!
> > > >>>
> > > >>>
> > > >>>
> > > >
> > > >
> > > >
> > >
> >
>



-- 
Jean-Louis


Re: [DISCUSS] next release version? 0.6 or 1.0?

2014-02-17 Thread Thomas Andraschko
+1 Mark



2014-02-17 13:08 GMT+01:00 Ove Ranheim :

> +1 for this :)
>
>
> 2014-02-17 10:10 GMT+01:00 Mark Struberg :
>
> > Oki, I can help a bit with ViewAccessScoped. Romain and Thomas, please
> fix
> > the Tx stuff.
> >
> > In that case I'd say we gonna ship a 0.6 and then in 3 weeks move to 1.0.
> >
> > wdyt?
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> >
> > On Monday, 17 February 2014, 10:06, Romain Manni-Bucau <
> > rmannibu...@gmail.com> wrote:
> >
> > Hi
> > >
> > >
> > >can we wait 1 or 2 weeks (no more) to see if we can sort out @Repo/@Tx
> > >stuff? Basically I'm waiting after it for months and this is blocker
> > >to be used ATM.
> > >Romain Manni-Bucau
> > >Twitter: @rmannibucau
> > >Blog: http://rmannibucau.wordpress.com/
> > >LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >Github: https://github.com/rmannibucau
> > >
> > >
> > >
> > >
> > >2014-02-17 9:57 GMT+01:00 Mark Struberg :
> > >> back 2 the topic, please!
> > >>
> > >> I'd say we should approach 1.0 NOW.
> > >>
> > >> DeltaSpike core and a few other modules is really rock solid already
> > since a year or so. It is also used heavily in production already.
> > >> There will always be some modules which are not so perfectly mature at
> > times. E.g. if we will add a new module.
> > >>
> > >> Thus I already did propose a methology which would fix this
> shortcoming:
> > >> We might introduce an 'ample page' which contains the status of each
> > project - stable / ready /in progress
> > >>
> > >> You know, the traffic light thingy where green means the module (e.g.
> > deltaspike-core) is stable and the API will not change or we will at
> least
> > be backward compatible unless we do a major new version.
> > >> Orange means that the module has been tested and looks good. Whereas
> > red means that the api might change still.
> > >>
> > >> What road blockers do we have before 1.0?
> > >> Please note that there is always something one can do better - but
> this
> > should not hinder us from releasing until something is really broken.
> > >> Also the documentation is *not* a show stopper - it is perfectly fine
> > to ship this later as our CMS is completely asynchronous.
> > >>
> > >>
> > >> So what BLOCKERS do you see before I go and press the release button?
> > >> Like to do that on Wednesday...
> > >>
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>
> > >>
> > >>
> > >> On Sunday, 16 February 2014, 23:14, Ove Ranheim 
> > wrote:
> > >>
> > >> That's reasonable enough.
> > >>>
> > >>>
> > >>>On 16. feb. 2014, at 23:02, Jason Porter 
> > wrote:
> > >>>
> >  Probably because we've become busy with some other projects and
> > priorities :(--
> >  Sent from Mailbox for iPhone
> > 
> >  On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim 
> > wrote:
> > 
> > > The commit graph shows too few committers.. and I appreciate your
> > work!
> > > I also notice too few Redhat/JBoss Weld/Seam committers left on the
> > project. How come?
> > > /ove
> > > On 16. feb. 2014, at 22:10, Gerhard Petracek <
> > gerhard.petra...@gmail.com> wrote:
> > >> hi ove,
> > >>
> > >> i was only talking about the commits.
> > >>
> > >> regards,
> > >> gerhard
> > >>
> > >> http://www.irian.at
> > >>
> > >> Your JSF/JavaEE powerhouse -
> > >> JavaEE Consulting, Development and
> > >> Courses in English and German
> > >>
> > >> Professional Support for Apache MyFaces
> > >>
> > >>
> > >>
> > >> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko <
> > andraschko.tho...@gmail.com>:
> > >>
> > >>> +1 Ove
> > >>> We are really late for an 0.6. I would release 0.6 this/next
> month
> > and
> > >>> after that, lets finish 1.0.
> > >>> We should fix all open issues and finish the documentation!
> > >>>
> > >>>
> > >>>
> > >
> > >
> > >
> >
>


Re: [DISCUSS] next release version? 0.6 or 1.0?

2014-02-17 Thread Ove Ranheim
+1 for this :)


2014-02-17 10:10 GMT+01:00 Mark Struberg :

> Oki, I can help a bit with ViewAccessScoped. Romain and Thomas, please fix
> the Tx stuff.
>
> In that case I'd say we gonna ship a 0.6 and then in 3 weeks move to 1.0.
>
> wdyt?
>
>
> LieGrue,
> strub
>
>
>
>
>
> On Monday, 17 February 2014, 10:06, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
>
> Hi
> >
> >
> >can we wait 1 or 2 weeks (no more) to see if we can sort out @Repo/@Tx
> >stuff? Basically I'm waiting after it for months and this is blocker
> >to be used ATM.
> >Romain Manni-Bucau
> >Twitter: @rmannibucau
> >Blog: http://rmannibucau.wordpress.com/
> >LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >Github: https://github.com/rmannibucau
> >
> >
> >
> >
> >2014-02-17 9:57 GMT+01:00 Mark Struberg :
> >> back 2 the topic, please!
> >>
> >> I'd say we should approach 1.0 NOW.
> >>
> >> DeltaSpike core and a few other modules is really rock solid already
> since a year or so. It is also used heavily in production already.
> >> There will always be some modules which are not so perfectly mature at
> times. E.g. if we will add a new module.
> >>
> >> Thus I already did propose a methology which would fix this shortcoming:
> >> We might introduce an 'ample page' which contains the status of each
> project - stable / ready /in progress
> >>
> >> You know, the traffic light thingy where green means the module (e.g.
> deltaspike-core) is stable and the API will not change or we will at least
> be backward compatible unless we do a major new version.
> >> Orange means that the module has been tested and looks good. Whereas
> red means that the api might change still.
> >>
> >> What road blockers do we have before 1.0?
> >> Please note that there is always something one can do better - but this
> should not hinder us from releasing until something is really broken.
> >> Also the documentation is *not* a show stopper - it is perfectly fine
> to ship this later as our CMS is completely asynchronous.
> >>
> >>
> >> So what BLOCKERS do you see before I go and press the release button?
> >> Like to do that on Wednesday...
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>
> >> On Sunday, 16 February 2014, 23:14, Ove Ranheim 
> wrote:
> >>
> >> That's reasonable enough.
> >>>
> >>>
> >>>On 16. feb. 2014, at 23:02, Jason Porter 
> wrote:
> >>>
>  Probably because we've become busy with some other projects and
> priorities :(--
>  Sent from Mailbox for iPhone
> 
>  On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim 
> wrote:
> 
> > The commit graph shows too few committers.. and I appreciate your
> work!
> > I also notice too few Redhat/JBoss Weld/Seam committers left on the
> project. How come?
> > /ove
> > On 16. feb. 2014, at 22:10, Gerhard Petracek <
> gerhard.petra...@gmail.com> wrote:
> >> hi ove,
> >>
> >> i was only talking about the commits.
> >>
> >> regards,
> >> gerhard
> >>
> >> http://www.irian.at
> >>
> >> Your JSF/JavaEE powerhouse -
> >> JavaEE Consulting, Development and
> >> Courses in English and German
> >>
> >> Professional Support for Apache MyFaces
> >>
> >>
> >>
> >> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko <
> andraschko.tho...@gmail.com>:
> >>
> >>> +1 Ove
> >>> We are really late for an 0.6. I would release 0.6 this/next month
> and
> >>> after that, lets finish 1.0.
> >>> We should fix all open issues and finish the documentation!
> >>>
> >>>
> >>>
> >
> >
> >
>


Re: [Discuss] Data Module - Transactional Repositories

2014-02-17 Thread Thomas Hug
Ok with 3) you basically mean we don't rely on @Transactional, but rather
on the TransactionStrategy?
Sounds fine too. Would require some tricks to bridge from InvocationHandler
to InvocationContext, and then again having the TXStrategy pick up the
repository EM (haven't checked yet what that means in detail).



On Mon, Feb 17, 2014 at 8:49 AM, Romain Manni-Bucau
wrote:

> Hello,
>
> 1) a producer + qualifier would be easier on entitymanager side so I'd
> propagate it to the repository.
> 2) em in transactionscoped should be useless since if you produce the
> em you are already in a scope so already cached by CDI itself, no?
> 3) we don't really need interceptors since we can invoke it ourself in
> the handler (for me CRUD + transaction need to fit together so not
> shocking to keep them linked. JPA is linked to JTA BTW ;)), it would
> even be important to be able to avoid nested transactions by default
> (I don't recall what does default @Tx impl). Where I'm less confident
> is with current @Tx impl we can't force a new transaction so we
> doesn't cover all needed case. But should be enough to start.
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2014-02-17 7:51 GMT+01:00 Thomas Hug :
> > Yes would be great to get this sorted out soon. Looks like 2) is the
> > preferred way to go, which would also mean some work on the JPA module.
> >
> > - Any thoughts on how the Data EntityManagerResolver fits in the picture
> > there?
> > - Also [1] seems rather nasty in this context. Is there a better way
> > dealing with it than just trying to detect it has not been picked up and
> > then call the TransactionStrategy by ourself?
> >
> > [1] https://issues.apache.org/jira/browse/DELTASPIKE-419
> >
> >
> > On Sun, Feb 16, 2014 at 10:10 PM, Romain Manni-Bucau
> > wrote:
> >
> >> Hi Thomas,
> >>
> >> would be great to get it in 0.6, any idea if it would be possible? I
> >> should be able to help once decided and if needed.
> >> Romain Manni-Bucau
> >> Twitter: @rmannibucau
> >> Blog: http://rmannibucau.wordpress.com/
> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> Github: https://github.com/rmannibucau
> >>
> >>
> >>
> >> 2014-02-12 12:13 GMT+01:00 Romain Manni-Bucau :
> >> > While it works with JTA it is ok for me, I think it should be
> >> > compatible with our @Transactional and EE 7 one. I think reusing
> >> > @Transactional is important in declaration (on method) so maybe the
> >> > way to go.
> >> > Romain Manni-Bucau
> >> > Twitter: @rmannibucau
> >> > Blog: http://rmannibucau.wordpress.com/
> >> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> > Github: https://github.com/rmannibucau
> >> >
> >> >
> >> >
> >> > 2014-02-12 11:40 GMT+01:00 Jean-Louis MONTEIRO :
> >> >> +1 for 2/ as well.
> >> >> That is right from an end user experience point of view.
> >> >> Also right to reuse and put in common some parts of JPA and Data
> module
> >> >> Closer to Java EE 7 @Transactional approach
> >> >>
> >> >> JLouis
> >> >>
> >> >>
> >> >>
> >> >> 2014-02-12 11:20 GMT+01:00 Thomas Hug :
> >> >>
> >> >>> Not sure where we stopped in the discussion but AFAIR we had two
> >> approaches
> >> >>> here:
> >> >>>
> >> >>> 1) An automatic internal tx handling if one is needed by the query,
> >> >>> probably similar to what the JPA module does in the
> >> >>> EnvironmentAwareTransactionStrategy. Could eventually be controlled
> by
> >> an
> >> >>> attribute on @Repository defaulting to active.
> >> >>>
> >> >>> 2) Integration with @Transactional of the JPA module. For this we'd
> >> also
> >> >>> have to look at:
> >> >>> - Aligning EntityManager resolution between the two modules. That
> could
> >> >>> include moving the EntityManagerResolver into the JPA module API and
> >> >>> eventually removing the current qualifier-based resolution. That one
> >> would
> >> >>> need some more thoughts to get out something consistent.
> >> >>> -  Eventually exposing the resolved EM @TransactionScoped so the
> >> repository
> >> >>> can easily access it.
> >> >>> - Deal with PartialBeans not picking up interceptors - AFAIR this
> was
> >> >>> reported to be an issue on some Weld versions?
> >> >>>
> >> >>> +1 on 2) - makes for me much more sense from a user perspective.
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Jean-Louis
> >>
>


Re: [DISCUSS] next release version? 0.6 or 1.0?

2014-02-17 Thread Nicklas Karlsson
+1 for this

Documentation and examples are never complete but with that in mind one
should not stop improving them "because they are never complete anyway" ;-)


On Mon, Feb 17, 2014 at 11:10 AM, Mark Struberg  wrote:

> Oki, I can help a bit with ViewAccessScoped. Romain and Thomas, please fix
> the Tx stuff.
>
> In that case I'd say we gonna ship a 0.6 and then in 3 weeks move to 1.0.
>
> wdyt?
>
>
> LieGrue,
> strub
>
>
>
>
>
> On Monday, 17 February 2014, 10:06, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
>
> Hi
> >
> >
> >can we wait 1 or 2 weeks (no more) to see if we can sort out @Repo/@Tx
> >stuff? Basically I'm waiting after it for months and this is blocker
> >to be used ATM.
> >Romain Manni-Bucau
> >Twitter: @rmannibucau
> >Blog: http://rmannibucau.wordpress.com/
> >LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >Github: https://github.com/rmannibucau
> >
> >
> >
> >
> >2014-02-17 9:57 GMT+01:00 Mark Struberg :
> >> back 2 the topic, please!
> >>
> >> I'd say we should approach 1.0 NOW.
> >>
> >> DeltaSpike core and a few other modules is really rock solid already
> since a year or so. It is also used heavily in production already.
> >> There will always be some modules which are not so perfectly mature at
> times. E.g. if we will add a new module.
> >>
> >> Thus I already did propose a methology which would fix this shortcoming:
> >> We might introduce an 'ample page' which contains the status of each
> project - stable / ready /in progress
> >>
> >> You know, the traffic light thingy where green means the module (e.g.
> deltaspike-core) is stable and the API will not change or we will at least
> be backward compatible unless we do a major new version.
> >> Orange means that the module has been tested and looks good. Whereas
> red means that the api might change still.
> >>
> >> What road blockers do we have before 1.0?
> >> Please note that there is always something one can do better - but this
> should not hinder us from releasing until something is really broken.
> >> Also the documentation is *not* a show stopper - it is perfectly fine
> to ship this later as our CMS is completely asynchronous.
> >>
> >>
> >> So what BLOCKERS do you see before I go and press the release button?
> >> Like to do that on Wednesday...
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>
> >> On Sunday, 16 February 2014, 23:14, Ove Ranheim 
> wrote:
> >>
> >> That's reasonable enough.
> >>>
> >>>
> >>>On 16. feb. 2014, at 23:02, Jason Porter 
> wrote:
> >>>
>  Probably because we've become busy with some other projects and
> priorities :(--
>  Sent from Mailbox for iPhone
> 
>  On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim 
> wrote:
> 
> > The commit graph shows too few committers.. and I appreciate your
> work!
> > I also notice too few Redhat/JBoss Weld/Seam committers left on the
> project. How come?
> > /ove
> > On 16. feb. 2014, at 22:10, Gerhard Petracek <
> gerhard.petra...@gmail.com> wrote:
> >> hi ove,
> >>
> >> i was only talking about the commits.
> >>
> >> regards,
> >> gerhard
> >>
> >> http://www.irian.at
> >>
> >> Your JSF/JavaEE powerhouse -
> >> JavaEE Consulting, Development and
> >> Courses in English and German
> >>
> >> Professional Support for Apache MyFaces
> >>
> >>
> >>
> >> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko <
> andraschko.tho...@gmail.com>:
> >>
> >>> +1 Ove
> >>> We are really late for an 0.6. I would release 0.6 this/next month
> and
> >>> after that, lets finish 1.0.
> >>> We should fix all open issues and finish the documentation!
> >>>
> >>>
> >>>
> >
> >
> >
>



-- 
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina


Re: [DISCUSS] next release version? 0.6 or 1.0?

2014-02-17 Thread Mark Struberg
Oki, I can help a bit with ViewAccessScoped. Romain and Thomas, please fix the 
Tx stuff.

In that case I'd say we gonna ship a 0.6 and then in 3 weeks move to 1.0.

wdyt?


LieGrue,
strub





On Monday, 17 February 2014, 10:06, Romain Manni-Bucau  
wrote:
 
Hi
>
>
>can we wait 1 or 2 weeks (no more) to see if we can sort out @Repo/@Tx
>stuff? Basically I'm waiting after it for months and this is blocker
>to be used ATM.
>Romain Manni-Bucau
>Twitter: @rmannibucau
>Blog: http://rmannibucau.wordpress.com/
>LinkedIn: http://fr.linkedin.com/in/rmannibucau
>Github: https://github.com/rmannibucau
>
>
>
>
>2014-02-17 9:57 GMT+01:00 Mark Struberg :
>> back 2 the topic, please!
>>
>> I'd say we should approach 1.0 NOW.
>>
>> DeltaSpike core and a few other modules is really rock solid already since a 
>> year or so. It is also used heavily in production already.
>> There will always be some modules which are not so perfectly mature at 
>> times. E.g. if we will add a new module.
>>
>> Thus I already did propose a methology which would fix this shortcoming:
>> We might introduce an 'ample page' which contains the status of each project 
>> - stable / ready /in progress
>>
>> You know, the traffic light thingy where green means the module (e.g. 
>> deltaspike-core) is stable and the API will not change or we will at least 
>> be backward compatible unless we do a major new version.
>> Orange means that the module has been tested and looks good. Whereas red 
>> means that the api might change still.
>>
>> What road blockers do we have before 1.0?
>> Please note that there is always something one can do better - but this 
>> should not hinder us from releasing until something is really broken.
>> Also the documentation is *not* a show stopper - it is perfectly fine to 
>> ship this later as our CMS is completely asynchronous.
>>
>>
>> So what BLOCKERS do you see before I go and press the release button?
>> Like to do that on Wednesday...
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> On Sunday, 16 February 2014, 23:14, Ove Ranheim  wrote:
>>
>> That's reasonable enough.
>>>
>>>
>>>On 16. feb. 2014, at 23:02, Jason Porter  wrote:
>>>
 Probably because we've become busy with some other projects and priorities 
 :(--
 Sent from Mailbox for iPhone

 On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim  wrote:

> The commit graph shows too few committers.. and I appreciate your work!
> I also notice too few Redhat/JBoss Weld/Seam committers left on the 
> project. How come?
> /ove
> On 16. feb. 2014, at 22:10, Gerhard Petracek  
> wrote:
>> hi ove,
>>
>> i was only talking about the commits.
>>
>> regards,
>> gerhard
>>
>> http://www.irian.at
>>
>> Your JSF/JavaEE powerhouse -
>> JavaEE Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>>
>>
>> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko 
>> :
>>
>>> +1 Ove
>>> We are really late for an 0.6. I would release 0.6 this/next month and
>>> after that, lets finish 1.0.
>>> We should fix all open issues and finish the documentation!
>>>
>>>
>>>
>
>
>

Re: [DISCUSS] next release version? 0.6 or 1.0?

2014-02-17 Thread Romain Manni-Bucau
Hi


can we wait 1 or 2 weeks (no more) to see if we can sort out @Repo/@Tx
stuff? Basically I'm waiting after it for months and this is blocker
to be used ATM.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-02-17 9:57 GMT+01:00 Mark Struberg :
> back 2 the topic, please!
>
> I'd say we should approach 1.0 NOW.
>
> DeltaSpike core and a few other modules is really rock solid already since a 
> year or so. It is also used heavily in production already.
> There will always be some modules which are not so perfectly mature at times. 
> E.g. if we will add a new module.
>
> Thus I already did propose a methology which would fix this shortcoming:
> We might introduce an 'ample page' which contains the status of each project 
> - stable / ready /in progress
>
> You know, the traffic light thingy where green means the module (e.g. 
> deltaspike-core) is stable and the API will not change or we will at least be 
> backward compatible unless we do a major new version.
> Orange means that the module has been tested and looks good. Whereas red 
> means that the api might change still.
>
> What road blockers do we have before 1.0?
> Please note that there is always something one can do better - but this 
> should not hinder us from releasing until something is really broken.
> Also the documentation is *not* a show stopper - it is perfectly fine to ship 
> this later as our CMS is completely asynchronous.
>
>
> So what BLOCKERS do you see before I go and press the release button?
> Like to do that on Wednesday...
>
>
> LieGrue,
> strub
>
>
>
>
> On Sunday, 16 February 2014, 23:14, Ove Ranheim  wrote:
>
> That's reasonable enough.
>>
>>
>>On 16. feb. 2014, at 23:02, Jason Porter  wrote:
>>
>>> Probably because we've become busy with some other projects and priorities 
>>> :(--
>>> Sent from Mailbox for iPhone
>>>
>>> On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim  wrote:
>>>
 The commit graph shows too few committers.. and I appreciate your work!
 I also notice too few Redhat/JBoss Weld/Seam committers left on the 
 project. How come?
 /ove
 On 16. feb. 2014, at 22:10, Gerhard Petracek  
 wrote:
> hi ove,
>
> i was only talking about the commits.
>
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF/JavaEE powerhouse -
> JavaEE Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko 
> :
>
>> +1 Ove
>> We are really late for an 0.6. I would release 0.6 this/next month and
>> after that, lets finish 1.0.
>> We should fix all open issues and finish the documentation!
>>
>>
>>


Re: [DISCUSS] next release version? 0.6 or 1.0?

2014-02-17 Thread Thomas Andraschko
IMHO ViewAccessScoped is a showstopper for the JSF users. Many people used
CODI just because of it!

But to be honest, if i will do it, it takes propably 2-4 weeks. I have
currently only time at weekend... and i'm note sure if i know all details
of the implementation ;)


2014-02-17 9:57 GMT+01:00 Mark Struberg :

> back 2 the topic, please!
>
> I'd say we should approach 1.0 NOW.
>
> DeltaSpike core and a few other modules is really rock solid already since
> a year or so. It is also used heavily in production already.
> There will always be some modules which are not so perfectly mature at
> times. E.g. if we will add a new module.
>
> Thus I already did propose a methology which would fix this shortcoming:
> We might introduce an 'ample page' which contains the status of each
> project - stable / ready /in progress
>
> You know, the traffic light thingy where green means the module (e.g.
> deltaspike-core) is stable and the API will not change or we will at least
> be backward compatible unless we do a major new version.
> Orange means that the module has been tested and looks good. Whereas red
> means that the api might change still.
>
> What road blockers do we have before 1.0?
> Please note that there is always something one can do better - but this
> should not hinder us from releasing until something is really broken.
> Also the documentation is *not* a show stopper - it is perfectly fine to
> ship this later as our CMS is completely asynchronous.
>
>
> So what BLOCKERS do you see before I go and press the release button?
> Like to do that on Wednesday...
>
>
> LieGrue,
> strub
>
>
>
>
> On Sunday, 16 February 2014, 23:14, Ove Ranheim 
> wrote:
>
> That's reasonable enough.
> >
> >
> >On 16. feb. 2014, at 23:02, Jason Porter  wrote:
> >
> >> Probably because we've become busy with some other projects and
> priorities :(--
> >> Sent from Mailbox for iPhone
> >>
> >> On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim 
> wrote:
> >>
> >>> The commit graph shows too few committers.. and I appreciate your work!
> >>> I also notice too few Redhat/JBoss Weld/Seam committers left on the
> project. How come?
> >>> /ove
> >>> On 16. feb. 2014, at 22:10, Gerhard Petracek <
> gerhard.petra...@gmail.com> wrote:
>  hi ove,
> 
>  i was only talking about the commits.
> 
>  regards,
>  gerhard
> 
>  http://www.irian.at
> 
>  Your JSF/JavaEE powerhouse -
>  JavaEE Consulting, Development and
>  Courses in English and German
> 
>  Professional Support for Apache MyFaces
> 
> 
> 
>  2014-02-16 22:07 GMT+01:00 Thomas Andraschko <
> andraschko.tho...@gmail.com>:
> 
> > +1 Ove
> > We are really late for an 0.6. I would release 0.6 this/next month
> and
> > after that, lets finish 1.0.
> > We should fix all open issues and finish the documentation!
> >
> >
> >
>


Re: [DISCUSS] next release version? 0.6 or 1.0?

2014-02-17 Thread Mark Struberg
back 2 the topic, please!

I'd say we should approach 1.0 NOW. 

DeltaSpike core and a few other modules is really rock solid already since a 
year or so. It is also used heavily in production already.
There will always be some modules which are not so perfectly mature at times. 
E.g. if we will add a new module. 

Thus I already did propose a methology which would fix this shortcoming: 
We might introduce an 'ample page' which contains the status of each project - 
stable / ready /in progress

You know, the traffic light thingy where green means the module (e.g. 
deltaspike-core) is stable and the API will not change or we will at least be 
backward compatible unless we do a major new version.
Orange means that the module has been tested and looks good. Whereas red means 
that the api might change still.

What road blockers do we have before 1.0?
Please note that there is always something one can do better - but this should 
not hinder us from releasing until something is really broken.
Also the documentation is *not* a show stopper - it is perfectly fine to ship 
this later as our CMS is completely asynchronous.


So what BLOCKERS do you see before I go and press the release button?
Like to do that on Wednesday...


LieGrue,
strub




On Sunday, 16 February 2014, 23:14, Ove Ranheim  wrote:
 
That’s reasonable enough.
>
>
>On 16. feb. 2014, at 23:02, Jason Porter  wrote:
>
>> Probably because we've become busy with some other projects and priorities 
>> :(—
>> Sent from Mailbox for iPhone
>> 
>> On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim  wrote:
>> 
>>> The commit graph shows too few committers.. and I appreciate your work! 
>>> I also notice too few Redhat/JBoss Weld/Seam committers left on the 
>>> project. How come?
>>> /ove
>>> On 16. feb. 2014, at 22:10, Gerhard Petracek  
>>> wrote:
 hi ove,
 
 i was only talking about the commits.
 
 regards,
 gerhard
 
 http://www.irian.at
 
 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 
 2014-02-16 22:07 GMT+01:00 Thomas Andraschko :
 
> +1 Ove
> We are really late for an 0.6. I would release 0.6 this/next month and
> after that, lets finish 1.0.
> We should fix all open issues and finish the documentation!
>
>
>