Re: Servlet Module - Do we really need @Web?
@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
[
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
[ 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
[ 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?
@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?
@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?
+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?
@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
[ 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
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
[ 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?
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?
+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?
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?
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?
+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?
+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
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?
+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?
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?
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?
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?
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! > > >
