Re: [DISCUSS] deltaspike-0.5 features

[Romain Manni-Bucau]

Cdi query stuff would be great too
Le 1 juin 2013 13:12, "Mark Struberg"  a écrit :

> Yes should mainly be a bugfix release with only a few new features.
>
> LieGrue,
> strub
>
>
>
>
> >
> > From: John D. Ament 
> >To: dev@deltaspike.apache.org; Mark Struberg 
> >Cc: deltaspike 
> >Sent: Saturday, 1 June 2013, 13:07
> >Subject: Re: [DISCUSS] deltaspike-0.5 features
> >
> >
> >
> >Mark,
> >
> >
> >A little aggressive based on how long it took to get 0.4?  Should this be
> a small release then?
> >
> >
> >I'd like to add some level of BeanValidation support in this release,
> looks like the CODI and Seam features are pretty similar; so adding support
> for a ConstraintValidatorFactory that creates injectable references would
> be a good one (I was about to kick off that email).
> >
> >
> >John
> >
> >
> >
> >On Sat, Jun 1, 2013 at 7:00 AM, Mark Struberg  wrote:
> >
> >Hi!
> >>
> >>It's time to go for planing ds-0.5.
> >>I'd say the release should be pretty small this time. Mostly bug fixes
> and a few minor enhancements. And max 1 or 2 bigger bullet features.
> >>The goal is to release ds-0.5 end of this month.
> >>
> >>A few things on the list as I remember so far:
> >>
> >>* Finish graduation and apply latest changes to our Docs.
> >>* Servlet module. Please add JIRAs which feature you like to see in this
> module
> >>
> >>* Improve the JSF module. We still miss a few features from CODI and
> seam-faces
> >> . improve ClientWindow handling
> >> . improve the typesafe navigation
> >> . add @ConfigurationScoped and @ViewAccessScoped
> >>
> >>
> >>* Improve the configuration
> >> . brainstorming about configuration 'categories' as requested a few
> times already
> >> . ProjectStage and/or property specific configuration
> >>
> >>
> >>This DISCUSS will be closed in 72h. New feature requests after that time
> will be handled in deltaspike-0.6 (unless they are blockers).
> >>
> >>The timeframe I would suggest:
> >>
> >>* Implement new features during 2013-06-12
> >>* Bugfixing and documentation until 2013-06-19
> >>* start with the release on 2013-06-23
> >>
> >>
> >>Any objection, ideas, feedback?
> >>
> >>
> >>txs and LieGrue,
> >>strub
> >>
> >>
> >
> >
> >
>

Re: DISCUSS DeltaSpike-332

[Romain Manni-Bucau]

Idem, not blocking IMO and bval 1.1 is coming so would be useless soon
Le 1 juin 2013 15:56, "Gerhard Petracek"  a
écrit :

> hi john,
>
> codi doesn't do auto registration. you need @Advanced to enable it.
>
> if you aren't allowed to use bv 1.1 right know, you can just use
> BeanProvider manually (usually there are just few constraint-validators
> which need it at all)
> or keep what your are using now in parallel or just copy those few classes
> to your ee6 (only) project. at least in case of codi they are quite
> independent (and in most cases just simple wrappers). -> -1 for adding it.
>
> regards,
> gerhard
>
>
>
> 2013/6/1 John D. Ament 
>
> > Hi All
> >
> > I wanted to begin introducing some level of BeanValidation Support.  The
> > main goal that I have is to be able to create CDI aware constraint
> > validators, let's say you want to validate @NonExistentEmail then you
> > should be able to run a query against your DB using your CDI services and
> > determine if the given email is already present or not.
> >
> > To do this, both Seam3 and CODI introduced a CDI aware ConstraintFactory.
> >  When it creates an instance the instance is a CDI object, so it has full
> > access to @Inject fields.  I'd like to bring this type of functionality
> > over to DS.
> >
> > The point where the two diverge is that CODI does an auto registration
> > whereas Seam3 does a registration via validation.xml.  As far as I know,
> > CDI already allows the injection of Validator and ValidatorFactory
> (though
> > the OWB guys can tell me if they disagree).
> >
> > Please let me know if anyone has concerns with adding this.  Yes, I
> realize
> > that this functionality is in bean val 1.1, but not everyone can upgrade
> to
> > bean val 1.1 yet.
> >
> > John
> >
>

Re: DISCUSS DeltaSpike-332

[Romain Manni-Bucau]

; >>  > @thomas:
> >> > >>  > if you are allowed to use bv 1.1, it should be possible (via
> >> > >>  > default-provider + the corresponding classloading-config for the
> >> > > server
> >> > >>  you
> >> > >>  > are using).
> >> > >>  > if you are not allowed to use it, have a look at my initial
> >> comments.
> >> > >>  >
> >> > >>  > @hantsy:
> >> > >>  > imo that's exotic anyway and you could still use BeanProvider.
> >> > >>  >
> >> > >>  > regards,
> >> > >>  > gerhard
> >> > >>  >
> >> > >>  >
> >> > >>  >
> >> > >>  > 2013/6/1 hantsy 
> >> > >>  >
> >> > >>  > > I noticed JSF 2.2 canceled the DI in JSF components in final
> >> > > Specs,
> >> > >>  only
> >> > >>  > > support in JSF backend beans.
> >> > >>  > >
> >> > >>  > > MyFaces CODI provides @Advanced for DI in non contextual
> >> > > object...it is
> >> > >>  > > still useful for JSF 2.2...but I do not want to add this to
> >> > > enable
> >> > >>  > > injection on JSF validator, converter, etc.
> >> > >>  > >
> >> > >>  > > Hantsy
> >> > >>  > > On 6/1/2013 22:11, Thomas Andraschko wrote:
> >> > >>  > > > Also if BV 1.1 is coming soon, many customers can't
> >> > > upgrade to BV 1.1
> >> > >>  > or
> >> > >>  > > > JavaEE 7 the next 1-2 years.
> >> > >>  > > > So IMO it would be a great feature which shoudl be disabled
> >> > > per
> >> > >>  > default.
> >> > >>  > > >
> >> > >>  > > >
> >> > >>  > > > 2013/6/1 Romain Manni-Bucau 
> >> > >>  > > >
> >> > >>  > > >> Idem, not blocking IMO and bval 1.1 is coming so would
> >> > > be useless
> >> > >>  soon
> >> > >>  > > >> Le 1 juin 2013 15:56, "Gerhard Petracek" <
> >> > >>  gerhard.petra...@gmail.com>
> >> > >>  > a
> >> > >>  > > >> écrit :
> >> > >>  > > >>
> >> > >>  > > >>> hi john,
> >> > >>  > > >>>
> >> > >>  > > >>> codi doesn't do auto registration. you need
> >> > > @Advanced to enable it.
> >> > >>  > > >>>
> >> > >>  > > >>> if you aren't allowed to use bv 1.1 right know,
> >> > > you can just use
> >> > >>  > > >>> BeanProvider manually (usually there are just few
> >> > >>  > constraint-validators
> >> > >>  > > >>> which need it at all)
> >> > >>  > > >>> or keep what your are using now in parallel or just
> >> > > copy those few
> >> > >>  > > >> classes
> >> > >>  > > >>> to your ee6 (only) project. at least in case of codi
> >> > > they are quite
> >> > >>  > > >>> independent (and in most cases just simple
> >> > > wrappers). -> -1 for
> >> > >>  > adding
> >> > >>  > > >> it.
> >> > >>  > > >>> regards,
> >> > >>  > > >>> gerhard
> >> > >>  > > >>>
> >> > >>  > > >>>
> >> > >>  > > >>>
> >> > >>  > > >>> 2013/6/1 John D. Ament
> >> > > 
> >> > >>  > > >>>
> >> > >>  > > >>>> Hi All
> >> > >>  > > >>>>
> >> > >>  > > >>>> I wanted to begin introducing some level of
> >> > > BeanValidation
> >> > >>  Support.
> >> > >>  > > >>  The
> >> > >>  > > >>>> main goal that I have is to be able to create
> >> > > CDI aware constraint
> >> > >>  > > >>>> validators, let's say you want to validate
> >> > > @NonExistentEmail then
> >> > >>  > you
> >> > >>  > > >>>> should be able to run a query against your DB
> >> > > using your CDI
> >> > >>  > services
> >> > >>  > > >> and
> >> > >>  > > >>>> determine if the given email is already present
> >> > > or not.
> >> > >>  > > >>>>
> >> > >>  > > >>>> To do this, both Seam3 and CODI introduced a CDI
> >> > > aware
> >> > >>  > > >> ConstraintFactory.
> >> > >>  > > >>>>  When it creates an instance the instance is a
> >> > > CDI object, so it
> >> > >>  has
> >> > >>  > > >> full
> >> > >>  > > >>>> access to @Inject fields.  I'd like to bring
> >> > > this type of
> >> > >>  > > functionality
> >> > >>  > > >>>> over to DS.
> >> > >>  > > >>>>
> >> > >>  > > >>>> The point where the two diverge is that CODI
> >> > > does an auto
> >> > >>  > registration
> >> > >>  > > >>>> whereas Seam3 does a registration via
> >> > > validation.xml.  As far as I
> >> > >>  > > >> know,
> >> > >>  > > >>>> CDI already allows the injection of Validator
> >> > > and ValidatorFactory
> >> > >>  > > >>> (though
> >> > >>  > > >>>> the OWB guys can tell me if they disagree).
> >> > >>  > > >>>>
> >> > >>  > > >>>> Please let me know if anyone has concerns with
> >> > > adding this.  Yes,
> >> > >>  I
> >> > >>  > > >>> realize
> >> > >>  > > >>>> that this functionality is in bean val 1.1, but
> >> > > not everyone can
> >> > >>  > > >> upgrade
> >> > >>  > > >>> to
> >> > >>  > > >>>> bean val 1.1 yet.
> >> > >>  > > >>>>
> >> > >>  > > >>>> John
> >> > >>  > > >>>>
> >> > >>  > >
> >> > >>  > > --
> >> > >>  > > Hantsy Bai
> >> > >>  > > Blog:http://hantsy.blogspot.com
> >> > >>  > > LinkedIN:http://www.linkedin.com/in/hantsy
> >> > >>  > >
> >> > >>  >
> >> > >>
> >> > >
> >> >
> >>

Jsf page and config?

[Romain Manni-Bucau]

Hi

We support a nice jsf navigation (strong typed) but i wonder if we shouldnt
look in our config (config resolver) if the page name is not overrided. It
would allow to use templates easily.

Wdyt?

If we do it we need to orefix the properties as for global alternatives.

Re: DISCUSS DeltaSpike-332

[Romain Manni-Bucau]

Weird if that s true but in such a case app will be constrained too i think
Le 2 juin 2013 10:25, "Mark Struberg"  a écrit :

>
>
> Pretty often you are not even allowed to change those libs for production.
> Sometimes because of legal constructs (ever looked at the Oracle license
> for WebLogic?) and sometimes because of company reasons.
>
> Thus I'm +1 for adding it as _optional_ feature.
>
> LieGrue,
> strub
>
>
> >
> > From: Romain Manni-Bucau 
> >To: dev@deltaspike.apache.org
> >Sent: Sunday, 2 June 2013, 8:57
> >Subject: Re: DISCUSS DeltaSpike-332
> >
> >
> >As said before, if using the javaee7 lib is easy in javaee6 no need of any
> >glue. That should be the case for bval, jpa...
> >Le 2 juin 2013 03:26, "Jason Porter"  a écrit :
> >
> >> FWIW I'm +1 for the BeanVal stuff and keeping it disabled by default.
> Just
> >> because Java EE 7 is soon to be released doesn't mean that people will
> >> migrate to it over night, as has already been said. I'm sure there are
> >> quite a few large corporations still on Java EE 5 and probably will be
> for
> >> a while.
> >>
> >>
> >> If the coding is minimal to bring some Java EE 7 features to Java EE 6
> >> via DeltaSpike, I don't see a reason not to do this.
> >>
> >> —
> >> Sent from Mailbox for iPhone
> >>
> >> On Sat, Jun 1, 2013 at 1:55 PM, Gerhard Petracek
> >>  wrote:
> >>
> >> > hi thomas,
> >> > no - we don't have @Advanced.
> >> > (-1 for adding it and therefore -1 for adding parts which would need
> >> such a
> >> > qualifier.)
> >> > regards,
> >> > gerhard
> >> > 2013/6/1 Thomas Andraschko 
> >> >> Jep, there will be many EE6 users out there the next 1-3 years.
> >> >>
> >> >> there are also other possible features:
> >> >> - injection in other BV artifacts - e.g. MessageInterpolator
> >> >> - method validation (if possible with 1.0 specs)
> >> >>
> >> >> AFAIK all this features will be available in BV 1.1, so it would be
> >> enough
> >> >> to create a BV1.0 module.
> >> >>
> >> >> Is there already something available like @Advanded in DS?
> >> >> I personally don't like it. Do we really save performance?
> >> >> Probably the best solution is to just activate injection if the
> module
> >> is
> >> >> included.
> >> >>
> >> >>
> >> >> Thats the same with JSF 2.2 ViewScoped.
> >> >> How will it be handled in DS?
> >> >>
> >> >>
> >> >> 2013/6/1 Mark Struberg 
> >> >>
> >> >> > As others said, in an EE-6 container you cannot just exchange the
> bean
> >> >> > validation provider easily.
> >> >> >
> >> >> >
> >> >> > Yes, it's already possible to use the BeanProvider to achieve this
> >> goal.
> >> >> > But it's also nice if that would work out of the box.
> >> >> > An important criteria is of course that it must also work when bean
> >> >> > validation-1.1 is available which will do the injection itself.
> >> >> >
> >> >> >
> >> >> > Imo it's mostly a question about what else we like to add into this
> >> >> module.
> >> >> >
> >> >> > LieGrue,
> >> >> > strub
> >> >> >
> >> >> >
> >> >> >
> >> >> > - Original Message -
> >> >> > > From: Gerhard Petracek 
> >> >> > > To: dev@deltaspike.apache.org
> >> >> > > Cc:
> >> >> > > Sent: Saturday, 1 June 2013, 20:25
> >> >> > > Subject: Re: DISCUSS DeltaSpike-332
> >> >> > >
> >> >> > > hi thomas,
> >> >> > >
> >> >> > > yes, because we based everything on the jsf 1.2 api.
> >> >> > > (~nothing from the jsf2+ api was needed to provide what you get
> with
> >> >> > codi.)
> >> >> > >
> >> >> > > @ "...in each validator...":
> >> >> > > projects usually don't have that many co

Re: DISCUSS DeltaSpike-332

[Romain Manni-Bucau]

Hmm, thinking of it we should consider how hard it is to dev and maintain
and if it is the same code as the new version of the lib. If so thats not
relevant IMO, if easy and small enough it could be added IMHO
Le 2 juin 2013 13:08, "John D. Ament"  a écrit :

> Definitely.  When you're a consultant, you typically don't tell what 3PL's
> you're using (just dealt with this recently, found some GPL in our
> product... not fun).  Adding in a 3PL that is apache licensed is typically
> ok.  Upgrading a core app server lib without real reason for it is a pain.
>  Right now, I think JBoss ans TomEE do it quite easily but the big boys
> (WebLogic & WebSphere) it's still a bit of a pain.  Sometimes your app is
> running on shared binaries, so then both apps need to be updated and you
> can't embed the library update for whatever class loading problem comes up.
>
> Anyways, thanks Mark & Jason for support on this.
>
> I agree w/ Gerhard, we need a general strategy for introducing stuff added
> by later EE specs.  It seems like we're inconsistent WRT this topic; e.g.
> JSF features were added, Servlet features are getting added, but JMS and
> BeanVal seemed to cause disdain in the group (not sure if it's who proposed
> it or the lack of use of these specs).
>
> John
>
>
> On Sun, Jun 2, 2013 at 5:03 AM, Romain Manni-Bucau  >wrote:
>
> > Weird if that s true but in such a case app will be constrained too i
> think
> > Le 2 juin 2013 10:25, "Mark Struberg"  a écrit :
> >
> > >
> > >
> > > Pretty often you are not even allowed to change those libs for
> > production.
> > > Sometimes because of legal constructs (ever looked at the Oracle
> license
> > > for WebLogic?) and sometimes because of company reasons.
> > >
> > > Thus I'm +1 for adding it as _optional_ feature.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > > >
> > > > From: Romain Manni-Bucau 
> > > >To: dev@deltaspike.apache.org
> > > >Sent: Sunday, 2 June 2013, 8:57
> > > >Subject: Re: DISCUSS DeltaSpike-332
> > > >
> > > >
> > > >As said before, if using the javaee7 lib is easy in javaee6 no need of
> > any
> > > >glue. That should be the case for bval, jpa...
> > > >Le 2 juin 2013 03:26, "Jason Porter"  a
> écrit
> > :
> > > >
> > > >> FWIW I'm +1 for the BeanVal stuff and keeping it disabled by
> default.
> > > Just
> > > >> because Java EE 7 is soon to be released doesn't mean that people
> will
> > > >> migrate to it over night, as has already been said. I'm sure there
> are
> > > >> quite a few large corporations still on Java EE 5 and probably will
> be
> > > for
> > > >> a while.
> > > >>
> > > >>
> > > >> If the coding is minimal to bring some Java EE 7 features to Java
> EE 6
> > > >> via DeltaSpike, I don't see a reason not to do this.
> > > >>
> > > >> —
> > > >> Sent from Mailbox for iPhone
> > > >>
> > > >> On Sat, Jun 1, 2013 at 1:55 PM, Gerhard Petracek
> > > >>  wrote:
> > > >>
> > > >> > hi thomas,
> > > >> > no - we don't have @Advanced.
> > > >> > (-1 for adding it and therefore -1 for adding parts which would
> need
> > > >> such a
> > > >> > qualifier.)
> > > >> > regards,
> > > >> > gerhard
> > > >> > 2013/6/1 Thomas Andraschko 
> > > >> >> Jep, there will be many EE6 users out there the next 1-3 years.
> > > >> >>
> > > >> >> there are also other possible features:
> > > >> >> - injection in other BV artifacts - e.g. MessageInterpolator
> > > >> >> - method validation (if possible with 1.0 specs)
> > > >> >>
> > > >> >> AFAIK all this features will be available in BV 1.1, so it would
> be
> > > >> enough
> > > >> >> to create a BV1.0 module.
> > > >> >>
> > > >> >> Is there already something available like @Advanded in DS?
> > > >> >> I personally don't like it. Do we really save performance?
> > > >> >> Probably the best solution is to just activate injection if the
>

Re: Jsf page and config?

[Romain Manni-Bucau]

Basically i thought allowing to switch basepath but you are right se
already have sthg customizable and usable
Le 2 juin 2013 22:56, "Gerhard Petracek"  a
écrit :

> hi romain,
>
> so far users were very happy with @View#basePath, @View#name and
> @View#extension.
> the only request we saw was about a simple mechanism to change the default
> naming-conventions.
>
> with deltaspike that's possible. just use
>
>   org.apache.deltaspike.jsf.api.config.view.View$DefaultBasePathBuilder
>   and/or
>   org.apache.deltaspike.jsf.api.config.view.View$DefaultFileNameBuilder
>   and/or
>   org.apache.deltaspike.jsf.api.config.view.View$DefaultExtensionBuilder
>
> to configure your own implementation/s.
>
> (if it makes sense, we can provide multiple implementations and users just
> configure whatever they need.)
>
> regards,
> gerhard
>
>
>
> 2013/6/2 Romain Manni-Bucau 
>
> > Hi
> >
> > We support a nice jsf navigation (strong typed) but i wonder if we
> shouldnt
> > look in our config (config resolver) if the page name is not overrided.
> It
> > would allow to use templates easily.
> >
> > Wdyt?
> >
> > If we do it we need to orefix the properties as for global alternatives.
> >
>

Re: ProjectStages in EAR scenarios

[Romain Manni-Bucau]

+1,

ear = 1 app so having 2 project stages would lead to stupid issues IMO

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



2013/6/3 Mark Struberg 

> Hi folks!
>
> The ProjectStageProducer currently uses a static field, thus we only have
> 1 ProjectStage per EAR if DeltaSpike gets shipped in the EARs /lib folder
> (opposed to each WAR).
>
> I personally don't think this is a problem - au contráire, I think it
> makes sense to have all WARs using the same ProjectStage when running on
> the same server.
>
>
> But we still should point this out in our docs and in the JavaDoc.
>
> LieGrue,
> strub
>
>

Re: [DISCUSS] deltaspike-0.5 features

[Romain Manni-Bucau]

If we try to summarize we get:

1) JSF
2) JPA repo
3) servlet module (almost already dev if i understood)

I think it is fine to get these 3 items in 0.5. having only JSF makes DS
too much linked to JSF in terms of comm + cdi query is waiting for months,
we need something now even if quickly written and matching less features
than cdi-query itself.


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



2013/6/3 Mark Struberg 

> it's not about focusing on JSF, it's about focusing on JSF for THIS very
> release.
>
> The main focus of DeltaSpike is btw currently on the core and not on JSF...
>
> LieGrue,
> strub
>
>
>
>
> - Original Message -
> > From: John D. Ament 
> > To: dev@deltaspike.apache.org
> > Cc:
> > Sent: Monday, 3 June 2013, 15:31
> > Subject: Re: [DISCUSS] deltaspike-0.5 features
> >
> > -1 for JSF support being a focus, since it makes it look like DS is a JSF
> > specific library (of course this is only my opinion).
> >
> > This was one of the benefits we had in Seam3, since all modules were at
> the
> > same level (solder being core of course), it didn't prefer any one
> > technology over another.
> >
> >
> > On Mon, Jun 3, 2013 at 9:25 AM, Adrian Gonzalez
> > wrote:
> >
> >>  Sorry, forgot :
> >>  - EAR support.
> >>
> >>  Regards,
> >>  Adrian
> >>
> >>  
> >>   De : Adrian Gonzalez 
> >>  À : "dev@deltaspike.apache.org" 
> >>  Envoyé le : Lundi 3 juin 2013 15h18
> >>  Objet : Re: [DISCUSS] deltaspike-0.5 features
> >>
> >>
> >>  Hello,
> >>
> >>  +1 for me too for :
> >>  - port the CODI Conversation and related scopes to DS (Group etc.)
> >>  - port the ViewAccessScope to DS
> >>
> >>
> >>  Also, didn't looked if JSF and REST bridge for DS Exception Handling
> > where
> >>  available for 0.4.
> >>
> >>  If not it would be good to have them in 0.5.
> >>
> >>  Thanks,
> >>  Adrian
> >>
> >>
> >>  
> >>  De : titou10 titou10 
> >>  À : dev@deltaspike.apache.org
> >>  Envoyé le : Lundi 3 juin 2013 14h43
> >>  Objet : Re: [DISCUSS] deltaspike-0.5 features
> >>
> >>
> >>  For us  DS v0.5 should be focused on the JSF module and particularly
> >>  on porting CODI scopes top get rid of CODI asap. ie:
> >>  - port the CODI Conversation and related scopes to DS (Group etc.)
> >>  - Enhance the WindowScope. (at least
> >>  https://issues.apache.org/jira/browse/DELTASPIKE-374 )
> >>  - port the ViewAccessScope to DS
> >>  - Tie the current JSF CDIfied ViewScope to a new anotation that can be
> >>  used for producers (@PageScope ?) to mimic Seam2 "Page Scope".
> > Current
> >>  JSF @ViewScope annotation can only be set on classes.
> >>  Note that "PageScope" is different from CODI
> > "ViewAccessScope".
> >>  ViewAccessScope live until there are no more referenced by ANY view.
> >>  PageScope object live in one and only one view until the view is
> >>  dismissed..)
> >>  - Clean/update the JSF module documentation
> >>  Thanks
> >>
> >>  2013/6/2 hantsy :
> >>  > I think the programming way to get the CDI bean via BeanProvider
> >>  > manually can be accepted...
> >>  >
> >>  > I would like the following will be added into the Apache DeltaSpike
> as
> >>  > soon as possible.
> >>  >
> >>  > 1. import the CDI query aka the JPA Repository API
> >>  > 2. improve the JSF scopes and Conversation support(nested, @Begin,
> > @End
> >>  > etc which are supported in Seam2), and add other Seam3 Faces
> > facilities,
> >>  > Formvalidation, inputContainer etc.
> >>  > 3. improve Security support, Authentication API for social(oAuth,
> etc)
> >>  > and stateless web service...and allow use multi Authenticators in one
> >>  > project. eg. /rest  REST web service  use stateless
> authentication(eg,
> >>  > BASIC, Base 64 encoded), other urls select a generic Authenticator.
> >>  >
> >>  >
> >>  > Hantsy
> >>  >
> 

Re: [Help] Arquillian tests with TomEE profile

[Romain Manni-Bucau]

Hi,

1) yes, known, not sure it is a real issue since both deps are test deps
and both are not mandatory
2) same code as openwebbeans (would be better to go on openwebbeans list
for this issue IMO)
3) you generated them (a sample here
https://github.com/rmannibucau/JeBlog/tree/master/pom.xml)? was the
entitymanager already used - if not try to add  in your
persistence.xml?

PS: sorry was not able to build your project with my current network
connection

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



2013/6/4 Thomas Hug 
>
> Hey TomEE experts
>
> I'm currently working on getting the CDI query code base ready for import
> [1] but haven't been successful running it under the TomEE profile (JBoss
> and Glassfish run both fine).
>
> As far as I could drill down to the problems it's
> - a Maven Aether library conflict with ShrinkWrap (solved by upgrading to
> ShrinkWrap 2 beta)
> - some of the partial beans not created (haven't checked all errors but
> seems mainly related to abstract classes)
> - JPA metamodel classes not initialized (all null)
>
> Haven't run it with the debugger yet, but in case any of those problems
> ring a bell, a hint is very welcome.
>
> [1] https://github.com/ctpconsulting/query/tree/dsimport

Re: [Help] Arquillian tests with TomEE profile

[Romain Manni-Bucau]

Would be great to get the snapshot running, it uses owb 1.2
Le 5 juin 2013 02:01, "John D. Ament"  a écrit :

> Hi Thomas
>
> Good news, upgrading to 1.5.2 changed me from 18 errors and 4 failures to
> 13 errors (or some number like that).
>
> Hi Mark, Romain,
>
> Here's a gist to get you looking
>
> https://gist.github.com/johnament/5710627
>
> It looks like OWB isn't happy when you use abstract classes and type
> hierarchies.  not sure if we ever added support for abstract classes for
> the partial bean feature that Gerhard did. Gerhard?
>
> John
>
>
> On Tue, Jun 4, 2013 at 7:33 PM, John D. Ament  >wrote:
>
> > Hi Thomas,
> >
> > Also, Arquillian + TomEE was kinda buggy in 1.5.0.  1.5.1 was better,
> > 1.5.2 is also good.  I'm going to run the tests against 1.5.2.
> >
> > John
> >
> >
> > On Tue, Jun 4, 2013 at 7:29 PM, John D. Ament  >wrote:
> >
> >> Hi Thomas,
> >>
> >> Actually, the first issue I see is a common one for arquillian users.
> >>  The no active context issue can be fixed by switching from an embedded
> to
> >> managed/remote container.  For TomEE it's just as clean, do you mind if
> I
> >> try this out locally to see if some of the errors go away?
> >>
> >> BTW (from a design standpoint) do you need to bind everything to
> >> @RequestScoped? What if a user is working on something that isn't
> request
> >> scoped?
> >>
> >> John
> >>
> >>
> >> On Tue, Jun 4, 2013 at 4:53 PM, Thomas Hug 
> wrote:
> >>
> >>> Hey TomEE experts
> >>>
> >>> I'm currently working on getting the CDI query code base ready for
> import
> >>> [1] but haven't been successful running it under the TomEE profile
> (JBoss
> >>> and Glassfish run both fine).
> >>>
> >>> As far as I could drill down to the problems it's
> >>> - a Maven Aether library conflict with ShrinkWrap (solved by upgrading
> to
> >>> ShrinkWrap 2 beta)
> >>> - some of the partial beans not created (haven't checked all errors but
> >>> seems mainly related to abstract classes)
> >>> - JPA metamodel classes not initialized (all null)
> >>>
> >>> Haven't run it with the debugger yet, but in case any of those problems
> >>> ring a bell, a hint is very welcome.
> >>>
> >>> [1] https://github.com/ctpconsulting/query/tree/dsimport
> >>>
> >>
> >>
> >
>

Re: Servlet module prototype

[Romain Manni-Bucau]

Hi

in fact i don't get why you would like to be able to deactivate it.
Basically it is a web *module* so if it is here it is either needed by a
dep or you explicitely imported it so you want it. So basically a
configurable (through ConfigResolver) ServletContainerInitializer is just
what we need to be able to deactivate not needed listeners. Other config
can break modules relying on it so it could prevent lib to use this module.

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



2013/6/7 Christian Kaltepoth 

> The servlet module doesn't work at all without the filter and the
> listeners. So I think it absolutely makes sense to include them in a
> web-fragment.xml inside the servlet-impl module. If something like
> filter/listener ordering is an issue for users, they can still set
> "metadata-complete" and manually add the required entries into their own
> web.xml. Or they could use .
>
> But I agree that it should be possible to disable the events (all events or
> perhaps just the request/response events?). The question is which way the
> user should use to configure this. Of cause we could also use a servlet
> context parameter. Something like:
>
>   
> org.apache.deltaspike.DISABLE_SERVLET_EVENTS
> true
>   
>
> But DeltaSpike already provides a mechanism for disabling features which is
> part of the core module and is already used in various other places. If we
> allow users to deactivate features, we should be consistent in how users
> can do it.
>
> Is it correct that there is currently no implementation of ClassDeactivator
> in DeltaSpike at all? What about adding an implementation that uses servlet
> context parameters to the servlet module? Wouldn't this be a nice
> enhancement? This way users could either use "simple" servlet context
> parameters or they could use some other more flexible way if they want to.
>
> Christian
>
>
>
>
> 2013/6/6 John D. Ament 
>
> > What if the web-fragment.xml were in a separate JAR?
> > Deactivatable is a custom solution, I'd love to avoid using it.
> >
> >
> > On Thu, Jun 6, 2013 at 11:03 AM, Christian Kaltepoth <
> > christ...@kaltepoth.de
> > > wrote:
> >
> > > @John, @Nicklas:
> > >
> > > I agree that it should be possible to disable the servlet events. But I
> > > think we should automatically register the filter and the listeners
> using
> > > web-fragment.xml because they are required for the injection to work
> > > correctly.
> > >
> > > Isn't this a perfect use case for Deactivatable? We could simply
> define a
> > > dummy implementation of Deactivatable which can be used to disable just
> > the
> > > events. We already do something with GlobalAlternative:
> > >
> > >
> > >
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/exclude/GlobalAlternative.java#L26
> > >
> > >
> > >
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/exclude/extension/ExcludeExtension.java#L91
> > >
> > > What about this:
> > >
> > >   public interface ServletEventBridge implements Deactivatable { }
> > >
> > > Thoughts?
> > >
> > > Christian
> > >
> > >
> > >
> > > 2013/6/6 John D. Ament 
> > >
> > > > I'd prefer if we simply didn't include the web-fragment.xml and
> instead
> > > > provided instructions on the wiki on how to enable them.
> > > >
> > > >
> > > > On Thu, Jun 6, 2013 at 4:37 AM, Nicklas Karlsson  >
> > > > wrote:
> > > >
> > > > > I would also drop the @Web-annotation, I think. BTW, can the
> > > > > request/reponse lifecycle events be disabled? I would assume that
> > there
> > > > is
> > > > > a lot of firing going off for an ajax-application and they
> observers
> > > will
> > > > > have to be resolved even if there are no observers(?)
> > > > >
> > > > >
> > > > > On Thu, Jun 6, 2013 at 11:25 AM, Mark Struberg 
> > > > wrote:
> > > > >
> > > > > > Nice work!
> > > > > >
> > > > > > The @Web Qualifi

Re: Servlet module prototype

[Romain Manni-Bucau]

Ok let me rephrase.

I basically agree on the perf issue (i typically have case where i want to
use cdi to observe webapp lifecycle but not request/session) so i want to
disable some part too if my deps doesn't need it. But using a container
initializer as mentionned before you can use ConfigResolver to only
register what is not disabled (all by default). That's easy and don't need
any xml (so you don't ask the user to know a lot of thing about internals
and it is compliant with our current configuration).

Looking our conf it seems to start to be designed as a tree
(globalAlternative prefix makes me think to it) so we'd need a web prefix
probably.

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



2013/6/7 Christian Kaltepoth 

> I think Nicklas and John fear that firing events for each request/response
> could lead to performance issues!?!
>
> But I'm not sure if there will be a noticeable performance impact if there
> are no observers for the events. I don't think that firing an event that
> nobody observes is expensive.
>
> And I also think that Solder didn't provide any way to disable these events
> (correct me if I'm wrong). Or has there been any reports regarding Solder's
> performance?
>
>
> 2013/6/7 Romain Manni-Bucau 
>
> > Hi
> >
> > in fact i don't get why you would like to be able to deactivate it.
> > Basically it is a web *module* so if it is here it is either needed by a
> > dep or you explicitely imported it so you want it. So basically a
> > configurable (through ConfigResolver) ServletContainerInitializer is just
> > what we need to be able to deactivate not needed listeners. Other config
> > can break modules relying on it so it could prevent lib to use this
> module.
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/6/7 Christian Kaltepoth 
> >
> > > The servlet module doesn't work at all without the filter and the
> > > listeners. So I think it absolutely makes sense to include them in a
> > > web-fragment.xml inside the servlet-impl module. If something like
> > > filter/listener ordering is an issue for users, they can still set
> > > "metadata-complete" and manually add the required entries into their
> own
> > > web.xml. Or they could use .
> > >
> > > But I agree that it should be possible to disable the events (all
> events
> > or
> > > perhaps just the request/response events?). The question is which way
> the
> > > user should use to configure this. Of cause we could also use a servlet
> > > context parameter. Something like:
> > >
> > >   
> > >
> org.apache.deltaspike.DISABLE_SERVLET_EVENTS
> > > true
> > >   
> > >
> > > But DeltaSpike already provides a mechanism for disabling features
> which
> > is
> > > part of the core module and is already used in various other places. If
> > we
> > > allow users to deactivate features, we should be consistent in how
> users
> > > can do it.
> > >
> > > Is it correct that there is currently no implementation of
> > ClassDeactivator
> > > in DeltaSpike at all? What about adding an implementation that uses
> > servlet
> > > context parameters to the servlet module? Wouldn't this be a nice
> > > enhancement? This way users could either use "simple" servlet context
> > > parameters or they could use some other more flexible way if they want
> > to.
> > >
> > > Christian
> > >
> > >
> > >
> > >
> > > 2013/6/6 John D. Ament 
> > >
> > > > What if the web-fragment.xml were in a separate JAR?
> > > > Deactivatable is a custom solution, I'd love to avoid using it.
> > > >
> > > >
> > > > On Thu, Jun 6, 2013 at 11:03 AM, Christian Kaltepoth <
> > > > christ...@kaltepoth.de
> > > > > wrote:
> > > >
> > > > > @John, @Nicklas:
> > > > >
> > > > > I agree that it should be possible to disable the servlet events.
> 

Re: Servlet module prototype

[Romain Manni-Bucau]

If a user deactivate it it means it doesn't it the feature so no need of
any thread local. If a module needs it it can just override the
configuration to force it (through config resolver) so i still think my
proposal was possible and better than having it always on (if i missed sthg
just push a bit more your explanations please).

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



2013/6/7 Christian Kaltepoth 

> @Romain:
>
> The filter and the listeners do not only send the events but also manage
> the ThreadLocals required for the producers. So currently it is required to
> have the filter and the listeners configured for the injection to work.
> That's why I think that it makes sense to always have the filter and
> listeners in place and just don't send the events if the user disabled
> them. And of cause one could use ConfigResolver for that.
>
> @Mark:
>
> So you say that firing events is expensive even if there are no observers
> listening?
>
> Generally I like the idea of having DeltaSpike automatically detect that
> certain features can be disabled because they are not used. So if nobody
> listens for servlet events, the filter could simply never send them.
>
>
>
>
> 2013/6/7 Gerhard Petracek 
>
> > the general jira-issue for it is [1].
> >
> > regards,
> > gerhard
> >
> > [1] https://issues.apache.org/jira/browse/DELTASPIKE-349
> >
> >
> >
> > 2013/6/7 Mark Struberg 
> >
> > >
> > >
> > > Gerhard and me thought about this for quite a few other features as
> well.
> > >
> > >
> > > Event firing is indeed a bit expensive. Thus we might add a
> > >
> > >
> > > Map /*the 'feature'*/, Set>
> > > /*types which get observed*/
> > >
> > > and utilize @Observes ProcessObserverMethod to check whether there is a
> > > need to activate this feature at all.
> > >
> > > In short: if there is no ObserverMethod which @Observes ? extends
> > > ServletResponse or ServletResponse then we don't need to fire any CDI
> > > event. Not sure if this is needed though or whether the Containers are
> > > smart enough to optimize this away themselfs (with a negative cache
> kind
> > of
> > > thingy).
> > >
> > >
> > > LieGrue,
> > > strub
> > >
> > > >
> > > > From: Christian Kaltepoth 
> > > >To: dev@deltaspike.apache.org
> > > >Cc: Mark Struberg 
> > > >Sent: Friday, 7 June 2013, 8:22
> > > >Subject: Re: Servlet module prototype
> > > >
> > > >
> > > >
> > > >I think Nicklas and John fear that firing events for each
> > > request/response could lead to performance issues!?!
> > > >
> > > >
> > > >But I'm not sure if there will be a noticeable performance impact if
> > > there are no observers for the events. I don't think that firing an
> event
> > > that nobody observes is expensive.
> > > >
> > > >
> > > >And I also think that Solder didn't provide any way to disable these
> > > events (correct me if I'm wrong). Or has there been any reports
> regarding
> > > Solder's performance?
> > > >
> > > >
> > > >
> > > >2013/6/7 Romain Manni-Bucau 
> > > >
> > > >Hi
> > > >>
> > > >>in fact i don't get why you would like to be able to deactivate it.
> > > >>Basically it is a web *module* so if it is here it is either needed
> by
> > a
> > > >>dep or you explicitely imported it so you want it. So basically a
> > > >>configurable (through ConfigResolver) ServletContainerInitializer is
> > just
> > > >>what we need to be able to deactivate not needed listeners. Other
> > config
> > > >>can break modules relying on it so it could prevent lib to use this
> > > module.
> > > >>
> > > >>*Romain Manni-Bucau*
> > > >>*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > >>*Blog: **http://rmannibucau.wordpress.com/*<
> > > http://rmannibucau.wordpress.com/>
> > > >>*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > &

Re: news feed for our site?

[Romain Manni-Bucau]

+1

i prefer the tomee version since you explicitely see that's a blog stream
but i'm not opposed to OWB layout

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



2013/6/12 Charles Moulliard 

> +1 to add latest news and go (for me) to option of openwebbeans
>
>
> On Wed, Jun 12, 2013 at 8:40 AM, Mark Struberg  wrote:
>
> > Hi!
> >
> > We have the option to add a blog to blogs.apache.org. This is just a
> > plain roller setup but it's a nice goodie to have some blog.
> >
> > But the really nice feature is that we are able to add those to our CMS
> > and setup a buildbot to refresh this on a daily basis.
> >
> > There are (at least) 2 options how this could look like:
> >
> > http://openwebbeans.apache.org (section "Latest News")
> >
> > or
> >
> > http://tomee.apache.org/ (section "Latest News")
> >
> >
> > wdyt?
> > Would not be too much work to set up.
> >
> > LieGrue,
> > strub
> >
> >
>
>
> --
> Charles Moulliard
> Apache Committer / Architect @RedHat
> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
>

Re: Re: graduation is finished

[Romain Manni-Bucau]

+1, we released 0.4 so i'd say too late

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



2013/6/14 Jason Porter 

> I think at this point in time if we were to change the name it would be a
> bad thing and massively confuse the community.
>
>
> On Thu, Jun 13, 2013 at 7:47 PM, John D. Ament  >wrote:
>
> > I like it.  The only thought I might have is whether or not there's
> concern
> > that we may not keep the name deltaspike long term.
> >
> > But I like the name and idea.
> >
> >
> > On Thu, Jun 13, 2013 at 9:04 PM, Shane Bryzak 
> wrote:
> >
> > > FYI
> > >
> > >  Original Message 
> > > Subject:Re: graduation is finished
> > > Date:   Thu, 13 Jun 2013 08:42:14 -0400
> > > From:   Shane Curcuru 
> > > To: Shane Bryzak 
> > > CC: Mark Struberg 
> > >
> > >
> > >
> > > Hey Shane!  It's great to meet you!  There aren't enough Shane's in
> this
> > > world, that's what I say.
> > >
> > > Note: this conversation should really be happening on one of
> > > DeltaSpike's mailing lists, rather than offline... feel free to forward
> > > this to your dev@ or private@ list as appropriate to start the
> > > conversation properly.
> > >
> > > Yes, the ASF accepts donations of domain names that are directly
> related
> > > to our Apache project brands - this is presuming the project in
> question
> > > wants them, of course.  For pre-existing domain names, it helps to keep
> > > them under ASF management to ensure they aren't snapped up by a third
> > > party or domain squatter.
> > >
> > > Typically we take any projectname.(com|org|net) if it's pre-existing,
> > > transfer it to the ASF, and then infra manages all the redirects.  To
> do
> > > this, you should file an INFRA JIRA ticket.  One (long winded) recent
> > > example of such a ticket is here:
> > >
> > >   https://issues.apache.org/**jira/browse/INFRA-6301<
> > https://issues.apache.org/jira/browse/INFRA-6301>
> > >
> > > Thanks in advance for the donation of deltaspike.org!
> > >
> > > - Shane
> > >
> > > On 6/13/2013 7:54 AM, Mark Struberg wrote:
> > >
> > >> Hi Shane!
> > >>
> > >> Yes ASF holds a few. But most of them just redirect to the respective
> *.
> > >> apache.org pages.
> > >>
> > >> Transfer would be very cool. I've added the other Shane, VP
> trademarks,
> > >> to the list.
> > >> ShaneC, how to proceed?
> > >>
> > >> txs and LieGrue,
> > >> strub
> > >>
> > >>
> > >>
> > >>
> > >> - Original Message -
> > >>
> > >>> From: Shane Bryzak 
> > >>> To: strub...@yahoo.de
> > >>> Cc:
> > >>> Sent: Tuesday, 28 May 2013, 22:50
> > >>> Subject: Re: graduation is finished
> > >>>
> > >>> Hi Mark,
> > >>>
> > >>> I reserved the deltaspike.org domain name some time ago - do Apache
> > >>> maintain non apache.org domains for projects, and if so do you know
> if
> > >>> it's possible for me to transfer the domain to Apache?  If not,
> perhaps
> > >>> we should set up a redirect from deltaspike.org to the new
> > >>> deltaspike.apache.org site - what do you think?
> > >>>
> > >>> Shane
> > >>>
> > >>> On 29/05/13 06:15, Mark Struberg wrote:
> > >>>
> > >>>>   Hiho!
> > >>>>
> > >>>>   The graduation tasks are done now. This means that our site has
> > moved
> > >>>> to
> > >>>>
> > >>>>   http://deltaspike.apache.org/**deltaspike<
> > http://deltaspike.apache.org/deltaspike>
> > >>>>
> > >>>>   We still need to move the page to the root, but we can do this
> > >>>> ourself.
> > >>>>
> > >>>>   The other thing which changed is the git repository URL. It's now
> > >>>>
> > >>> available at
> > >>>
> > >>>>
> > >>>>   https://git-wip-us.apache.org/**repos/asf/deltaspike.git<
> > https://git-wip-us.apache.org/repos/asf/deltaspike.git>
> > >>>>
> > >>>>
> > >>>>
> > >>>>   LieGrue,
> > >>>>   strub
> > >>>>
> > >>>>
> > >>>
> > >
> > >
> > >
> >
>
>
>
> --
> Jason Porter
> http://en.gravatar.com/lightguardjp
>

Re: CDI Query import

[Romain Manni-Bucau]

Jpa-repository sounds fine as a jpa submodule for me
Le 14 juin 2013 19:56, "John D. Ament"  a écrit :

> i thought it was a separate module from JPA at inception.
>
>
> On Fri, Jun 14, 2013 at 1:08 PM, Jason Porter  >wrote:
>
> > Sounds like we need to create a new module for this, or put it into the
> JPA
> > module. Any objections for just doing the code dump into the jpa module?
> >
> >
> > On Fri, Jun 14, 2013 at 6:40 AM, Thomas Hug 
> wrote:
> >
> > > Valid point, thnx for the feedback!
> > >
> > >
> > > On Fri, Jun 14, 2013 at 2:30 PM, Karl Kildén 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Okay sounds good. I guess I interpreted it to it's worst meaning :-)
> I
> > > > would be glad to try to test it with a plain Tomcat during the coming
> > two
> > > > weeks but sounds like it should work.
> > > >
> > > > I think the final docs should be formulated a little different if you
> > > want
> > > > people to try it out and create bug reports with issues etc. At least
> > > > myself If I was on a plain tomcat and read that I would give up if I
> > had
> > > an
> > > > issue.
> > > >
> > > >
> > > > 2013/6/14 Thomas Hug 
> > > >
> > > > > Hey Karl
> > > > > I don't see a reason this should not work even with e.g. Weld SE -
> > but
> > > I
> > > > > basically wanted to say that I have neither tried it nor is it CI
> > > tested
> > > > so
> > > > > far ;-)
> > > > > Something we can put on the todo list to have the Weld and OWB
> > profile
> > > > > running as well.
> > > > >
> > > > >
> > > > > On Fri, Jun 14, 2013 at 1:58 PM, John D. Ament <
> > john.d.am...@gmail.com
> > > > > >wrote:
> > > > >
> > > > > > Karl,
> > > > > >
> > > > > > Maybe you could give it a try and let us know if it works? You'd
> > need
> > > > at
> > > > > > least JPA, CDI runtime to get it working.
> > > > > >
> > > > > >
> > > > > > On Fri, Jun 14, 2013 at 7:40 AM, Karl Kildén <
> > karl.kil...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Thomas! I got that from the third link (temp docs)
> > > > > > >
> > > > > > > "In order to use the DeltaSpike data module, you have to run
> your
> > > > > > > application in a Java EE container supporting at least the Java
> > EE
> > > 6
> > > > > Web
> > > > > > > Profile. Other configurations like running it inside Tomcat or
> > > even a
> > > > > > Java
> > > > > > > SE application are possible but currently not supported."
> > > > > > >
> > > > > > > cheers
> > > > > > >
> > > > > > >
> > > > > > > 2013/6/14 Thomas Andraschko 
> > > > > > >
> > > > > > > > sorry for this question, i didn't read other posts but why
> > can't
> > > > this
> > > > > > be
> > > > > > > > used on a plain servlet container?
> > > > > > > >
> > > > > > > >
> > > > > > > > 2013/6/14 Karl Kildén 
> > > > > > > >
> > > > > > > > > Sorry if I missed out on some of the discussions about this
> > > but I
> > > > > > think
> > > > > > > > the
> > > > > > > > > lack of support for a plain servlet container is a big
> > > > > disappointment
> > > > > > > > and a
> > > > > > > > > big loss of potential users in my immediate network.
> > > > > > > > >
> > > > > > > > > I really like the module though, can't wait etc. Thanks for
> > > doing
> > > > > it
> > > > > > > > >
> > > > > > > > > Cheers
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 2013/6/14 Thomas Hug 
> > > > > > > > >
> > > > > > > > > > Hey all
> > > > > > > > > >
> > > > > > > > > > Any suggestions on how to proceed with the CDI Query
> > import?
> > > So
> > > > > far
> > > > > > > we
> > > > > > > > > have
> > > > > > > > > > - a proposal on the API [1]
> > > > > > > > > > - a cleaned out branch depending on DS core and
> > PartialBeans,
> > > > > > running
> > > > > > > > on
> > > > > > > > > > the JBoss, TomEE and Glassfish profiles [2]
> > > > > > > > > > - a reasonable amount of documentation [3]
> > > > > > > > > > So what'd be next, anything still to adapt/missing?
> > > > > > > > > >
> > > > > > > > > > [1]
> > > https://cwiki.apache.org/DeltaSpike/repository-drafts.html
> > > > > > > > > > [2] https://github.com/ctpconsulting/query/tree/dsimport
> > > > > > > > > > [3]
> > > > https://github.com/ctpconsulting/query/tree/dsimport#readme
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Jason Porter
> > http://en.gravatar.com/lightguardjp
> >
>

Re: [DISCUSS] beanval module name

[Romain Manni-Bucau]

As a short name bval is fine but maybe too close of apache impl. So id use
bean-validation. Being explicit is good when naming things
Le 16 juin 2013 15:25, "John D. Ament"  a écrit :

> Hi all
>
> One of the comments in the introduction of a Bean Validation module is that
> the name I gave it isn't descriptive/useful.  I chose the name "beanval"
> since it was a shortened version of "Bean Validation" that could easily be
> read via maven.  To me, it's descriptive of being related to JSR303
> support.
>
> One of the other names proposed is "bv."
>
> If anyone has any recommended names, or questions about the given names,
> could you speak up?
>
> John
>

Re: [DISCUSS] beanval module name

[Romain Manni-Bucau]

whatever the list is IMO, the point was already mentionned: how many times
did you use "bv" to say bean validation? You never say "Java Persistence
API" but always jpa, for bval that's the opposite IMO.

I commonly see bval or beanvalidation but not others.

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



2013/6/16 John D. Ament 

> Gerhard,
>
> They may use [bv-dev] as a prefix, but the mailing list name is
> beanvalidation-dev.
>
>
> On Sun, Jun 16, 2013 at 10:11 AM, Gerhard Petracek <
> gerhard.petra...@gmail.com> wrote:
>
> > hi john,
> >
> > please check e.g. the official eg/dev list [1].
> > the subject of mails starts with "[bv-dev]"
> >
> > regards,
> > gerhard
> >
> > [1] http://lists.jboss.org/pipermail/beanvalidation-dev/
> >
> >
> >
> > 2013/6/16 John D. Ament 
> >
> > > gerhard/thomas
> > >
> > > The problem I have with "bv" is that no one refers to BeanValidation as
> > bv
> > > (in fact, Bean Validation is the shortened form of JavaBeans
> Validation).
> > >  Doing a quick google search on bv shows me some STDs.  Since google is
> > > typically stalking me and knows I ask lots of programming questions, it
> > > would typically return the programming references first.
> > >
> > > Doing a google search for "bv bean validation" shows
> beanvalidation.org,
> > > however there are no references to bv on that site.
> > >
> > > romain
> > >
> > > Yes, I think using "bval" ties us closely to the Apache impl.
> > >
> > > I think I generally prefer longer names.  For example, we chose
> > > partial-bean rather than pb.  If it were bean-val instead of beanval,
> > would
> > > anyone mind that?
> > >
> > > John
> > >
> > >
> > > On Sun, Jun 16, 2013 at 9:45 AM, Gerhard Petracek <
> > > gerhard.petra...@gmail.com> wrote:
> > >
> > > > hi john,
> > > >
> > > > in codi we used bv1 (like jpa1, jsf12, jsf20,...).
> > > > if we don't plan to support multiple versions with separated
> modules, i
> > > > tend to like just "bv" (since we use "jpa" and "jsf" for the modules
> of
> > > the
> > > > corresponding specs).
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2013/6/16 Romain Manni-Bucau 
> > > >
> > > > > As a short name bval is fine but maybe too close of apache impl. So
> > id
> > > > use
> > > > > bean-validation. Being explicit is good when naming things
> > > > > Le 16 juin 2013 15:25, "John D. Ament"  a
> > > écrit
> > > > :
> > > > >
> > > > > > Hi all
> > > > > >
> > > > > > One of the comments in the introduction of a Bean Validation
> module
> > > is
> > > > > that
> > > > > > the name I gave it isn't descriptive/useful.  I chose the name
> > > > "beanval"
> > > > > > since it was a shortened version of "Bean Validation" that could
> > > easily
> > > > > be
> > > > > > read via maven.  To me, it's descriptive of being related to
> JSR303
> > > > > > support.
> > > > > >
> > > > > > One of the other names proposed is "bv."
> > > > > >
> > > > > > If anyone has any recommended names, or questions about the given
> > > > names,
> > > > > > could you speak up?
> > > > > >
> > > > > > John
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] beanval module name

[Romain Manni-Bucau]

even when speaking?

Then the point is who should understand the name, the EG or users.

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



2013/6/16 Gerhard Petracek 

> we (= bv-eg) ~always used "bv". it's even used in the bv-spec. document.
>
> regards,
> gerhard
>
>
>
> 2013/6/16 Romain Manni-Bucau 
>
> > whatever the list is IMO, the point was already mentionned: how many
> times
> > did you use "bv" to say bean validation? You never say "Java Persistence
> > API" but always jpa, for bval that's the opposite IMO.
> >
> > I commonly see bval or beanvalidation but not others.
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/6/16 John D. Ament 
> >
> > > Gerhard,
> > >
> > > They may use [bv-dev] as a prefix, but the mailing list name is
> > > beanvalidation-dev.
> > >
> > >
> > > On Sun, Jun 16, 2013 at 10:11 AM, Gerhard Petracek <
> > > gerhard.petra...@gmail.com> wrote:
> > >
> > > > hi john,
> > > >
> > > > please check e.g. the official eg/dev list [1].
> > > > the subject of mails starts with "[bv-dev]"
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > > [1] http://lists.jboss.org/pipermail/beanvalidation-dev/
> > > >
> > > >
> > > >
> > > > 2013/6/16 John D. Ament 
> > > >
> > > > > gerhard/thomas
> > > > >
> > > > > The problem I have with "bv" is that no one refers to
> BeanValidation
> > as
> > > > bv
> > > > > (in fact, Bean Validation is the shortened form of JavaBeans
> > > Validation).
> > > > >  Doing a quick google search on bv shows me some STDs.  Since
> google
> > is
> > > > > typically stalking me and knows I ask lots of programming
> questions,
> > it
> > > > > would typically return the programming references first.
> > > > >
> > > > > Doing a google search for "bv bean validation" shows
> > > beanvalidation.org,
> > > > > however there are no references to bv on that site.
> > > > >
> > > > > romain
> > > > >
> > > > > Yes, I think using "bval" ties us closely to the Apache impl.
> > > > >
> > > > > I think I generally prefer longer names.  For example, we chose
> > > > > partial-bean rather than pb.  If it were bean-val instead of
> beanval,
> > > > would
> > > > > anyone mind that?
> > > > >
> > > > > John
> > > > >
> > > > >
> > > > > On Sun, Jun 16, 2013 at 9:45 AM, Gerhard Petracek <
> > > > > gerhard.petra...@gmail.com> wrote:
> > > > >
> > > > > > hi john,
> > > > > >
> > > > > > in codi we used bv1 (like jpa1, jsf12, jsf20,...).
> > > > > > if we don't plan to support multiple versions with separated
> > > modules, i
> > > > > > tend to like just "bv" (since we use "jpa" and "jsf" for the
> > modules
> > > of
> > > > > the
> > > > > > corresponding specs).
> > > > > >
> > > > > > regards,
> > > > > > gerhard
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2013/6/16 Romain Manni-Bucau 
> > > > > >
> > > > > > > As a short name bval is fine but maybe too close of apache
> impl.
> > So
> > > > id
> > > > > > use
> > > > > > > bean-validation. Being explicit is good when naming things
> > > > > > > Le 16 juin 2013 15:25, "John D. Ament"  >
> > a
> > > > > écrit
> > > > > > :
> > > > > > >
> > > > > > > > Hi all
> > > > > > > >
> > > > > > > > One of the comments in the introduction of a Bean Validation
> > > module
> > > > > is
> > > > > > > that
> > > > > > > > the name I gave it isn't descriptive/useful.  I chose the
> name
> > > > > > "beanval"
> > > > > > > > since it was a shortened version of "Bean Validation" that
> > could
> > > > > easily
> > > > > > > be
> > > > > > > > read via maven.  To me, it's descriptive of being related to
> > > JSR303
> > > > > > > > support.
> > > > > > > >
> > > > > > > > One of the other names proposed is "bv."
> > > > > > > >
> > > > > > > > If anyone has any recommended names, or questions about the
> > given
> > > > > > names,
> > > > > > > > could you speak up?
> > > > > > > >
> > > > > > > > John
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] beanval module name

[Romain Manni-Bucau]

codi is not that used, and not sure bv is explicit enough in all languages.

hibernate uses "validator", other can use jsr330/jsr349. Since this module
can be an in between 330 and 349 maybe using jsr330 is good but IMO has the
same drawback as "bv". If you don't follow specs and/or dev them you don't
know what it is.

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



2013/6/16 Gerhard Petracek 

> we never had an issue with that in codi where we use "bv" since 2010.
>
> regards,
> gerhard
>
>
>
> 2013/6/16 Romain Manni-Bucau 
>
> > even when speaking?
> >
> > Then the point is who should understand the name, the EG or users.
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/6/16 Gerhard Petracek 
> >
> > > we (= bv-eg) ~always used "bv". it's even used in the bv-spec.
> document.
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2013/6/16 Romain Manni-Bucau 
> > >
> > > > whatever the list is IMO, the point was already mentionned: how many
> > > times
> > > > did you use "bv" to say bean validation? You never say "Java
> > Persistence
> > > > API" but always jpa, for bval that's the opposite IMO.
> > > >
> > > > I commonly see bval or beanvalidation but not others.
> > > >
> > > > *Romain Manni-Bucau*
> > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > > http://rmannibucau.wordpress.com/>
> > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > > *Github: https://github.com/rmannibucau*
> > > >
> > > >
> > > >
> > > > 2013/6/16 John D. Ament 
> > > >
> > > > > Gerhard,
> > > > >
> > > > > They may use [bv-dev] as a prefix, but the mailing list name is
> > > > > beanvalidation-dev.
> > > > >
> > > > >
> > > > > On Sun, Jun 16, 2013 at 10:11 AM, Gerhard Petracek <
> > > > > gerhard.petra...@gmail.com> wrote:
> > > > >
> > > > > > hi john,
> > > > > >
> > > > > > please check e.g. the official eg/dev list [1].
> > > > > > the subject of mails starts with "[bv-dev]"
> > > > > >
> > > > > > regards,
> > > > > > gerhard
> > > > > >
> > > > > > [1] http://lists.jboss.org/pipermail/beanvalidation-dev/
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2013/6/16 John D. Ament 
> > > > > >
> > > > > > > gerhard/thomas
> > > > > > >
> > > > > > > The problem I have with "bv" is that no one refers to
> > > BeanValidation
> > > > as
> > > > > > bv
> > > > > > > (in fact, Bean Validation is the shortened form of JavaBeans
> > > > > Validation).
> > > > > > >  Doing a quick google search on bv shows me some STDs.  Since
> > > google
> > > > is
> > > > > > > typically stalking me and knows I ask lots of programming
> > > questions,
> > > > it
> > > > > > > would typically return the programming references first.
> > > > > > >
> > > > > > > Doing a google search for "bv bean validation" shows
> > > > > beanvalidation.org,
> > > > > > > however there are no references to bv on that site.
> > > > > > >
> > > > > > > romain
> > > > > > >
> > > > > > > Yes, I think using "bval" ties us closely to the Apache impl.
> > > > > > >
> > > > > > > I think I generally prefer longer names.  For example, we 

Re: [DISCUSS] beanval module name

[Romain Manni-Bucau]

works for me, so waiting for the vote

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



2013/6/16 Gerhard Petracek 

> we won't get a full agreement on that. we just need a majority for one
> abbreviation.
> if you don't agree (for whatever reason) with "bv" (which was coined by the
> eg and is used since years), you are welcome to vote for a different
> abbreviation.
>
> regards,
> gerhard
>
>
>
> 2013/6/16 Romain Manni-Bucau 
>
> > codi is not that used, and not sure bv is explicit enough in all
> languages.
> >
> > hibernate uses "validator", other can use jsr330/jsr349. Since this
> module
> > can be an in between 330 and 349 maybe using jsr330 is good but IMO has
> the
> > same drawback as "bv". If you don't follow specs and/or dev them you
> don't
> > know what it is.
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/6/16 Gerhard Petracek 
> >
> > > we never had an issue with that in codi where we use "bv" since 2010.
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2013/6/16 Romain Manni-Bucau 
> > >
> > > > even when speaking?
> > > >
> > > > Then the point is who should understand the name, the EG or users.
> > > >
> > > > *Romain Manni-Bucau*
> > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > > http://rmannibucau.wordpress.com/>
> > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > > *Github: https://github.com/rmannibucau*
> > > >
> > > >
> > > >
> > > > 2013/6/16 Gerhard Petracek 
> > > >
> > > > > we (= bv-eg) ~always used "bv". it's even used in the bv-spec.
> > > document.
> > > > >
> > > > > regards,
> > > > > gerhard
> > > > >
> > > > >
> > > > >
> > > > > 2013/6/16 Romain Manni-Bucau 
> > > > >
> > > > > > whatever the list is IMO, the point was already mentionned: how
> > many
> > > > > times
> > > > > > did you use "bv" to say bean validation? You never say "Java
> > > > Persistence
> > > > > > API" but always jpa, for bval that's the opposite IMO.
> > > > > >
> > > > > > I commonly see bval or beanvalidation but not others.
> > > > > >
> > > > > > *Romain Manni-Bucau*
> > > > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > > > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > > > > http://rmannibucau.wordpress.com/>
> > > > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > > > > *Github: https://github.com/rmannibucau*
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2013/6/16 John D. Ament 
> > > > > >
> > > > > > > Gerhard,
> > > > > > >
> > > > > > > They may use [bv-dev] as a prefix, but the mailing list name is
> > > > > > > beanvalidation-dev.
> > > > > > >
> > > > > > >
> > > > > > > On Sun, Jun 16, 2013 at 10:11 AM, Gerhard Petracek <
> > > > > > > gerhard.petra...@gmail.com> wrote:
> > > > > > >
> > > > > > > > hi john,
> > > > > > > >
> > > > > > > > please check e.g. the official eg/dev list [1].
> > > > > > > > the subject of mails starts with "[bv-dev]"
> > > > > > > >
> > > > > > > > regards,
> > > > > > > > gerhard
> > > > > > > >
> > > > > > > > [1] h

Re: [VOTE] Bean Validation Module Name

[Romain Manni-Bucau]

-1
Le 17 juin 2013 02:49, "John D. Ament"  a écrit :

> This way we can just sum up the total.
> On Jun 16, 2013 8:46 PM, "Jason Porter"  wrote:
>
> > This a little odd way of doing a vote, but whatever :)
> >
> >
> > -1 I prefer bean-validation, it aligns exactly with the name.
> >
> > —
> > Sent from Mailbox for iPhone
> >
> > On Sun, Jun 16, 2013 at 6:43 PM, John D. Ament 
> > wrote:
> >
> > > [+1] beanval
> > > BTW, I'll leave this open for about 72 hours.
> > > John
> > > On Sun, Jun 16, 2013 at 8:42 PM, John D. Ament  > >wrote:
> > >> All
> > >>
> > >> Based on the thread thus far, I'd like to call a vote.  These are the
> > two
> > >> names the seem to have the least angst:
> > >>
> > >> beanval
> > >> bean-validation
> > >>
> > >> So, to vote please respond with a +1 or a -1.  +1 is for "beanval" but
> > -1
> > >> is for "bean-validation"
> > >>
> > >> I'm not including bv due to the US English connotations.  I'm not
> > >> including bval due to the existing apache project plus references to
> > other
> > >> names I saw in a quick google search.
> > >>
> > >> - John
> > >>
>

Re: [ANNOUNCE] Welcome Thomas Hug as new DeltaSpike committer

[Romain Manni-Bucau]

Welcome Thomas!
Le 22 juin 2013 18:16, "Mark Struberg"  a écrit :

> The Apache DeltaSpike Team is happy to announce the addition of Thomas Hug
> as new committer.
>
> Thomas will contribute the CDI-Query module and might also help in other
> areas.
>
> Welcome on board, Thomas!
>
> Sincerly,
> the Apache DeltaSpike PMC
>

Re: Time to cut 0.5?

[Romain Manni-Bucau]

+1, data module needs review and we (with Jean-Louis) already saw an issue
in its usage: it is not compatible with DTO at all.

It would be great to enhance the API to support it (using ModelMapper it
would be trivial to implement, the only issue will be to add an interface
Repository) -> probably needs another discuss
thread but i'll let JL open it

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



2013/7/10 Mark Struberg 

> yup, I really like to get 0.5 out of the door. We need some reviews first
> though.
> Mainly the new query and beanval modules.
> Sadly, I'm 180% overloaded at $$dayjob right now. Hope I can find some
> time on the weekend.
>
> Or did anyone else take a deep look at it already?
> Then I'd be happy to run the release tasks.
>
> This I would also like to document the release process so everybody is
> able to run it.
>
> LieGrue,
> strub
>
>
>
>
>
> - Original Message -
> From: Jason Porter 
> To: dev@deltaspike.apache.org
> Cc:
> Sent: Sunday, 7 July 2013, 2:20
> Subject: Re: Time to cut 0.5?
>
> Yep, saw the deluge of emails come in.
>
>
> On Sat, Jul 6, 2013 at 6:18 PM, John D. Ament  >wrote:
>
> > 0.5 was intended to be a small release, per [1]
> >
> > Note, I just moved the config module ones per your note in the top level
> > issue.
> >
> > [1]:
> >
> http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201306.mbox/browser
> >
> >
> > On Sat, Jul 6, 2013 at 8:15 PM, Jason Porter  > >wrote:
> >
> > > I must have been sleeping or something for 0.5, I didn't think that
> much
> > > work had been done. If that much work had been done, why are there only
> > > nine closed issues in 0.5 in JIRA?
> > >
> > >
> > > On Sat, Jul 6, 2013 at 6:09 PM, John D. Ament  > > >wrote:
> > >
> > > > Errr, 3 new modules.
> > > >
> > > >
> > > > On Sat, Jul 6, 2013 at 8:03 PM, John D. Ament <
> john.d.am...@gmail.com
> > > > >wrote:
> > > >
> > > > > We're a couple weeks late, but is anyone else interested in seeing
> > 0.5
> > > > > cut?  Seems like we have a slew of bug fixes and two new modules in
> > the
> > > > > hangar waiting to take off.
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Jason Porter
> > > http://en.gravatar.com/lightguardjp
> > >
> >
>
>
>
> --
> Jason Porter
> http://en.gravatar.com/lightguardjp
>
>

Re: Data Module

[Romain Manni-Bucau]

+1

just to complete this thread the main issue is not the implementation but
the exposed API:

public interface EntityRepository

would become

public interface EntityDtoRepository

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



2013/7/10 Jean-Louis MONTEIRO 

> Hello guys,
>
> Just used DS Data module yesturday, and I was wondering if we could add a
> feature allowing on-the-fly conversion to DTO.
> For example, we could use modelmapper (or similar to convert DAO return
> values to DTO objects).
>
> Adding a mapper interface to delegate to would also allow people to plug
> their own implementation in.
>
> WDYT?
>
> JLouis
>
>
> 2013/7/1 Thomas Hug 
>
> > Hi John
> > Thnx for the message, missed that one. Looks like there's a default
> profile
> > needed (test-persistence.xml only part of the specific server profiles).
> > Will check tonight.
> >
> >
> > On Mon, Jul 1, 2013 at 2:42 AM, John D. Ament  > >wrote:
> >
> > > Hi
> > >
> > > Whoever brought in the data module, can you double check your tests and
> > > license headers?
> > >
> > > I think it's just your tests, but it's failing during a rat check
> > >
> > >
> > >
> >
> https://builds.apache.org/job/DeltaSpike%20RAT-Check/org.apache.deltaspike.modules$deltaspike-data-module-impl/558/testReport/org.apache.deltaspike.data.impl/QueryResultTest/org_apache_deltaspike_data_impl_QueryResultTest/
> > >
> > > John
> > >
> >
>
>
>
> --
> Jean-Louis
>

Re: Data Module

[Romain Manni-Bucau]

do you mean you force forEntity = Person.class?

looks ok for me since the only constraint is to add the dto types somewhere
:)

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



2013/7/10 Thomas Hug 

> Hmm and I assumed DTOs are dead and buried :-)
>
> Packing this in the base interface feels kind of clunky to me - also
> considering that there are repositories without the need to extend the base
> interface. What about something like
>
> @Repository(forEntity = Person.class)
> @ResultMapper(entityMapper = MapperX.class, keyMapper = MapperY.class)
> public interface PersonRepository extends EntityRepository DtoPk> { ... }
>
> Having the Entity on @Repository takes precedence and the type parameters
> are in this case just for convenience.
>
>
>
> On Wed, Jul 10, 2013 at 2:35 PM, Romain Manni-Bucau
> wrote:
>
> > +1
> >
> > just to complete this thread the main issue is not the implementation but
> > the exposed API:
> >
> > public interface EntityRepository
> >
> > would become
> >
> > public interface EntityDtoRepository > DtoPk>
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/7/10 Jean-Louis MONTEIRO 
> >
> > > Hello guys,
> > >
> > > Just used DS Data module yesturday, and I was wondering if we could
> add a
> > > feature allowing on-the-fly conversion to DTO.
> > > For example, we could use modelmapper (or similar to convert DAO return
> > > values to DTO objects).
> > >
> > > Adding a mapper interface to delegate to would also allow people to
> plug
> > > their own implementation in.
> > >
> > > WDYT?
> > >
> > > JLouis
> > >
> > >
> > > 2013/7/1 Thomas Hug 
> > >
> > > > Hi John
> > > > Thnx for the message, missed that one. Looks like there's a default
> > > profile
> > > > needed (test-persistence.xml only part of the specific server
> > profiles).
> > > > Will check tonight.
> > > >
> > > >
> > > > On Mon, Jul 1, 2013 at 2:42 AM, John D. Ament <
> john.d.am...@gmail.com
> > > > >wrote:
> > > >
> > > > > Hi
> > > > >
> > > > > Whoever brought in the data module, can you double check your tests
> > and
> > > > > license headers?
> > > > >
> > > > > I think it's just your tests, but it's failing during a rat check
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://builds.apache.org/job/DeltaSpike%20RAT-Check/org.apache.deltaspike.modules$deltaspike-data-module-impl/558/testReport/org.apache.deltaspike.data.impl/QueryResultTest/org_apache_deltaspike_data_impl_QueryResultTest/
> > > > >
> > > > > John
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Jean-Louis
> > >
> >
>

Re: Data Module

[Romain Manni-Bucau]

globally my answer meant "if forEntity is sometimes mandatory, sometimes
not this is maybe not the right place"

i thought to add it to mapper config

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



2013/7/10 Thomas Hug 

> Making forEntity non-optional would then be redundant for the regular cases
> using the base interface, so I wouldn't. But I see that it should be
> clearly documented then as things might get confusing...
>
>
> On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau
> wrote:
>
> > do you mean you force forEntity = Person.class?
> >
> > looks ok for me since the only constraint is to add the dto types
> somewhere
> > :)
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/7/10 Thomas Hug 
> >
> > > Hmm and I assumed DTOs are dead and buried :-)
> > >
> > > Packing this in the base interface feels kind of clunky to me - also
> > > considering that there are repositories without the need to extend the
> > base
> > > interface. What about something like
> > >
> > > @Repository(forEntity = Person.class)
> > > @ResultMapper(entityMapper = MapperX.class, keyMapper = MapperY.class)
> > > public interface PersonRepository extends EntityRepository > > DtoPk> { ... }
> > >
> > > Having the Entity on @Repository takes precedence and the type
> parameters
> > > are in this case just for convenience.
> > >
> > >
> > >
> > > On Wed, Jul 10, 2013 at 2:35 PM, Romain Manni-Bucau
> > > wrote:
> > >
> > > > +1
> > > >
> > > > just to complete this thread the main issue is not the implementation
> > but
> > > > the exposed API:
> > > >
> > > > public interface EntityRepository
> > > >
> > > > would become
> > > >
> > > > public interface EntityDtoRepository > > > DtoPk>
> > > >
> > > > *Romain Manni-Bucau*
> > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > > http://rmannibucau.wordpress.com/>
> > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > > *Github: https://github.com/rmannibucau*
> > > >
> > > >
> > > >
> > > > 2013/7/10 Jean-Louis MONTEIRO 
> > > >
> > > > > Hello guys,
> > > > >
> > > > > Just used DS Data module yesturday, and I was wondering if we could
> > > add a
> > > > > feature allowing on-the-fly conversion to DTO.
> > > > > For example, we could use modelmapper (or similar to convert DAO
> > return
> > > > > values to DTO objects).
> > > > >
> > > > > Adding a mapper interface to delegate to would also allow people to
> > > plug
> > > > > their own implementation in.
> > > > >
> > > > > WDYT?
> > > > >
> > > > > JLouis
> > > > >
> > > > >
> > > > > 2013/7/1 Thomas Hug 
> > > > >
> > > > > > Hi John
> > > > > > Thnx for the message, missed that one. Looks like there's a
> default
> > > > > profile
> > > > > > needed (test-persistence.xml only part of the specific server
> > > > profiles).
> > > > > > Will check tonight.
> > > > > >
> > > > > >
> > > > > > On Mon, Jul 1, 2013 at 2:42 AM, John D. Ament <
> > > john.d.am...@gmail.com
> > > > > > >wrote:
> > > > > >
> > > > > > > Hi
> > > > > > >
> > > > > > > Whoever brought in the data module, can you double check your
> > tests
> > > > and
> > > > > > > license headers?
> > > > > > >
> > > > > > > I think it's just your tests, but it's failing during a rat
> check
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://builds.apache.org/job/DeltaSpike%20RAT-Check/org.apache.deltaspike.modules$deltaspike-data-module-impl/558/testReport/org.apache.deltaspike.data.impl/QueryResultTest/org_apache_deltaspike_data_impl_QueryResultTest/
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Jean-Louis
> > > > >
> > > >
> > >
> >
>

Re: Data Module

[Romain Manni-Bucau]

Cause in REST you can push your entities to your REST endpoints then simply
convert it to DTO, that's a stateless case which work but not that general.

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



2013/7/10 John D. Ament 

> Personally, I don't like this idea.
>
> A DAO should do DAO stuff.
> A DTO should do DTO stuff.
>
> The transformation of your entities into some other POJO shouldn't be
> inside your DAO.
>
> Right now, I use google guava to do DTO work on entities going back and
> forth over a REST API.  Works well IMHO.
>
> John
>
>
> On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
> wrote:
>
> > globally my answer meant "if forEntity is sometimes mandatory, sometimes
> > not this is maybe not the right place"
> >
> > i thought to add it to mapper config
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/7/10 Thomas Hug 
> >
> > > Making forEntity non-optional would then be redundant for the regular
> > cases
> > > using the base interface, so I wouldn't. But I see that it should be
> > > clearly documented then as things might get confusing...
> > >
> > >
> > > On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau
> > > wrote:
> > >
> > > > do you mean you force forEntity = Person.class?
> > > >
> > > > looks ok for me since the only constraint is to add the dto types
> > > somewhere
> > > > :)
> > > >
> > > > *Romain Manni-Bucau*
> > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > > http://rmannibucau.wordpress.com/>
> > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > > *Github: https://github.com/rmannibucau*
> > > >
> > > >
> > > >
> > > > 2013/7/10 Thomas Hug 
> > > >
> > > > > Hmm and I assumed DTOs are dead and buried :-)
> > > > >
> > > > > Packing this in the base interface feels kind of clunky to me -
> also
> > > > > considering that there are repositories without the need to extend
> > the
> > > > base
> > > > > interface. What about something like
> > > > >
> > > > > @Repository(forEntity = Person.class)
> > > > > @ResultMapper(entityMapper = MapperX.class, keyMapper =
> > MapperY.class)
> > > > > public interface PersonRepository extends
> EntityRepository > > > > DtoPk> { ... }
> > > > >
> > > > > Having the Entity on @Repository takes precedence and the type
> > > parameters
> > > > > are in this case just for convenience.
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Jul 10, 2013 at 2:35 PM, Romain Manni-Bucau
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > just to complete this thread the main issue is not the
> > implementation
> > > > but
> > > > > > the exposed API:
> > > > > >
> > > > > > public interface EntityRepository
> > > > > >
> > > > > > would become
> > > > > >
> > > > > > public interface EntityDtoRepository > Dto,
> > > > > > DtoPk>
> > > > > >
> > > > > > *Romain Manni-Bucau*
> > > > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > > > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > > > > http://rmannibucau.wordpress.com/>
> > > > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > > > > *Github: https://github.com/rmannibucau*
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2013/7/10 Jean-Louis MONTEIRO 
> > > > > >
>

Re: Data Module

[Romain Manni-Bucau]

Hi

Depending the case DTO are not an option.

I agree in rest app i wouldnt it but if not possible (maybe through another
Bean) it would kill this module for half of the usages i see since i'd need
to add this layer.
Le 12 juil. 2013 06:55, "hantsy"  a écrit :

> No DTO please, data module for data access, why we care about DTO.
>
> A question about the data, the difference for EJB and none EJB environment.
>
> if possible in a EJB envoriment, proxy the Repository and add @Stateless
> and transaction declaration to Repository automatically at runtime.
>
> Regards
>
> Hantsy
> On 7/10/2013 23:23, Thomas Hug wrote:
> > I wouldn't label the feature with DTO but rather as some general result
> > transformation - might also be useful for e.g. native queries. Going back
> > to the API suggestion, from that perspective such an annotation should
> > probably also work on method level, so I'd keep the forEntity out there.
> >
> >
> > On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament  >wrote:
> >
> >> Personally, I don't like this idea.
> >>
> >> A DAO should do DAO stuff.
> >> A DTO should do DTO stuff.
> >>
> >> The transformation of your entities into some other POJO shouldn't be
> >> inside your DAO.
> >>
> >> Right now, I use google guava to do DTO work on entities going back and
> >> forth over a REST API.  Works well IMHO.
> >>
> >> John
> >>
> >>
> >> On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
> >> wrote:
> >>
> >>> globally my answer meant "if forEntity is sometimes mandatory,
> sometimes
> >>> not this is maybe not the right place"
> >>>
> >>> i thought to add it to mapper config
> >>>
> >>> *Romain Manni-Bucau*
> >>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> >>> *Blog: **http://rmannibucau.wordpress.com/*<
> >>> http://rmannibucau.wordpress.com/>
> >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >>> *Github: https://github.com/rmannibucau*
> >>>
> >>>
> >>>
> >>> 2013/7/10 Thomas Hug 
> >>>
> >>>> Making forEntity non-optional would then be redundant for the regular
> >>> cases
> >>>> using the base interface, so I wouldn't. But I see that it should be
> >>>> clearly documented then as things might get confusing...
> >>>>
> >>>>
> >>>> On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau
> >>>> wrote:
> >>>>
> >>>>> do you mean you force forEntity = Person.class?
> >>>>>
> >>>>> looks ok for me since the only constraint is to add the dto types
> >>>> somewhere
> >>>>> :)
> >>>>>
> >>>>> *Romain Manni-Bucau*
> >>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> >>>>> *Blog: **http://rmannibucau.wordpress.com/*<
> >>>>> http://rmannibucau.wordpress.com/>
> >>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >>>>> *Github: https://github.com/rmannibucau*
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2013/7/10 Thomas Hug 
> >>>>>
> >>>>>> Hmm and I assumed DTOs are dead and buried :-)
> >>>>>>
> >>>>>> Packing this in the base interface feels kind of clunky to me -
> >> also
> >>>>>> considering that there are repositories without the need to extend
> >>> the
> >>>>> base
> >>>>>> interface. What about something like
> >>>>>>
> >>>>>> @Repository(forEntity = Person.class)
> >>>>>> @ResultMapper(entityMapper = MapperX.class, keyMapper =
> >>> MapperY.class)
> >>>>>> public interface PersonRepository extends
> >> EntityRepository >>>>>> DtoPk> { ... }
> >>>>>>
> >>>>>> Having the Entity on @Repository takes precedence and the type
> >>>> parameters
> >>>>>> are in this case just for convenience.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Jul 10, 2013 at 2:35 PM, Romain Manni-Bucau
> >>>>>> wrote:
&

Re: Data Module

[Romain Manni-Bucau]

Ps: you can make a cdi bean an ejb from cdi extension
Le 12 juil. 2013 08:12, "Romain Manni-Bucau"  a
écrit :

> Hi
>
> Depending the case DTO are not an option.
>
> I agree in rest app i wouldnt it but if not possible (maybe through
> another Bean) it would kill this module for half of the usages i see since
> i'd need to add this layer.
> Le 12 juil. 2013 06:55, "hantsy"  a écrit :
>
>> No DTO please, data module for data access, why we care about DTO.
>>
>> A question about the data, the difference for EJB and none EJB
>> environment.
>>
>> if possible in a EJB envoriment, proxy the Repository and add @Stateless
>> and transaction declaration to Repository automatically at runtime.
>>
>> Regards
>>
>> Hantsy
>> On 7/10/2013 23:23, Thomas Hug wrote:
>> > I wouldn't label the feature with DTO but rather as some general result
>> > transformation - might also be useful for e.g. native queries. Going
>> back
>> > to the API suggestion, from that perspective such an annotation should
>> > probably also work on method level, so I'd keep the forEntity out there.
>> >
>> >
>> > On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament > >wrote:
>> >
>> >> Personally, I don't like this idea.
>> >>
>> >> A DAO should do DAO stuff.
>> >> A DTO should do DTO stuff.
>> >>
>> >> The transformation of your entities into some other POJO shouldn't be
>> >> inside your DAO.
>> >>
>> >> Right now, I use google guava to do DTO work on entities going back and
>> >> forth over a REST API.  Works well IMHO.
>> >>
>> >> John
>> >>
>> >>
>> >> On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
>> >> wrote:
>> >>
>> >>> globally my answer meant "if forEntity is sometimes mandatory,
>> sometimes
>> >>> not this is maybe not the right place"
>> >>>
>> >>> i thought to add it to mapper config
>> >>>
>> >>> *Romain Manni-Bucau*
>> >>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>> >>> *Blog: **http://rmannibucau.wordpress.com/*<
>> >>> http://rmannibucau.wordpress.com/>
>> >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>> >>> *Github: https://github.com/rmannibucau*
>> >>>
>> >>>
>> >>>
>> >>> 2013/7/10 Thomas Hug 
>> >>>
>> >>>> Making forEntity non-optional would then be redundant for the regular
>> >>> cases
>> >>>> using the base interface, so I wouldn't. But I see that it should be
>> >>>> clearly documented then as things might get confusing...
>> >>>>
>> >>>>
>> >>>> On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau
>> >>>> wrote:
>> >>>>
>> >>>>> do you mean you force forEntity = Person.class?
>> >>>>>
>> >>>>> looks ok for me since the only constraint is to add the dto types
>> >>>> somewhere
>> >>>>> :)
>> >>>>>
>> >>>>> *Romain Manni-Bucau*
>> >>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>> >>>>> *Blog: **http://rmannibucau.wordpress.com/*<
>> >>>>> http://rmannibucau.wordpress.com/>
>> >>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>> >>>>> *Github: https://github.com/rmannibucau*
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> 2013/7/10 Thomas Hug 
>> >>>>>
>> >>>>>> Hmm and I assumed DTOs are dead and buried :-)
>> >>>>>>
>> >>>>>> Packing this in the base interface feels kind of clunky to me -
>> >> also
>> >>>>>> considering that there are repositories without the need to extend
>> >>> the
>> >>>>> base
>> >>>>>> interface. What about something like
>> >>>>>>
>> >>>>>> @Repository(forEntity = Person.class)
>> >>>>>> @ResultMapper(entityMapper = MapperX.class, keyMapper =
>> >>> MapperY.class)
>> >>>>>>

Re: Data Module

[Romain Manni-Bucau]

@John: oops, was a type, "can" was "cannot", i meant adding @stateless will
do nothing.

about dto or not both are needed, i dont propose to force it, i just
mention it is common to need it.

the proposed API sounds fine for me.

I don't want this thread to be a troll, dto usage depends on the
architecture of the app and that's not the role of DS to say it is good or
not (the answer would obviously be wrong here ;).

DTO (or whatever name you want) are larger than entity/other object, it can
always be data cleanup. So basically we need a layer to be able to modify
what is returned, nothing more.

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



2013/7/12 John D. Ament 

> Yep, if you want to do it in the JPA layer you can do something like that.
>
> In my case, my front end data objects aren't exposed to our JPA libraries,
> so it's not an option.
>
> @Romain
>
> How do you make a CDI object a remote EJB? Or are you referring to
> transactional state? As far as I know, you cannot setup an MDB in a CDI
> extension.
>
>
> On Fri, Jul 12, 2013 at 6:59 AM, hantsy  wrote:
>
> > Your requirement is based on your experience, i do not think a must in
> > REST application.
> >
> > Some case we can wrap the result in query result like this.
> >
> > select new UserResult(name, email ) from  User u
> >
> > to get a  ValueObject directly.
> >
> >
> > Hantsy
> > On 7/12/2013 14:12, Romain Manni-Bucau wrote:
> > > Hi
> > >
> > > Depending the case DTO are not an option.
> > >
> > > I agree in rest app i wouldnt it but if not possible (maybe through
> > another
> > > Bean) it would kill this module for half of the usages i see since i'd
> > need
> > > to add this layer.
> > > Le 12 juil. 2013 06:55, "hantsy"  a écrit :
> > >
> > >> No DTO please, data module for data access, why we care about DTO.
> > >>
> > >> A question about the data, the difference for EJB and none EJB
> > environment.
> > >>
> > >> if possible in a EJB envoriment, proxy the Repository and add
> @Stateless
> > >> and transaction declaration to Repository automatically at runtime.
> > >>
> > >> Regards
> > >>
> > >> Hantsy
> > >> On 7/10/2013 23:23, Thomas Hug wrote:
> > >>> I wouldn't label the feature with DTO but rather as some general
> result
> > >>> transformation - might also be useful for e.g. native queries. Going
> > back
> > >>> to the API suggestion, from that perspective such an annotation
> should
> > >>> probably also work on method level, so I'd keep the forEntity out
> > there.
> > >>>
> > >>>
> > >>> On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament <
> john.d.am...@gmail.com
> > >>> wrote:
> > >>>
> > >>>> Personally, I don't like this idea.
> > >>>>
> > >>>> A DAO should do DAO stuff.
> > >>>> A DTO should do DTO stuff.
> > >>>>
> > >>>> The transformation of your entities into some other POJO shouldn't
> be
> > >>>> inside your DAO.
> > >>>>
> > >>>> Right now, I use google guava to do DTO work on entities going back
> > and
> > >>>> forth over a REST API.  Works well IMHO.
> > >>>>
> > >>>> John
> > >>>>
> > >>>>
> > >>>> On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
> > >>>> wrote:
> > >>>>
> > >>>>> globally my answer meant "if forEntity is sometimes mandatory,
> > >> sometimes
> > >>>>> not this is maybe not the right place"
> > >>>>>
> > >>>>> i thought to add it to mapper config
> > >>>>>
> > >>>>> *Romain Manni-Bucau*
> > >>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > >>>>> *Blog: **http://rmannibucau.wordpress.com/*<
> > >>>>> http://rmannibucau.wordpress.com/>
> > >>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > >>>>> *Github: http

Re: all tests green (almost)

[Romain Manni-Bucau]

I think so too, this is not a main feature of DS IMO
Le 11 août 2013 16:43, "John D. Ament"  a écrit :

> Well, it looks like Glassfish 4 is shipping with 2.0.0.SP1.
>
> Maybe we can just list this as a known limitation?
>
> On Sun, Aug 11, 2013 at 9:22 AM, Mark Struberg  wrote:
> > Hi folks!
> >
> > All our CI are now green again. The only Exception being weld-2.0.0 and
> 2.0.0.SP1.
> >
> > I first guessed it's due to the missing getBean() handling in our
> InjectionPoints created via BeanBuilder. But it turns our it had no impact.
> > These 2 weld verions fail with an internal proxy failure (NPE deep
> inside the proxy due to wrong handling of abstract classes).
> > It seems those errors already got fixed with weld-2.0.1 onwards (both
> works perfectly fine in our CI builds).
> >
> > Are those buggy 2.0.0 versions used in some containers? Or can we just
> remove them from our CI because they are known to be broken?
> >
> > txs and LieGrue,
> > strub
> >
> >
> > PS: like to finally do 0.5 this week...
>

Re: Checkstyle change

[Romain Manni-Bucau]

+1

Btw wonder if using java brace style shouldnt be done too (same line as
class, method...instead of a new line)
Le 9 sept. 2013 07:16, "Christian Kaltepoth"  a
écrit :

> I like the idea of checking this automatically. So +1 for that.
>
>
> 2013/9/9 John D. Ament 
>
> > Hi all,
> >
> > I'd like to make a change to our checkstyle file.  Right now, we
> > manually check for leaving out the author javadoc tag.  However, I
> > found a configuration that will enforce it, so the build will fail.
> > I'd like to implement this change for the DS project.
> >
> > Please let me know if anyone objects.
> >
> > John
> >
>
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>

Re: [VOTE] Release Apache DeltaSpike-0.5

[Romain Manni-Bucau]

+1

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



2013/9/11 Mark Struberg 

>
>
>  Hi!
>
> I'd like to call a VOTE for the release of DeltasSpike-0.4.
>
> The staging repo is:
> https://repository.apache.org/content/repositories/orgapachedeltaspike-029/
>
> The tag is available here:
> https://github.com/struberg/deltaspike/tree/deltaspike-project-0.5
> This will get pushed to the ASF repo and merged into the upstream master
> branch once the VOTE succeeded.
>
> The source release is available here:
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-029//org/apache/deltaspike/deltaspike-project/0.5/deltaspike-project-0.5-source-release.zip
>
>
> Release Notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312820&version=12320947
>
> Guide to testing:
> Add the following to your ~/.m2/settings.xml:
>
> 
>   staging
>   
> 
>   apache_staging
>   
> https://repository.apache.org/content/repositories/orgapachedeltaspike-029/
> 
>   true
>   false
> 
>   
> 
>
> Then upgrade your project to 0.5 and build with mvn -Pstaging.
>
> LieGrue,
> your Apache DeltaSpike Team
>

Re: Data module, full replacement for Seam Factories?

[Romain Manni-Bucau]

Hi

I dont get the need, using cdi event + repo looks enough. What do I miss?
Le 14 sept. 2013 02:04, "Jason Porter"  a écrit :

> I was looking at
>
> http://stackoverflow.com/questions/18774025/how-can-i-update-a-collection-that-is-produces-applicationscoped
> and
> the data module came to my mind. I just did a quick glance through the code
> I thought was applicable, but I'm still doubtful it'll actually do what I
> want. Can someone correct me if the data module will actually do this?
>
> If not, it sure sounds like a killer feature to implement. We'd need to
> create events, probably add some more metadata to it, and possibly create
> some beans so there's a concrete class, or perhaps some InvocationHandlers.
>
> --
> Jason Porter
> http://en.gravatar.com/lightguardjp
>

Re: Data module, full replacement for Seam Factories?

[Romain Manni-Bucau]

Got it, thks.
Le 15 sept. 2013 07:32, "Jason Porter"  a écrit :

> It's an ease of use thing. The big thing we're missing (I think) is the
> ability to easily setup @Named lists of entities. Seam 2 @Factory did this
> remarkably well and easily. To do this now (again, I've only glanced
> through the code I think would be responsible for this in the data module)
> you'd need to create a new class for each entity, create a producer and
> listen for the event. It would be great if we could do that all behind the
> scenes for people and expose it simply with an annotation or class or
> something similar.
>
>
> On Sat, Sep 14, 2013 at 12:53 AM, Romain Manni-Bucau
> wrote:
>
> > Hi
> >
> > I dont get the need, using cdi event + repo looks enough. What do I miss?
> > Le 14 sept. 2013 02:04, "Jason Porter"  a
> écrit :
> >
> > > I was looking at
> > >
> > >
> >
> http://stackoverflow.com/questions/18774025/how-can-i-update-a-collection-that-is-produces-applicationscoped
> > > and
> > > the data module came to my mind. I just did a quick glance through the
> > code
> > > I thought was applicable, but I'm still doubtful it'll actually do
> what I
> > > want. Can someone correct me if the data module will actually do this?
> > >
> > > If not, it sure sounds like a killer feature to implement. We'd need to
> > > create events, probably add some more metadata to it, and possibly
> create
> > > some beans so there's a concrete class, or perhaps some
> > InvocationHandlers.
> > >
> > > --
> > > Jason Porter
> > > http://en.gravatar.com/lightguardjp
> > >
> >
>
>
>
> --
> Jason Porter
> http://en.gravatar.com/lightguardjp
>

ConfigSource using ThreadLocal

[Romain Manni-Bucau]

Hi,

I have the following use case: a config is dynamic (typically the url of
the server using arquillian - @ArquillianResource URL url). I need this url
in a config. In prod i use apache-deltaspike.properties or a custom
ConfigSource. I see an easy solution being a ThreadLocal (or a global Map)
backing a TestConfigSource.

The question now: do we provide a default impl answering this need? (maybe
an in memory configuration == map/properties updatable through a static
method)

wdyt?


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

Re: ConfigSource using ThreadLocal

[Romain Manni-Bucau]

It would be a contextual config so in the case of arquillian you'd set it
in the beginning of your  test method.

The point is not if it works but if we can/should support it.

typically how to configure a webservice client url when the port is random?

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



2013/9/25 Jason Porter 

> I'm not sure what good a ThreadLocal is going to give you. Unless you're
> using @InSequence in your tests you're not guaranteed when the tests will
> run and if that ThreadLocal variable will be set. Simply having Arquillian
> inject the URL should be fine. Also if depending on the forking parameter
> with JUnit it may not work anyway.
>
>
> On Wed, Sep 25, 2013 at 5:01 AM, Romain Manni-Bucau
> wrote:
>
> > Hi,
> >
> > I have the following use case: a config is dynamic (typically the url of
> > the server using arquillian - @ArquillianResource URL url). I need this
> url
> > in a config. In prod i use apache-deltaspike.properties or a custom
> > ConfigSource. I see an easy solution being a ThreadLocal (or a global
> Map)
> > backing a TestConfigSource.
> >
> > The question now: do we provide a default impl answering this need?
> (maybe
> > an in memory configuration == map/properties updatable through a static
> > method)
> >
> > wdyt?
> >
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
>
>
>
> --
> Jason Porter
> http://en.gravatar.com/lightguardjp
>

Re: ConfigSource using ThreadLocal

[Romain Manni-Bucau]

Yep but the app doesnt know it and arquillian doesnt have it in packaging
phase (@deployment)
Le 25 sept. 2013 19:51, "Jason Porter"  a écrit :

> In that particular example, in the test, Arquillian knows the URL of the
> server, so the port should already be there, right? Maybe I'm missing
> something.
>
>
> On Wed, Sep 25, 2013 at 10:51 AM, Romain Manni-Bucau
> wrote:
>
> > It would be a contextual config so in the case of arquillian you'd set it
> > in the beginning of your  test method.
> >
> > The point is not if it works but if we can/should support it.
> >
> > typically how to configure a webservice client url when the port is
> random?
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/9/25 Jason Porter 
> >
> > > I'm not sure what good a ThreadLocal is going to give you. Unless
> you're
> > > using @InSequence in your tests you're not guaranteed when the tests
> will
> > > run and if that ThreadLocal variable will be set. Simply having
> > Arquillian
> > > inject the URL should be fine. Also if depending on the forking
> parameter
> > > with JUnit it may not work anyway.
> > >
> > >
> > > On Wed, Sep 25, 2013 at 5:01 AM, Romain Manni-Bucau
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I have the following use case: a config is dynamic (typically the url
> > of
> > > > the server using arquillian - @ArquillianResource URL url). I need
> this
> > > url
> > > > in a config. In prod i use apache-deltaspike.properties or a custom
> > > > ConfigSource. I see an easy solution being a ThreadLocal (or a global
> > > Map)
> > > > backing a TestConfigSource.
> > > >
> > > > The question now: do we provide a default impl answering this need?
> > > (maybe
> > > > an in memory configuration == map/properties updatable through a
> static
> > > > method)
> > > >
> > > > wdyt?
> > > >
> > > >
> > > > *Romain Manni-Bucau*
> > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > > http://rmannibucau.wordpress.com/>
> > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > > *Github: https://github.com/rmannibucau*
> > > >
> > >
> > >
> > >
> > > --
> > > Jason Porter
> > > http://en.gravatar.com/lightguardjp
> > >
> >
>
>
>
> --
> Jason Porter
> http://en.gravatar.com/lightguardjp
>

Re: ConfigSource using ThreadLocal

[Romain Manni-Bucau]

The point is my webservice client is part of my app and then need app
config. The design cant change cause of tests. I can isolate it and mock ut
through cdi but using config source is nicer
Le 25 sept. 2013 20:39, "John D. Ament"  a écrit :

> Yeah... the target path of the deployment isn't available at
> deployment creation.  It's only available after.
>
> When I was doing some webservice testing, i simply instantiated using
> the URL param, not injection of the webservice (I honestly find
> webservice injection to be a bit difficult since endpoints will be
> different in environments).
>
>
>
> On Wed, Sep 25, 2013 at 2:35 PM, Jason Porter 
> wrote:
> > Ah, okay. Now I see.
> >
> >
> > On Wed, Sep 25, 2013 at 12:12 PM, Romain Manni-Bucau
> > wrote:
> >
> >> Yep but the app doesnt know it and arquillian doesnt have it in
> packaging
> >> phase (@deployment)
> >> Le 25 sept. 2013 19:51, "Jason Porter"  a
> écrit :
> >>
> >> > In that particular example, in the test, Arquillian knows the URL of
> the
> >> > server, so the port should already be there, right? Maybe I'm missing
> >> > something.
> >> >
> >> >
> >> > On Wed, Sep 25, 2013 at 10:51 AM, Romain Manni-Bucau
> >> > wrote:
> >> >
> >> > > It would be a contextual config so in the case of arquillian you'd
> set
> >> it
> >> > > in the beginning of your  test method.
> >> > >
> >> > > The point is not if it works but if we can/should support it.
> >> > >
> >> > > typically how to configure a webservice client url when the port is
> >> > random?
> >> > >
> >> > > *Romain Manni-Bucau*
> >> > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> >> > > *Blog: **http://rmannibucau.wordpress.com/*<
> >> > > http://rmannibucau.wordpress.com/>
> >> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >> > > *Github: https://github.com/rmannibucau*
> >> > >
> >> > >
> >> > >
> >> > > 2013/9/25 Jason Porter 
> >> > >
> >> > > > I'm not sure what good a ThreadLocal is going to give you. Unless
> >> > you're
> >> > > > using @InSequence in your tests you're not guaranteed when the
> tests
> >> > will
> >> > > > run and if that ThreadLocal variable will be set. Simply having
> >> > > Arquillian
> >> > > > inject the URL should be fine. Also if depending on the forking
> >> > parameter
> >> > > > with JUnit it may not work anyway.
> >> > > >
> >> > > >
> >> > > > On Wed, Sep 25, 2013 at 5:01 AM, Romain Manni-Bucau
> >> > > > wrote:
> >> > > >
> >> > > > > Hi,
> >> > > > >
> >> > > > > I have the following use case: a config is dynamic (typically
> the
> >> url
> >> > > of
> >> > > > > the server using arquillian - @ArquillianResource URL url). I
> need
> >> > this
> >> > > > url
> >> > > > > in a config. In prod i use apache-deltaspike.properties or a
> custom
> >> > > > > ConfigSource. I see an easy solution being a ThreadLocal (or a
> >> global
> >> > > > Map)
> >> > > > > backing a TestConfigSource.
> >> > > > >
> >> > > > > The question now: do we provide a default impl answering this
> need?
> >> > > > (maybe
> >> > > > > an in memory configuration == map/properties updatable through a
> >> > static
> >> > > > > method)
> >> > > > >
> >> > > > > wdyt?
> >> > > > >
> >> > > > >
> >> > > > > *Romain Manni-Bucau*
> >> > > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> >> > > > > *Blog: **http://rmannibucau.wordpress.com/*<
> >> > > > > http://rmannibucau.wordpress.com/>
> >> > > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >> > > > > *Github: https://github.com/rmannibucau*
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Jason Porter
> >> > > > http://en.gravatar.com/lightguardjp
> >> > > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Jason Porter
> >> > http://en.gravatar.com/lightguardjp
> >> >
> >>
> >
> >
> >
> > --
> > Jason Porter
> > http://en.gravatar.com/lightguardjp
>

Re: ConfigSource using ThreadLocal

[Romain Manni-Bucau]

I was looking for something more portable, in tomee my test passes as you
can guess ;)

But ok, you join my thought: this case shows a "limitation" of
arquillian...that said not sure why url can be passed as @deployment
parameter, it should work in the arq lifecycle imo
Le 26 sept. 2013 06:58, "Mark Struberg"  a écrit :

> I think a ThreadLocal ConfigSource is kind of an anti-pattern.
> Even in your case it looks like this only would work if you start the
> container inplace. But it will not work with remote containers.
>
> But there is nothing which prevents you from registering an own
> ThreadLocalTestConfigSource which you add as  to your tomee, right?
>
> LieGrue,
> strub
>
>
>
>
> - Original Message -
> > From: Romain Manni-Bucau 
> > To: dev@deltaspike.apache.org
> > Cc:
> > Sent: Wednesday, 25 September 2013, 21:49
> > Subject: Re: ConfigSource using ThreadLocal
> >
> >T he point is my webservice client is part of my app and then need app
> > config. The design cant change cause of tests. I can isolate it and mock
> ut
> > through cdi but using config source is nicer
> > Le 25 sept. 2013 20:39, "John D. Ament" 
> > a écrit :
> >
> >>  Yeah... the target path of the deployment isn't available at
> >>  deployment creation.  It's only available after.
> >>
> >>  When I was doing some webservice testing, i simply instantiated using
> >>  the URL param, not injection of the webservice (I honestly find
> >>  webservice injection to be a bit difficult since endpoints will be
> >>  different in environments).
> >>
> >>
> >>
> >>  On Wed, Sep 25, 2013 at 2:35 PM, Jason Porter
> > 
> >>  wrote:
> >>  > Ah, okay. Now I see.
> >>  >
> >>  >
> >>  > On Wed, Sep 25, 2013 at 12:12 PM, Romain Manni-Bucau
> >>  > wrote:
> >>  >
> >>  >> Yep but the app doesnt know it and arquillian doesnt have it in
> >>  packaging
> >>  >> phase (@deployment)
> >>  >> Le 25 sept. 2013 19:51, "Jason Porter"
> >  a
> >>  écrit :
> >>  >>
> >>  >> > In that particular example, in the test, Arquillian knows the
> > URL of
> >>  the
> >>  >> > server, so the port should already be there, right? Maybe
> > I'm missing
> >>  >> > something.
> >>  >> >
> >>  >> >
> >>  >> > On Wed, Sep 25, 2013 at 10:51 AM, Romain Manni-Bucau
> >>  >> > wrote:
> >>  >> >
> >>  >> > > It would be a contextual config so in the case of
> > arquillian you'd
> >>  set
> >>  >> it
> >>  >> > > in the beginning of your  test method.
> >>  >> > >
> >>  >> > > The point is not if it works but if we can/should
> > support it.
> >>  >> > >
> >>  >> > > typically how to configure a webservice client url when
> > the port is
> >>  >> > random?
> >>  >> > >
> >>  >> > > *Romain Manni-Bucau*
> >>  >> > > *Twitter: @rmannibucau
> > <https://twitter.com/rmannibucau>*
> >>  >> > > *Blog: **http://rmannibucau.wordpress.com/*<
> >>  >> > > http://rmannibucau.wordpress.com/>
> >>  >> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >>  >> > > *Github: https://github.com/rmannibucau*
> >>  >> > >
> >>  >> > >
> >>  >> > >
> >>  >> > > 2013/9/25 Jason Porter 
> >>  >> > >
> >>  >> > > > I'm not sure what good a ThreadLocal is going
> > to give you. Unless
> >>  >> > you're
> >>  >> > > > using @InSequence in your tests you're not
> > guaranteed when the
> >>  tests
> >>  >> > will
> >>  >> > > > run and if that ThreadLocal variable will be set.
> > Simply having
> >>  >> > > Arquillian
> >>  >> > > > inject the URL should be fine. Also if depending on
> > the forking
> >>  >> > parameter
> >>  >> > > > with JUnit it may not work anyway.
> >>  >> > > >
> >>  >> > > 

Re: ConfigSource using ThreadLocal

[Romain Manni-Bucau]

Yep, I'll ping him today on IRC

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



2013/9/26 Jason Porter 

> Bring it up to Aslak. I highly doubt he's watching this list.
>
>
> On Wed, Sep 25, 2013 at 11:02 PM, Romain Manni-Bucau
> wrote:
>
> > I was looking for something more portable, in tomee my test passes as you
> > can guess ;)
> >
> > But ok, you join my thought: this case shows a "limitation" of
> > arquillian...that said not sure why url can be passed as @deployment
> > parameter, it should work in the arq lifecycle imo
> > Le 26 sept. 2013 06:58, "Mark Struberg"  a écrit :
> >
> > > I think a ThreadLocal ConfigSource is kind of an anti-pattern.
> > > Even in your case it looks like this only would work if you start the
> > > container inplace. But it will not work with remote containers.
> > >
> > > But there is nothing which prevents you from registering an own
> > > ThreadLocalTestConfigSource which you add as  to your tomee,
> right?
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > >
> > > - Original Message -
> > > > From: Romain Manni-Bucau 
> > > > To: dev@deltaspike.apache.org
> > > > Cc:
> > > > Sent: Wednesday, 25 September 2013, 21:49
> > > > Subject: Re: ConfigSource using ThreadLocal
> > > >
> > > >T he point is my webservice client is part of my app and then need app
> > > > config. The design cant change cause of tests. I can isolate it and
> > mock
> > > ut
> > > > through cdi but using config source is nicer
> > > > Le 25 sept. 2013 20:39, "John D. Ament" 
> > > > a écrit :
> > > >
> > > >>  Yeah... the target path of the deployment isn't available at
> > > >>  deployment creation.  It's only available after.
> > > >>
> > > >>  When I was doing some webservice testing, i simply instantiated
> using
> > > >>  the URL param, not injection of the webservice (I honestly find
> > > >>  webservice injection to be a bit difficult since endpoints will be
> > > >>  different in environments).
> > > >>
> > > >>
> > > >>
> > > >>  On Wed, Sep 25, 2013 at 2:35 PM, Jason Porter
> > > > 
> > > >>  wrote:
> > > >>  > Ah, okay. Now I see.
> > > >>  >
> > > >>  >
> > > >>  > On Wed, Sep 25, 2013 at 12:12 PM, Romain Manni-Bucau
> > > >>  > wrote:
> > > >>  >
> > > >>  >> Yep but the app doesnt know it and arquillian doesnt have it in
> > > >>  packaging
> > > >>  >> phase (@deployment)
> > > >>  >> Le 25 sept. 2013 19:51, "Jason Porter"
> > > >  a
> > > >>  écrit :
> > > >>  >>
> > > >>  >> > In that particular example, in the test, Arquillian knows the
> > > > URL of
> > > >>  the
> > > >>  >> > server, so the port should already be there, right? Maybe
> > > > I'm missing
> > > >>  >> > something.
> > > >>  >> >
> > > >>  >> >
> > > >>  >> > On Wed, Sep 25, 2013 at 10:51 AM, Romain Manni-Bucau
> > > >>  >> > wrote:
> > > >>  >> >
> > > >>  >> > > It would be a contextual config so in the case of
> > > > arquillian you'd
> > > >>  set
> > > >>  >> it
> > > >>  >> > > in the beginning of your  test method.
> > > >>  >> > >
> > > >>  >> > > The point is not if it works but if we can/should
> > > > support it.
> > > >>  >> > >
> > > >>  >> > > typically how to configure a webservice client url when
> > > > the port is
> > > >>  >> > random?
> > > >>  >> > >
> > > >>  >> > > *Romain Manni-Bucau*
> > > >>  >> > > *Twitter: @rmannibucau
> > > > <https://twitter.c

Re: Data Module

[Romain Manni-Bucau]

Hi

any news on it?

@ResultMapper was good to me

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



2013/7/12 Jason Porter 

> On Fri, Jul 12, 2013 at 12:13 AM, Romain Manni-Bucau
> wrote:
>
> > Ps: you can make a cdi bean an ejb from cdi extension
> >
>
> No, the bootstrapping for each container do not communicate to my
> knowledge.
>
>
> > Le 12 juil. 2013 08:12, "Romain Manni-Bucau"  a
> > écrit :
> >
> > > Hi
> > >
> > > Depending the case DTO are not an option.
> > >
> > > I agree in rest app i wouldnt it but if not possible (maybe through
> > > another Bean) it would kill this module for half of the usages i see
> > since
> > > i'd need to add this layer.
> > > Le 12 juil. 2013 06:55, "hantsy"  a écrit :
> > >
> > >> No DTO please, data module for data access, why we care about DTO.
> > >>
> > >> A question about the data, the difference for EJB and none EJB
> > >> environment.
> > >>
> > >> if possible in a EJB envoriment, proxy the Repository and add
> @Stateless
> > >> and transaction declaration to Repository automatically at runtime.
> > >>
> > >> Regards
> > >>
> > >> Hantsy
> > >> On 7/10/2013 23:23, Thomas Hug wrote:
> > >> > I wouldn't label the feature with DTO but rather as some general
> > result
> > >> > transformation - might also be useful for e.g. native queries. Going
> > >> back
> > >> > to the API suggestion, from that perspective such an annotation
> should
> > >> > probably also work on method level, so I'd keep the forEntity out
> > there.
> > >> >
> > >> >
> > >> > On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament <
> > john.d.am...@gmail.com
> > >> >wrote:
> > >> >
> > >> >> Personally, I don't like this idea.
> > >> >>
> > >> >> A DAO should do DAO stuff.
> > >> >> A DTO should do DTO stuff.
> > >> >>
> > >> >> The transformation of your entities into some other POJO shouldn't
> be
> > >> >> inside your DAO.
> > >> >>
> > >> >> Right now, I use google guava to do DTO work on entities going back
> > and
> > >> >> forth over a REST API.  Works well IMHO.
> > >> >>
> > >> >> John
> > >> >>
> > >> >>
> > >> >> On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
> > >> >> wrote:
> > >> >>
> > >> >>> globally my answer meant "if forEntity is sometimes mandatory,
> > >> sometimes
> > >> >>> not this is maybe not the right place"
> > >> >>>
> > >> >>> i thought to add it to mapper config
> > >> >>>
> > >> >>> *Romain Manni-Bucau*
> > >> >>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > >> >>> *Blog: **http://rmannibucau.wordpress.com/*<
> > >> >>> http://rmannibucau.wordpress.com/>
> > >> >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > >> >>> *Github: https://github.com/rmannibucau*
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> 2013/7/10 Thomas Hug 
> > >> >>>
> > >> >>>> Making forEntity non-optional would then be redundant for the
> > regular
> > >> >>> cases
> > >> >>>> using the base interface, so I wouldn't. But I see that it should
> > be
> > >> >>>> clearly documented then as things might get confusing...
> > >> >>>>
> > >> >>>>
> > >> >>>> On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau
> > >> >>>> wrote:
> > >> >>>>
> > >> >>>>> do you mean you force forEntity = Person.class?
> > >> >>>>>
> > >> >>>>> looks ok for me since the only constraint is 

Re: Data Module

[Romain Manni-Bucau]

Not particularly

the thread ends while the feature is useful IMO so simply asking what to do
next ;)

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



2013/10/1 Jason Porter 

> Was this my action item?
>
> Sent from my iPhone
>
> > On Oct 1, 2013, at 7:43, Romain Manni-Bucau 
> wrote:
> >
> > Hi
> >
> > any news on it?
> >
> > @ResultMapper was good to me
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/7/12 Jason Porter 
> >
> >> On Fri, Jul 12, 2013 at 12:13 AM, Romain Manni-Bucau
> >> wrote:
> >>
> >>> Ps: you can make a cdi bean an ejb from cdi extension
> >>>
> >>
> >> No, the bootstrapping for each container do not communicate to my
> >> knowledge.
> >>
> >>
> >>> Le 12 juil. 2013 08:12, "Romain Manni-Bucau"  a
> >>> écrit :
> >>>
> >>>> Hi
> >>>>
> >>>> Depending the case DTO are not an option.
> >>>>
> >>>> I agree in rest app i wouldnt it but if not possible (maybe through
> >>>> another Bean) it would kill this module for half of the usages i see
> >>> since
> >>>> i'd need to add this layer.
> >>>> Le 12 juil. 2013 06:55, "hantsy"  a écrit :
> >>>>
> >>>>> No DTO please, data module for data access, why we care about DTO.
> >>>>>
> >>>>> A question about the data, the difference for EJB and none EJB
> >>>>> environment.
> >>>>>
> >>>>> if possible in a EJB envoriment, proxy the Repository and add
> >> @Stateless
> >>>>> and transaction declaration to Repository automatically at runtime.
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>> Hantsy
> >>>>>> On 7/10/2013 23:23, Thomas Hug wrote:
> >>>>>> I wouldn't label the feature with DTO but rather as some general
> >>> result
> >>>>>> transformation - might also be useful for e.g. native queries. Going
> >>>>> back
> >>>>>> to the API suggestion, from that perspective such an annotation
> >> should
> >>>>>> probably also work on method level, so I'd keep the forEntity out
> >>> there.
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament <
> >>> john.d.am...@gmail.com
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Personally, I don't like this idea.
> >>>>>>>
> >>>>>>> A DAO should do DAO stuff.
> >>>>>>> A DTO should do DTO stuff.
> >>>>>>>
> >>>>>>> The transformation of your entities into some other POJO shouldn't
> >> be
> >>>>>>> inside your DAO.
> >>>>>>>
> >>>>>>> Right now, I use google guava to do DTO work on entities going back
> >>> and
> >>>>>>> forth over a REST API.  Works well IMHO.
> >>>>>>>
> >>>>>>> John
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> globally my answer meant "if forEntity is sometimes mandatory,
> >>>>> sometimes
> >>>>>>>> not this is maybe not the right place"
> >>>>>>>>
> >>>>>>>> i thought to add it to mapper config
> >>>>>>>>
> >>>>>>>> *Romain Manni-Bucau*
> >>>>>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> >>>>>>>> *Blog: **http://rmannibucau.wordpress.com

org.apache.deltaspike.data.impl.handler.EntityManagerLookup broken?

[Romain Manni-Bucau]

Hi,

in org.apache.deltaspike.data.impl.handler.EntityManagerLookup#lookupFor we
use the em resolver then we return the entityManager.get() instead of the
result. Is it intended?

Why not using a qualifier to resolve the em? It was easier IMO

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

Re: org.apache.deltaspike.data.impl.handler.EntityManagerLookup broken?

[Romain Manni-Bucau]

If it possible to have both behavior? Adding a class for it while you can
have in some kind of project a module qualifier is too much IMO. Supporting
both in the em lookup impl should be easy.

PS: whatever the answer to previous question is, is it possible to get a
0.5.1 soon with the fix?

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



2013/10/2 Thomas Hug 

> Hi Romain,
> if I remember correctly the idea with a resolver was to make things
> consistent over DS (similar constructs in the JSF module).
> ...and yes, there's a return missing (d'oh!). Will create a ticket / fix.
>
>
> On Tue, Oct 1, 2013 at 6:39 PM, Romain Manni-Bucau  >wrote:
>
> > Hi,
> >
> > in org.apache.deltaspike.data.impl.handler.EntityManagerLookup#lookupFor
> we
> > use the em resolver then we return the entityManager.get() instead of the
> > result. Is it intended?
> >
> > Why not using a qualifier to resolve the em? It was easier IMO
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
>

Re: Renaming @ViewRef config property?

[Romain Manni-Bucau]

+1, same for @ConfigProperty btw
Le 3 oct. 2013 20:49, "Gerhard Petracek"  a
écrit :

> -0.5 for now
> once we add more, you get the same and it would be not that expressive.
> that was the reason for changing it (compared to codi).
>
> regards,
> gerhard
>
>
>
> 2013/10/3 Thomas Andraschko 
>
> > Hi,
> >
> > currently @ViewRef has only one property called "config".
> >
> > So the current usage is:
> > @ViewRef(config = Views.Logout.class)
> >
> > What about renaming it to "value"?
> > -> @ViewRef(Views.Logout.class)
> >
> > Regards,
> > Thomas
> >
>

Re: Renaming @ViewRef config property?

[Romain Manni-Bucau]

If config is the unique mandatory attr it should be value imo
Le 3 oct. 2013 22:39, "Gerhard Petracek"  a
écrit :

> hi thomas,
>
> yes - we had something in codi and we might add something like the payload
> in bv.
>
> regards,
> gerhard
>
>
>
> 2013/10/3 Thomas Andraschko 
>
> > @Gerhard: Are there any expected properties on @ViewRef in the future?
> >
> >
> > 2013/10/3 Romain Manni-Bucau 
> >
> > > +1, same for @ConfigProperty btw
> > > Le 3 oct. 2013 20:49, "Gerhard Petracek" 
> a
> > > écrit :
> > >
> > > > -0.5 for now
> > > > once we add more, you get the same and it would be not that
> expressive.
> > > > that was the reason for changing it (compared to codi).
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2013/10/3 Thomas Andraschko 
> > > >
> > > > > Hi,
> > > > >
> > > > > currently @ViewRef has only one property called "config".
> > > > >
> > > > > So the current usage is:
> > > > > @ViewRef(config = Views.Logout.class)
> > > > >
> > > > > What about renaming it to "value"?
> > > > > -> @ViewRef(Views.Logout.class)
> > > > >
> > > > > Regards,
> > > > > Thomas
> > > > >
> > > >
> > >
> >
>

Re: Renaming @ViewRef config property?

[Romain Manni-Bucau]

I didnt use viewref enough to say but typically it is boring to need to
write name in configproperty each time while you know what it is. Moreover
for viewref, config doesnt sound really right, metadata or marker sounds as
right as config depending where you are coming from.

Well this doesnt hold features so i dont want to loose time in it but now
you know why i like value ;)
Le 3 oct. 2013 23:21, "Gerhard Petracek"  a
écrit :

> -0.5 (instead of -1), because i used "value" in codi back then and there is
> nothing wrong with it.
> however, that was one of the lessons learned from using it in projects and
> explaining it in trainings for almost three years.
> what we have right now just reflects the feedback.
>
> regards,
> gerhard
>
>
>
> 2013/10/3 Romain Manni-Bucau 
>
> > If config is the unique mandatory attr it should be value imo
> > Le 3 oct. 2013 22:39, "Gerhard Petracek"  a
> > écrit :
> >
> > > hi thomas,
> > >
> > > yes - we had something in codi and we might add something like the
> > payload
> > > in bv.
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2013/10/3 Thomas Andraschko 
> > >
> > > > @Gerhard: Are there any expected properties on @ViewRef in the
> future?
> > > >
> > > >
> > > > 2013/10/3 Romain Manni-Bucau 
> > > >
> > > > > +1, same for @ConfigProperty btw
> > > > > Le 3 oct. 2013 20:49, "Gerhard Petracek" <
> gerhard.petra...@gmail.com
> > >
> > > a
> > > > > écrit :
> > > > >
> > > > > > -0.5 for now
> > > > > > once we add more, you get the same and it would be not that
> > > expressive.
> > > > > > that was the reason for changing it (compared to codi).
> > > > > >
> > > > > > regards,
> > > > > > gerhard
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2013/10/3 Thomas Andraschko 
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > currently @ViewRef has only one property called "config".
> > > > > > >
> > > > > > > So the current usage is:
> > > > > > > @ViewRef(config = Views.Logout.class)
> > > > > > >
> > > > > > > What about renaming it to "value"?
> > > > > > > -> @ViewRef(Views.Logout.class)
> > > > > > >
> > > > > > > Regards,
> > > > > > > Thomas
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: git commit: DELTASPIKE-424 taking into account EntityManagerResolver with a normal scope

[Romain Manni-Bucau]

Both works Mark depending as you said from where you take your em. We just
need to be explicit on this behavior. BTW I prefer the normal scope usage
too.

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



2013/10/10 Mark Struberg 

> Not sure if we really need this flag.
> The most important question to me is _when_ do we trigger the destroy()
> method.
>
> The following code doesn't make much sense imo:
>
> > final DependentProvider resolver =
> lookupResolver(emrc);
> > result = resolver.get().resolveEntityManager();
> > resolver.destroy();
>
>
> The DependentProvider is intended to store it's instances somewhere to be
> able to properly destroy the created @Dependent instance once you don't
> need it anymore. Invoking destroy() immediately but returning the created
> contextual instance makes no sense imo. Imagine what happens if you would
> close the EntityManagerFactory in a @PreDestroy method.
>
> If there is no clean way to clean up the instance again, then we should
> only rely on NormalScoped instances and remove the handling (and get the
> warnings again, because they make sense).
>
> LieGrue,
> strub
>
>
>
>
>
>
>
> - Original Message -
> > From: "rmannibu...@apache.org" 
> > To: comm...@deltaspike.apache.org
> > Cc:
> > Sent: Wednesday, 9 October 2013, 16:46
> > Subject: git commit: DELTASPIKE-424 taking into account
> EntityManagerResolver with a normal scope
> >
> > Updated Branches:
> >   refs/heads/master bdc9cdce6 -> e8148110e
> >
> >
> > DELTASPIKE-424 taking into account EntityManagerResolver with a normal
> scope
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/deltaspike/repo
> > Commit:
> http://git-wip-us.apache.org/repos/asf/deltaspike/commit/e8148110
> > Tree: http://git-wip-us.apache.org/repos/asf/deltaspike/tree/e8148110
> > Diff: http://git-wip-us.apache.org/repos/asf/deltaspike/diff/e8148110
> >
> > Branch: refs/heads/master
> > Commit: e8148110ea2458fa2244a439583da0f2adddb482
> > Parents: bdc9cdc
> > Author: Romain Manni-Bucau 
> > Authored: Wed Oct 9 16:46:06 2013 +0200
> > Committer: Romain Manni-Bucau 
> > Committed: Wed Oct 9 16:46:06 2013 +0200
> >
> > --
> > .../data/impl/RepositoryExtension.java  |  2 +-
> > .../data/impl/handler/EntityManagerLookup.java  | 20 +++--
> > .../data/impl/meta/RepositoryComponent.java | 23 +++-
> > .../data/impl/meta/RepositoryComponents.java| 16 --
> > .../data/impl/builder/part/QueryRootTest.java   |  5 ++---
> > 5 files changed, 47 insertions(+), 19 deletions(-)
> > --
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/deltaspike/blob/e8148110/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/RepositoryExtension.java
> > --
> > diff --git
> >
> a/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/RepositoryExtension.java
> >
> b/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/RepositoryExtension.java
> > index 076393b..8ba0dca 100755
> > ---
> >
> a/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/RepositoryExtension.java
> > +++
> >
> b/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/RepositoryExtension.java
> > @@ -72,7 +72,7 @@ public class RepositoryExtension implements Extension
> >  {
> >  log.log(Level.FINER, "getHandlerClass: Repository
> > annotation detected on {0}",
> >  event.getAnnotatedType());
> > -RepositoryComponentsFactory.instance().add(repoClass);
> > +RepositoryComponentsFactory.instance().add(repoClass,
> > beanManager);
> >  }
> >  catch (RepositoryDefinitionException e)
> >  {
> >
> >
> http://git-wip-us.apache.org/repos/asf/deltaspike/blob/e8148110/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/handler/EntityManagerLookup.java
> > --
> > diff --git
&g

Re: git commit: DELTASPIKE-424 taking into account EntityManagerResolver with a normal scope

[Romain Manni-Bucau]

If you don't destroy it you'll likely leak.

And once again you are in your case where you handle the emf yourself. In
other cases @Dependent should work fine.

That said nothing again preventing using @Dependent so just do it If it
solves the issue. Normal scopes were the important part for me.

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



2013/10/10 Mark Struberg 

>
> >Both works
>
> That's exactly where I disagree. While both 'work' in the sample,
> immediately destroying the instances again after creating them - and only
> later returning the java reference to the now 'dead' EntityManagerResolver
> - is broken if you will use it in productive scenarios.
>
>
> Either we fix this, or we don't need any special handling. In this case I
> suggest to just use DependentProvider.get() for all cases. It has no harm
> on NormalScoped instances anyway.
>
> I will guard DependentProvider#destroy to not have any impact on
> @Dependent scoped instances.
>
>
> LieGrue,
> strub
>
>
> >
> > From: Romain Manni-Bucau 
> >To: "dev@deltaspike.apache.org" ; Mark
> Struberg 
> >Sent: Thursday, 10 October 2013, 8:33
> >Subject: Re: git commit: DELTASPIKE-424 taking into account
> EntityManagerResolver with a normal scope
> >
> >
> >
> >Both works Mark depending as you said from where you take your em. We
> just need to be explicit on this behavior. BTW I prefer the normal scope
> usage too.
> >
> >
> >Romain Manni-Bucau
> >Twitter: @rmannibucau
> >Blog: http://rmannibucau.wordpress.com/
> >LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >Github: https://github.com/rmannibucau
> >
> >
> >
> >
> >2013/10/10 Mark Struberg 
> >
> >Not sure if we really need this flag.
> >>The most important question to me is _when_ do we trigger the destroy()
> method.
> >>
> >>The following code doesn't make much sense imo:
> >>
> >>> final DependentProvider resolver =
> lookupResolver(emrc);
> >>> result = resolver.get().resolveEntityManager();
> >>> resolver.destroy();
> >>
> >>
> >>The DependentProvider is intended to store it's instances somewhere to
> be able to properly destroy the created @Dependent instance once you don't
> need it anymore. Invoking destroy() immediately but returning the created
> contextual instance makes no sense imo. Imagine what happens if you would
> close the EntityManagerFactory in a @PreDestroy method.
> >>
> >>If there is no clean way to clean up the instance again, then we should
> only rely on NormalScoped instances and remove the handling (and get the
> warnings again, because they make sense).
> >>
> >>LieGrue,
> >>strub
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>- Original Message -
> >>> From: "rmannibu...@apache.org" 
> >>> To: comm...@deltaspike.apache.org
> >>> Cc:
> >>> Sent: Wednesday, 9 October 2013, 16:46
> >>> Subject: git commit: DELTASPIKE-424 taking into account
> EntityManagerResolver with a normal scope
> >>>
> >>> Updated Branches:
> >>>   refs/heads/master bdc9cdce6 -> e8148110e
> >>>
> >>>
> >>> DELTASPIKE-424 taking into account EntityManagerResolver with a normal
> scope
> >>>
> >>>
> >>> Project: http://git-wip-us.apache.org/repos/asf/deltaspike/repo
> >>> Commit:
> http://git-wip-us.apache.org/repos/asf/deltaspike/commit/e8148110
> >>> Tree: http://git-wip-us.apache.org/repos/asf/deltaspike/tree/e8148110
> >>> Diff: http://git-wip-us.apache.org/repos/asf/deltaspike/diff/e8148110
> >>>
> >>> Branch: refs/heads/master
> >>> Commit: e8148110ea2458fa2244a439583da0f2adddb482
> >>> Parents: bdc9cdc
> >>> Author: Romain Manni-Bucau 
> >>> Authored: Wed Oct 9 16:46:06 2013 +0200
> >>> Committer: Romain Manni-Bucau 
> >>> Committed: Wed Oct 9 16:46:06 2013 +0200
> >>>
> >>> --
> >>> .../data/impl/RepositoryExtension.java  |  2 +-
> >>> .../data/impl/handler/EntityManagerLookup.java  |

Re: git commit: DELTASPIKE-424 taking into account EntityManagerResolver with a normal scope

[Romain Manni-Bucau]

@Mark: if we add the constraint to not use other scoped injections it would
work...but I agree it is maybe a big constraint since the em will often be
@ReqScoped

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



2013/10/11 Karl Kildén 

> Hello!
>
> I have some trouble understanding why it's bad to destroy the instance with
> that example. What about this example, does it make sense?
>
> DependentProvider ctxControl =
> BeanProvider.getDependent(ContextControl.class);
>
> ctxControl.get().startContext(ApplicationScoped.class);
> // Do something useful in for example a Quartz Job
>
> ctxControl.destroy();
>
> cheers
>
>
>
>
> On 11 October 2013 10:15, Mark Struberg  wrote:
>
> >
> > >If you don't destroy it you'll likely leak.
> > Yes, fully agree. But the way we do it is still wrong. IF it is a
> > @Dependent scoped instance, then we must store the
> > DependentProvider somewhere and only invoke it's destroy()
> > method once we really need.
> >
> > For NormalScoped beans you are relieved of this burden, but for
> @Dependent
> > ones you need to handle it manually. The DependentProvider just helps to
> > easily store the CreationalContext, the Bean and the instance for
> > convenience reasons.
> >
> >
> > LieGrue,
> > strub
> >
> >
> > >
> > > From: Romain Manni-Bucau 
> > >To: "dev@deltaspike.apache.org" ; Mark
> > Struberg 
> > >Sent: Thursday, 10 October 2013, 9:07
> > >Subject: Re: git commit: DELTASPIKE-424 taking into account
> > EntityManagerResolver with a normal scope
> > >
> > >
> > >If you don't destroy it you'll likely leak.
> > >
> > >And once again you are in your case where you handle the emf yourself.
> In
> > >other cases @Dependent should work fine.
> > >
> > >That said nothing again preventing using @Dependent so just do it If it
> > >solves the issue. Normal scopes were the important part for me.
> > >
> > >*Romain Manni-Bucau*
> > >*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > >*Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > >*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > >*Github: https://github.com/rmannibucau*
> > >
> > >
> > >
> > >
> > >2013/10/10 Mark Struberg 
> > >
> > >>
> > >> >Both works
> > >>
> > >> That's exactly where I disagree. While both 'work' in the sample,
> > >> immediately destroying the instances again after creating them - and
> > only
> > >> later returning the java reference to the now 'dead'
> > EntityManagerResolver
> > >> - is broken if you will use it in productive scenarios.
> > >>
> > >>
> > >> Either we fix this, or we don't need any special handling. In this
> case
> > I
> > >> suggest to just use DependentProvider.get() for all cases. It has no
> > harm
> > >> on NormalScoped instances anyway.
> > >>
> > >> I will guard DependentProvider#destroy to not have any impact on
> > >> @Dependent scoped instances.
> > >>
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>
> > >> >
> > >> > From: Romain Manni-Bucau 
> > >> >To: "dev@deltaspike.apache.org" ; Mark
> > >> Struberg 
> > >> >Sent: Thursday, 10 October 2013, 8:33
> > >> >Subject: Re: git commit: DELTASPIKE-424 taking into account
> > >> EntityManagerResolver with a normal scope
> > >> >
> > >> >
> > >> >
> > >> >Both works Mark depending as you said from where you take your em. We
> > >> just need to be explicit on this behavior. BTW I prefer the normal
> scope
> > >> usage too.
> > >> >
> > >> >
> > >> >Romain Manni-Bucau
> > >> >Twitter: @rmannibucau
> > >> >Blog: http://rmannibucau.wordpress.com/
> > >> >LinkedIn: http://fr.linkedin.com/in/rmannibucau
>

Re: CDI ContextControl - only available in SE mode?

[Romain Manni-Bucau]

@AppScope will work for sure but other scopes would need to be
initialized/resetted. There isn't enough link between jsr 236 and cdi to
suppose it but CDI tend to impose container to start request/session scopes
if not already started so I think it can work out of the box, no?

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



2013/10/14 Mark Struberg 

> Hmm, I remember talking with Romain about this a few months ago and if I
> remember correctly we had the conclusion that at least @ApplicationScoped
> context and @RequestScoped context needs to be set up. But I'd be happy to
> learn that this is not the case.
> We could also redirect this question to the EE or EJB EG which seems to
> have been in charge about the concurrency util integration into EE7.
>
>
> In any case ContextControl should work :)
>
> LieGrue,
> strub
>
>
>
> - Original Message -
> > From: Martin Kouba 
> > To: dev@deltaspike.apache.org
> > Cc:
> > Sent: Monday, 14 October 2013, 10:00
> > Subject: Re: CDI ContextControl - only available in SE mode?
> >
> > Dne 14.10.2013 09:22, Mark Struberg napsal(a):
> >>  Hi John!
> >>
> >>  Yes, the ContextControl is also designed for being used in JavaEE.
> This is
> > very helpful if you need to manually for new threads which need CDI setup
> > properly in JavaEE6 or a pure Servlet container based environment.
> >>
> >>  In JavaEE7 you should be able to utilize JSR-236 "concurrency utils
> > for JavaEE" to create a 'Managed Thread' which has at least the
> > @RequestScoped and @ApplicationScoped contexts set up properly.
> >>  Still you can use the ContextControl to start a dummy @RequestScoped
> > context even in this case.
> >
> > Mark, I think JSR-236 only comments on using CDI beans as tasks, it says
> > nothing about CDI context propagation. WRT JSR-236 it seems the
> > container must only support propagation of JNDI naming context,
> > classloader, and security information. So I think request context is not
> > set up properly. The application context should be ok. Maybe I'm missing
> > something...
> >
> >
> >>
> >>
> >>  There are of course a few restriction in jsr-236. You can read more
> about
> > it in section "2.3.2.1 Tasks and Contexts and Dependency Injection
> > (CDI)". In that case ContextControl could be an easy way to work around
> it.
> >>
> >>
> >>  hth.
> >>
> >>  LieGrue,
> >>  strub
> >>
> >>
> >>
> >>  - Original Message -
> >>>  From: John D. Ament 
> >>>  To: dev@deltaspike.apache.org
> >>>  Cc:
> >>>  Sent: Monday, 14 October 2013, 0:59
> >>>  Subject: Re: CDI ContextControl - only available in SE mode?
> >>>
> >>>  Interesting.  I guess my big curiosity is that it was "shipped in
> > 0.4"
> >>>  but it's not clear what was shipped.  Better handling if you're
> > in EE
> >>>  so that it doesn't crash?
> >>>
> >>>  Clearly yes, you shouldn't be able to boot weld if you're
> > already in
> >>>  EE, but I'm more interested in starting contexts.
> >>>
> >>>
> >>>  On Sun, Oct 13, 2013 at 4:17 PM, Karl Kildén
> > 
> >>>  wrote:
> >>>>   Hi. It works for OWB.
> >>>>
> >>>>   See: https://issues.apache.org/jira/browse/DELTASPIKE-284
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>   On 13 October 2013 21:29, John D. Ament
> > 
> >>>  wrote:
> >>>>
> >>>>>   Hey guys,
> >>>>>
> >>>>>   Just wanted to check with everyone.  Looking at the
> > documentation
> >>>>>   around context control, it seems a little puzzling and wanted
> > to get
> >>>>>   others opinions.
> >>>>>
> >>>>>   I don't need to be in SE mode to start a context manually,
> > right?
> >>>>>
> >>>>>   The docs seem to imply this, but if I'm already in a CDI
> > container
> >>>>>   doing work, I should be able to inject ContextControl to my
> > class and
> >>>>>   start a new context right?  I'd need to look up the bean,
> > e.g.
> >>>  through
> >>>>>   BeanManager but it should work in theory, right?
> >>>>>
> >>>>>   If we agree it should work, I can update the docs to make it
> > clearer,
> >>>>>   as right now it looks like it should only work in SE mode.
> >>>>>
> >>>>>   Thanks,
> >>>>>
> >>>>>   John
> >>>>>
> >>>
> >
>

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

[Romain Manni-Bucau]

Well if code is released it should be stable or explicitely in
alpha/beta..maybe we should do subreleases for unstables modules
Le 11 nov. 2013 18:43, "Mark Struberg"  a écrit :

> Oki folks, txs 4 the feedback, all!
>
>
> I'd say we should create the module-maturity-matrix.md first and then we
> might do the version bump.
> Maybe something like green/blue/orange/red for mature / ready but still
> needs a few features / ready but might change it's api still / work in
> progress
>
>
> LieGrue,
> strub
>
>
>
>
> - Original Message -
> > From: Charles Moulliard 
> > To: dev@deltaspike.apache.org
> > Cc: Mark Struberg 
> > Sent: Monday, 11 November 2013, 18:25
> > Subject: Re: [DISCUSS] next release version? 0.6 or 1.0?
> >
> > +1 to move to 1.0. We have done the same thing with Apache Aries moving
> > Blueprint from 0.5 to 1.0 release
> >
> >
> >
> > On Mon, Nov 11, 2013 at 6:17 PM, John D. Ament
> > wrote:
> >
> >>  Yep, agreed.  Users care about the version #.  I would recommend that
> if we
> >>  could release a 1.0 based on the current code base + some additional
> bug
> >>  fixes we'll get huge wins.
> >>
> >>  +1 to switching current to 1.0.0-SNAPSHOT.
> >>
> >>
> >>  On Mon, Nov 11, 2013 at 12:08 PM, Mark Struberg 
> > wrote:
> >>
> >>  > Hi!
> >>  >
> >>  > In the last 2 months I did a few conference talks and smaller
> >>  > presentations (OpenBlend, W-JAX, ..) and always got the same
> > questions:
> >>  > "it's only a 0.x version, so is it already stable? I
> > don't like to use it
> >>  > in production with 0.x"
> >>  >
> >>  > And the actual answer is: "well, core, cdictrl, etc are stable
> > since a
> >>  > long time, other modules are not yet 100% where we like them".
> >>  >
> >>  > The other fact is that we will never get all our modules 100% stable.
> >>  > Because new modules cannot be released with the same quality than
> >>  > established and well known and bugfixed modules.
> >>  >
> >>  > Thus I think we should rather introduce a kind of majurity-matrix for
> >>  > DeltaSpike.
> >>  > A simple list of modules and their majurity grade.
> >>  >
> >>  >
> >>  >
> >>  > By officially moving to 1.0 we would gain much more users.
> >>  > I personally do not care about numbers, but LOTS of users do!
> >>  >
> >>  > Wdyt?
> >>  >
> >>  > LieGrue,
> >>  > strub
> >>  >
> >>
> >
> >
> >
> > --
> > Charles Moulliard
> > Apache Committer / Architect @RedHat
> > Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io
> >
>

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

[Romain Manni-Bucau]

+1 for v1. If we don't go back (= we don't make unstable stable
modules) it is enough IMO

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

[Romain Manni-Bucau]

@Thomas: does 1 mean "we can replace codi" or "you can use me".

I think the initial statement is right: if we dont do a 1 (foe Xmas?) We'll
not get that much users.

The version mainly constraint us to be stable on package and existing
signatures (for code, doc etc are needed too), not really more IMO.
Le 13 nov. 2013 04:00, "Thomas Andraschko"  a
écrit :

> -1 for 1.0 - till adding the most important features from CODI (e.g.
> ViewAccessScoped)
>
>
> 2013/11/12 Gerhard Petracek 
>
> > the minimum before v1:
> > everybody documents the feature/s they added (/helped with) within the
> next
> > weeks.
> > (for sure the rest is very welcome to join and/or provide feedback.)
> > if we don't handle it as a blocker for v1, it won't happen any time soon.
> >
> > the optimum before v1:
> > docs + examples + agreed versioning strategy
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2013/11/12 Mark Struberg 
> >
> > > yea, but what are the alternatives?
> > > If you have a better idea, then tell us :)
> > >
> > > The problem is that it's not only about the JSF module but about all
> > other
> > > modules as well.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > >
> > > - Original Message -
> > > > From: Gerhard Petracek 
> > > > To: dev@deltaspike.apache.org
> > > > Cc:
> > > > Sent: Tuesday, 12 November 2013, 16:18
> > > > Subject: Re: [DISCUSS] next release version? 0.6 or 1.0?
> > > >
> > > > @mark:
> > > > i never said that we should do #2.
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > >
> > > > 2013/11/12 Mark Struberg 
> > > >
> > > >>  Pete, Gerhard
> > > >>
> > > >>  The Problem here is that there are only 2 ways to handle the
> > situation:
> > > >>
> > > >>  1.) all modules share the same version but have different maturity
> > > grades
> > > >>
> > > >>  2.) each module has it's very own version. A 0.x reflects
> > instability,
> > > > 1.x
> > > >>  reflects maturity. But you know what happened with exactly this
> > > approach in
> > > >>  Seam3? The problem is that users do not know which version of
> > > ds-jsf-api
> > > >>  works together with which version of ds-core-impl for example. It
> > gets
> > > much
> > > >>  more complicated with later modules.
> > > >>
> > > >>  Thus I prefer 1.).
> > > >>
> > > >>  LieGrue,
> > > >>  strub
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>  >
> > > >>  > From: Pete Muir 
> > > >>  >To: dev@deltaspike.apache.org
> > > >>  >Sent: Tuesday, 12 November 2013, 14:35
> > > >>  >Subject: Re: [DISCUSS] next release version? 0.6 or 1.0?
> > > >>  >
> > > >>  >
> > > >>  >+1 to Gerhard’s point (I am looking to try to find someone to help
> > > with
> > > >>  docs, but the person I had in mind just left Red Hat :-(. Also +1
> to
> > > going
> > > >>  to 1.0 soon (i.e. making docs and stability a priority!).
> > > >>  >
> > > >>  >
> > > >>  >On 11 Nov 2013, at 23:09, Gerhard Petracek
> > > > 
> > > >>  wrote:
> > > >>  >
> > > >>  >> if we move to v1 soon, we need an useful versioning strategy,
> > > > better
> > > >>  docs
> > > >>  >> and examples + the api and spi need to be stable for some time
> (in
> > > > the
> > > >>  best
> > > >>  >> case until v2+).
> > > >>  >>
> > > >>  >> regards,
> > > >>  >> gerhard
> > > >>  >>
> > > >>  >>
> > > >>  >>
> > > >>  >> 2013/11/11 Mark Struberg 
> > > >>  >>
> > > >>  >>>
> > > >>  >>>
> > > >>  >>> how should that work?
> > > >>  >>>
> > &

Re: Data Module

[Romain Manni-Bucau]

+1 Works for me, thks
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2013/11/15 Thomas Hug :
> One question is probably whether it's worth adding something like a
> MapperResolver instead of referring to the mapper class directly.
>
>
> On Fri, Nov 15, 2013 at 11:10 AM, Thomas Hug  wrote:
>
>> Finally found some spare time to get back to this. You can find an API
>> proposal at [1] and a sample repository at [2].
>> Suggestions?
>>
>> [1]
>> https://github.com/thomashug/DeltaSpike-Mirror/tree/master/deltaspike/modules/data/api/src/main/java/org/apache/deltaspike/data/api/mapping
>> [2]
>> https://github.com/thomashug/DeltaSpike-Mirror/blob/master/deltaspike/modules/data/impl/src/test/java/org/apache/deltaspike/data/test/service/SimpleMappedRepository.java
>>
>>
>>
>> On Tue, Oct 1, 2013 at 5:44 PM, Thomas Hug  wrote:
>>
>>> +1 on the feature, just been busy on a project where that would have been
>>> handy.
>>>
>>> And apologies for letting the thread quiet, will I'll try to propose
>>> something over the next two weeks based on the initial API suggestion (and
>>> get some other JIRA issues finally done...).
>>>
>>>
>>> On Tue, Oct 1, 2013 at 4:31 PM, Jean-Louis MONTEIRO 
>>> wrote:
>>>
>>>> Yep, I still think it's useful.
>>>>
>>>> JLouis
>>>>
>>>>
>>>> 2013/10/1 Romain Manni-Bucau 
>>>>
>>>> > Not particularly
>>>> >
>>>> > the thread ends while the feature is useful IMO so simply asking what
>>>> to do
>>>> > next ;)
>>>> >
>>>> > *Romain Manni-Bucau*
>>>> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>>>> > *Blog: **http://rmannibucau.wordpress.com/*<
>>>> > http://rmannibucau.wordpress.com/>
>>>> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>>>> > *Github: https://github.com/rmannibucau*
>>>> >
>>>> >
>>>> >
>>>> > 2013/10/1 Jason Porter 
>>>> >
>>>> > > Was this my action item?
>>>> > >
>>>> > > Sent from my iPhone
>>>> > >
>>>> > > > On Oct 1, 2013, at 7:43, Romain Manni-Bucau >>> >
>>>> > > wrote:
>>>> > > >
>>>> > > > Hi
>>>> > > >
>>>> > > > any news on it?
>>>> > > >
>>>> > > > @ResultMapper was good to me
>>>> > > >
>>>> > > > *Romain Manni-Bucau*
>>>> > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>>>> > > > *Blog: **http://rmannibucau.wordpress.com/*<
>>>> > > http://rmannibucau.wordpress.com/>
>>>> > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>>>> > > > *Github: https://github.com/rmannibucau*
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > 2013/7/12 Jason Porter 
>>>> > > >
>>>> > > >> On Fri, Jul 12, 2013 at 12:13 AM, Romain Manni-Bucau
>>>> > > >> wrote:
>>>> > > >>
>>>> > > >>> Ps: you can make a cdi bean an ejb from cdi extension
>>>> > > >>>
>>>> > > >>
>>>> > > >> No, the bootstrapping for each container do not communicate to my
>>>> > > >> knowledge.
>>>> > > >>
>>>> > > >>
>>>> > > >>> Le 12 juil. 2013 08:12, "Romain Manni-Bucau" <
>>>> rmannibu...@gmail.com>
>>>> > a
>>>> > > >>> écrit :
>>>> > > >>>
>>>> > > >>>> Hi
>>>> > > >>>>
>>>> > > >>>> Depending the case DTO are not an option.
>>>> > > >>>>
>>>> > > >>>> I agree in rest app i wouldnt it but if not possible (maybe
>>>> through
>>>> > > >>>> another Bean) it would kill this module for half of the usages
>>>> i see
>>>> > > >

repositories

[Romain Manni-Bucau]

Hi

testing new mapping feature (really appreciated once
SimpleQueryInOutMapperBase was added) I realized we still don't
support @transactional on repos.

What's blocking for it? Since we handle the impl we can add the
transaction strategy handling.

That said it rings 2 questions:
1) why don't we handle nested transactions?
2) why don't we have a TransactionStrategy backed by a transaction manager?
2') if 2) can't we support default locations like
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.openjpa/openjpa-all/2.1.0/org/apache/openjpa/ee/AutomaticManagedRuntime.java?av=f
. This is great cause make it working with 0 config in a JavaEE
server.

wdyt?

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

Re: repositories

[Romain Manni-Bucau]

BTW to make some code on 2): https://gist.github.com/rmannibucau/7564089
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2013/11/20 Romain Manni-Bucau :
> Hi
>
> testing new mapping feature (really appreciated once
> SimpleQueryInOutMapperBase was added) I realized we still don't
> support @transactional on repos.
>
> What's blocking for it? Since we handle the impl we can add the
> transaction strategy handling.
>
> That said it rings 2 questions:
> 1) why don't we handle nested transactions?
> 2) why don't we have a TransactionStrategy backed by a transaction manager?
> 2') if 2) can't we support default locations like
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.openjpa/openjpa-all/2.1.0/org/apache/openjpa/ee/AutomaticManagedRuntime.java?av=f
> . This is great cause make it working with 0 config in a JavaEE
> server.
>
> wdyt?
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau

[data] getSingleResult exceptions

[Romain Manni-Bucau]

Hi,

playing further with data module I realized we get an exception is we
do a X findYyyy(bbb); and X doesn't exist.

-> The first thing is: can't we get null instead of an exception
(adding a param in @Query or adding a @SingleQuery(throwException =
false))?

The other point (and more embarassaing) is: why is it a
QueryInvocationException? If we don't want null but an exception to be
aligned on the jpa spec we should be able to catch the exception. ATM
we can only do it if we add in compile scope data-impl which doesn't
seem to be the idea. Do we add an exception for that purpose?

To summarize:
1) do we allow to configure though an annotation the fact single
result query return null if the entity is not ofund?
2) do we add in the data-api an exception when 1) throws an exception
to be able to catch it?

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

Re: [data] getSingleResult exceptions

[Romain Manni-Bucau]

sounds great, thks!
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2013/11/22 Thomas Hug :
> Hi Romain
> 1) relates to DELTASPIKE-421. Started to prototype something there and will
> push a proposal soon.
> 2) Agree there should be something in the API. And for JPA exceptions, I
> guess we should just rethrow them.
>
>
> On Fri, Nov 22, 2013 at 11:01 AM, Romain Manni-Bucau
> wrote:
>
>> Hi,
>>
>> playing further with data module I realized we get an exception is we
>> do a X findYyyy(bbb); and X doesn't exist.
>>
>> -> The first thing is: can't we get null instead of an exception
>> (adding a param in @Query or adding a @SingleQuery(throwException =
>> false))?
>>
>> The other point (and more embarassaing) is: why is it a
>> QueryInvocationException? If we don't want null but an exception to be
>> aligned on the jpa spec we should be able to catch the exception. ATM
>> we can only do it if we add in compile scope data-impl which doesn't
>> seem to be the idea. Do we add an exception for that purpose?
>>
>> To summarize:
>> 1) do we allow to configure though an annotation the fact single
>> result query return null if the entity is not ofund?
>> 2) do we add in the data-api an exception when 1) throws an exception
>> to be able to catch it?
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>

Re: [data] getSingleResult exceptions

[Romain Manni-Bucau]

+1

I'd remove both line btw:

e.printStackTrace();
log.log(Level.SEVERE, "Query execution error", e);

i'd keep the log in FINEST level


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



2013/11/22 Thomas Hug :
> Here we go. Would that work?
> https://github.com/thomashug/DeltaSpike-Mirror/commit/6177a9581b6694570d3279d5d694d45ddb6e7ac1
>
>
>
> On Fri, Nov 22, 2013 at 12:15 PM, Romain Manni-Bucau
> wrote:
>
>> sounds great, thks!
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2013/11/22 Thomas Hug :
>> > Hi Romain
>> > 1) relates to DELTASPIKE-421. Started to prototype something there and
>> will
>> > push a proposal soon.
>> > 2) Agree there should be something in the API. And for JPA exceptions, I
>> > guess we should just rethrow them.
>> >
>> >
>> > On Fri, Nov 22, 2013 at 11:01 AM, Romain Manni-Bucau
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> playing further with data module I realized we get an exception is we
>> >> do a X findYyyy(bbb); and X doesn't exist.
>> >>
>> >> -> The first thing is: can't we get null instead of an exception
>> >> (adding a param in @Query or adding a @SingleQuery(throwException =
>> >> false))?
>> >>
>> >> The other point (and more embarassaing) is: why is it a
>> >> QueryInvocationException? If we don't want null but an exception to be
>> >> aligned on the jpa spec we should be able to catch the exception. ATM
>> >> we can only do it if we add in compile scope data-impl which doesn't
>> >> seem to be the idea. Do we add an exception for that purpose?
>> >>
>> >> To summarize:
>> >> 1) do we allow to configure though an annotation the fact single
>> >> result query return null if the entity is not ofund?
>> >> 2) do we add in the data-api an exception when 1) throws an exception
>> >> to be able to catch it?
>> >>
>> >> Romain Manni-Bucau
>> >> Twitter: @rmannibucau
>> >> Blog: http://rmannibucau.wordpress.com/
>> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> >> Github: https://github.com/rmannibucau
>> >>
>>

Re: [data] getSingleResult exceptions

[Romain Manni-Bucau]

Looks good!
Le 22 nov. 2013 18:05, "Thomas Hug"  a écrit :

> Digged out some other crappy exception handling on the delegates. Proposals
> for 1) and 2) pushed at
> https://github.com/thomashug/DeltaSpike-Mirror/commits/master
>
>
>
> On Fri, Nov 22, 2013 at 5:11 PM, Thomas Hug  wrote:
>
> > Oops, good catch, that one sneaked in.
> >
> > -----Original Message-
> > From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> > Sent: Freitag, 22. November 2013 16:13
> > To: dev@deltaspike.apache.org
> > Subject: Re: [data] getSingleResult exceptions
> >
> > +1
> >
> > I'd remove both line btw:
> >
> > e.printStackTrace();
> > log.log(Level.SEVERE, "Query execution error", e);
> >
> > i'd keep the log in FINEST level
> >
> >
> > Romain Manni-Bucau
> > Twitter: @rmannibucau
> > Blog: http://rmannibucau.wordpress.com/
> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > Github: https://github.com/rmannibucau
> >
> >
> >
> > 2013/11/22 Thomas Hug :
> > > Here we go. Would that work?
> > > https://github.com/thomashug/DeltaSpike-Mirror/commit/6177a9581b669457
> > > 0d3279d5d694d45ddb6e7ac1
> > >
> > >
> > >
> > > On Fri, Nov 22, 2013 at 12:15 PM, Romain Manni-Bucau
> > > wrote:
> > >
> > >> sounds great, thks!
> > >> Romain Manni-Bucau
> > >> Twitter: @rmannibucau
> > >> Blog: http://rmannibucau.wordpress.com/
> > >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >> Github: https://github.com/rmannibucau
> > >>
> > >>
> > >>
> > >> 2013/11/22 Thomas Hug :
> > >> > Hi Romain
> > >> > 1) relates to DELTASPIKE-421. Started to prototype something there
> > >> > and
> > >> will
> > >> > push a proposal soon.
> > >> > 2) Agree there should be something in the API. And for JPA
> > >> > exceptions, I guess we should just rethrow them.
> > >> >
> > >> >
> > >> > On Fri, Nov 22, 2013 at 11:01 AM, Romain Manni-Bucau
> > >> > wrote:
> > >> >
> > >> >> Hi,
> > >> >>
> > >> >> playing further with data module I realized we get an exception is
> > >> >> we do a X findYyyy(bbb); and X doesn't exist.
> > >> >>
> > >> >> -> The first thing is: can't we get null instead of an exception
> > >> >> (adding a param in @Query or adding a @SingleQuery(throwException
> > >> >> = false))?
> > >> >>
> > >> >> The other point (and more embarassaing) is: why is it a
> > >> >> QueryInvocationException? If we don't want null but an exception
> > >> >> to be aligned on the jpa spec we should be able to catch the
> > >> >> exception. ATM we can only do it if we add in compile scope
> > >> >> data-impl which doesn't seem to be the idea. Do we add an exception
> > for that purpose?
> > >> >>
> > >> >> To summarize:
> > >> >> 1) do we allow to configure though an annotation the fact single
> > >> >> result query return null if the entity is not ofund?
> > >> >> 2) do we add in the data-api an exception when 1) throws an
> > >> >> exception to be able to catch it?
> > >> >>
> > >> >> Romain Manni-Bucau
> > >> >> Twitter: @rmannibucau
> > >> >> Blog: http://rmannibucau.wordpress.com/
> > >> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >> >> Github: https://github.com/rmannibucau
> > >> >>
> > >>
> >
>

Re: [data] getSingleResult exceptions

[Romain Manni-Bucau]

I was written it in my previous mail then thought nobody will use it. Too
low level IMO
Le 22 nov. 2013 19:15, "Jason Porter"  a écrit :

> Do we want to / should we have exceptioncontrol integration here?
>
>
> On Fri, Nov 22, 2013 at 10:20 AM, Romain Manni-Bucau
> wrote:
>
> > Looks good!
> > Le 22 nov. 2013 18:05, "Thomas Hug"  a écrit :
> >
> > > Digged out some other crappy exception handling on the delegates.
> > Proposals
> > > for 1) and 2) pushed at
> > > https://github.com/thomashug/DeltaSpike-Mirror/commits/master
> > >
> > >
> > >
> > > On Fri, Nov 22, 2013 at 5:11 PM, Thomas Hug 
> wrote:
> > >
> > > > Oops, good catch, that one sneaked in.
> > > >
> > > > -Original Message-
> > > > From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> > > > Sent: Freitag, 22. November 2013 16:13
> > > > To: dev@deltaspike.apache.org
> > > > Subject: Re: [data] getSingleResult exceptions
> > > >
> > > > +1
> > > >
> > > > I'd remove both line btw:
> > > >
> > > > e.printStackTrace();
> > > > log.log(Level.SEVERE, "Query execution error", e);
> > > >
> > > > i'd keep the log in FINEST level
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > Twitter: @rmannibucau
> > > > Blog: http://rmannibucau.wordpress.com/
> > > > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > > Github: https://github.com/rmannibucau
> > > >
> > > >
> > > >
> > > > 2013/11/22 Thomas Hug :
> > > > > Here we go. Would that work?
> > > > >
> > https://github.com/thomashug/DeltaSpike-Mirror/commit/6177a9581b669457
> > > > > 0d3279d5d694d45ddb6e7ac1
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Nov 22, 2013 at 12:15 PM, Romain Manni-Bucau
> > > > > wrote:
> > > > >
> > > > >> sounds great, thks!
> > > > >> Romain Manni-Bucau
> > > > >> Twitter: @rmannibucau
> > > > >> Blog: http://rmannibucau.wordpress.com/
> > > > >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > > >> Github: https://github.com/rmannibucau
> > > > >>
> > > > >>
> > > > >>
> > > > >> 2013/11/22 Thomas Hug :
> > > > >> > Hi Romain
> > > > >> > 1) relates to DELTASPIKE-421. Started to prototype something
> there
> > > > >> > and
> > > > >> will
> > > > >> > push a proposal soon.
> > > > >> > 2) Agree there should be something in the API. And for JPA
> > > > >> > exceptions, I guess we should just rethrow them.
> > > > >> >
> > > > >> >
> > > > >> > On Fri, Nov 22, 2013 at 11:01 AM, Romain Manni-Bucau
> > > > >> > wrote:
> > > > >> >
> > > > >> >> Hi,
> > > > >> >>
> > > > >> >> playing further with data module I realized we get an exception
> > is
> > > > >> >> we do a X findYyyy(bbb); and X doesn't exist.
> > > > >> >>
> > > > >> >> -> The first thing is: can't we get null instead of an
> exception
> > > > >> >> (adding a param in @Query or adding a
> @SingleQuery(throwException
> > > > >> >> = false))?
> > > > >> >>
> > > > >> >> The other point (and more embarassaing) is: why is it a
> > > > >> >> QueryInvocationException? If we don't want null but an
> exception
> > > > >> >> to be aligned on the jpa spec we should be able to catch the
> > > > >> >> exception. ATM we can only do it if we add in compile scope
> > > > >> >> data-impl which doesn't seem to be the idea. Do we add an
> > exception
> > > > for that purpose?
> > > > >> >>
> > > > >> >> To summarize:
> > > > >> >> 1) do we allow to configure though an annotation the fact
> single
> > > > >> >> result query return null if the entity is not ofund?
> > > > >> >> 2) do we add in the data-api an exception when 1) throws an
> > > > >> >> exception to be able to catch it?
> > > > >> >>
> > > > >> >> Romain Manni-Bucau
> > > > >> >> Twitter: @rmannibucau
> > > > >> >> Blog: http://rmannibucau.wordpress.com/
> > > > >> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > > >> >> Github: https://github.com/rmannibucau
> > > > >> >>
> > > > >>
> > > >
> > >
> >
>
>
>
> --
> Jason Porter
> http://en.gravatar.com/lightguardjp
>

Re: [data] getSingleResult exceptions

[Romain Manni-Bucau]

Then the question is the same as for @transactional/@repo: do we integrate
all our features together (im +1)
Le 22 nov. 2013 19:22, "Jason Porter"  a écrit :

> Okay. If we're exposing it up through the stack then people can decide on
> their own how they'd like to handle things.
>
>
> On Fri, Nov 22, 2013 at 11:17 AM, Romain Manni-Bucau
> wrote:
>
> > I was written it in my previous mail then thought nobody will use it. Too
> > low level IMO
> > Le 22 nov. 2013 19:15, "Jason Porter"  a écrit
> :
> >
> > > Do we want to / should we have exceptioncontrol integration here?
> > >
> > >
> > > On Fri, Nov 22, 2013 at 10:20 AM, Romain Manni-Bucau
> > > wrote:
> > >
> > > > Looks good!
> > > > Le 22 nov. 2013 18:05, "Thomas Hug"  a écrit :
> > > >
> > > > > Digged out some other crappy exception handling on the delegates.
> > > > Proposals
> > > > > for 1) and 2) pushed at
> > > > > https://github.com/thomashug/DeltaSpike-Mirror/commits/master
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Nov 22, 2013 at 5:11 PM, Thomas Hug 
> > > wrote:
> > > > >
> > > > > > Oops, good catch, that one sneaked in.
> > > > > >
> > > > > > -Original Message-
> > > > > > From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> > > > > > Sent: Freitag, 22. November 2013 16:13
> > > > > > To: dev@deltaspike.apache.org
> > > > > > Subject: Re: [data] getSingleResult exceptions
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > I'd remove both line btw:
> > > > > >
> > > > > > e.printStackTrace();
> > > > > > log.log(Level.SEVERE, "Query execution error", e);
> > > > > >
> > > > > > i'd keep the log in FINEST level
> > > > > >
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > Twitter: @rmannibucau
> > > > > > Blog: http://rmannibucau.wordpress.com/
> > > > > > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > > > > Github: https://github.com/rmannibucau
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2013/11/22 Thomas Hug :
> > > > > > > Here we go. Would that work?
> > > > > > >
> > > >
> https://github.com/thomashug/DeltaSpike-Mirror/commit/6177a9581b669457
> > > > > > > 0d3279d5d694d45ddb6e7ac1
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Nov 22, 2013 at 12:15 PM, Romain Manni-Bucau
> > > > > > > wrote:
> > > > > > >
> > > > > > >> sounds great, thks!
> > > > > > >> Romain Manni-Bucau
> > > > > > >> Twitter: @rmannibucau
> > > > > > >> Blog: http://rmannibucau.wordpress.com/
> > > > > > >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > > > > >> Github: https://github.com/rmannibucau
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> 2013/11/22 Thomas Hug :
> > > > > > >> > Hi Romain
> > > > > > >> > 1) relates to DELTASPIKE-421. Started to prototype something
> > > there
> > > > > > >> > and
> > > > > > >> will
> > > > > > >> > push a proposal soon.
> > > > > > >> > 2) Agree there should be something in the API. And for JPA
> > > > > > >> > exceptions, I guess we should just rethrow them.
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > On Fri, Nov 22, 2013 at 11:01 AM, Romain Manni-Bucau
> > > > > > >> > wrote:
> > > > > > >> >
> > > > > > >> >> Hi,
> > > > > > >> >>
> > > > > > >> >> playing further with data module I realized we get an
> > exception
> > > > is
> > > > > > >> >> we do a X findYyyy(bbb); and X doesn't exist.
> > > > > > >> >>
> > > > > > >> >> -> The first thing is: can't we get null instead of an
> > > exception
> > > > > > >> >> (adding a param in @Query or adding a
> > > @SingleQuery(throwException
> > > > > > >> >> = false))?
> > > > > > >> >>
> > > > > > >> >> The other point (and more embarassaing) is: why is it a
> > > > > > >> >> QueryInvocationException? If we don't want null but an
> > > exception
> > > > > > >> >> to be aligned on the jpa spec we should be able to catch
> the
> > > > > > >> >> exception. ATM we can only do it if we add in compile scope
> > > > > > >> >> data-impl which doesn't seem to be the idea. Do we add an
> > > > exception
> > > > > > for that purpose?
> > > > > > >> >>
> > > > > > >> >> To summarize:
> > > > > > >> >> 1) do we allow to configure though an annotation the fact
> > > single
> > > > > > >> >> result query return null if the entity is not ofund?
> > > > > > >> >> 2) do we add in the data-api an exception when 1) throws an
> > > > > > >> >> exception to be able to catch it?
> > > > > > >> >>
> > > > > > >> >> Romain Manni-Bucau
> > > > > > >> >> Twitter: @rmannibucau
> > > > > > >> >> Blog: http://rmannibucau.wordpress.com/
> > > > > > >> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > > > > >> >> Github: https://github.com/rmannibucau
> > > > > > >> >>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Jason Porter
> > > http://en.gravatar.com/lightguardjp
> > >
> >
>
>
>
> --
> Jason Porter
> http://en.gravatar.com/lightguardjp
>

Re: [data] getSingleResult exceptions

[Romain Manni-Bucau]

That's exactly the question ;)
Le 22 nov. 2013 19:51, "Jason Porter"  a écrit :

> I think it only makes sense to integrate our own features.
>
>
> On Fri, Nov 22, 2013 at 11:26 AM, Romain Manni-Bucau
> wrote:
>
> > Then the question is the same as for @transactional/@repo: do we
> integrate
> > all our features together (im +1)
> > Le 22 nov. 2013 19:22, "Jason Porter"  a écrit
> :
> >
> > > Okay. If we're exposing it up through the stack then people can decide
> on
> > > their own how they'd like to handle things.
> > >
> > >
> > > On Fri, Nov 22, 2013 at 11:17 AM, Romain Manni-Bucau
> > > wrote:
> > >
> > > > I was written it in my previous mail then thought nobody will use it.
> > Too
> > > > low level IMO
> > > > Le 22 nov. 2013 19:15, "Jason Porter"  a
> > écrit
> > > :
> > > >
> > > > > Do we want to / should we have exceptioncontrol integration here?
> > > > >
> > > > >
> > > > > On Fri, Nov 22, 2013 at 10:20 AM, Romain Manni-Bucau
> > > > > wrote:
> > > > >
> > > > > > Looks good!
> > > > > > Le 22 nov. 2013 18:05, "Thomas Hug"  a
> écrit :
> > > > > >
> > > > > > > Digged out some other crappy exception handling on the
> delegates.
> > > > > > Proposals
> > > > > > > for 1) and 2) pushed at
> > > > > > > https://github.com/thomashug/DeltaSpike-Mirror/commits/master
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Nov 22, 2013 at 5:11 PM, Thomas Hug <
> thomas@ctp.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > Oops, good catch, that one sneaked in.
> > > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> > > > > > > > Sent: Freitag, 22. November 2013 16:13
> > > > > > > > To: dev@deltaspike.apache.org
> > > > > > > > Subject: Re: [data] getSingleResult exceptions
> > > > > > > >
> > > > > > > > +1
> > > > > > > >
> > > > > > > > I'd remove both line btw:
> > > > > > > >
> > > > > > > > e.printStackTrace();
> > > > > > > > log.log(Level.SEVERE, "Query execution error", e);
> > > > > > > >
> > > > > > > > i'd keep the log in FINEST level
> > > > > > > >
> > > > > > > >
> > > > > > > > Romain Manni-Bucau
> > > > > > > > Twitter: @rmannibucau
> > > > > > > > Blog: http://rmannibucau.wordpress.com/
> > > > > > > > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > > > > > > Github: https://github.com/rmannibucau
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 2013/11/22 Thomas Hug :
> > > > > > > > > Here we go. Would that work?
> > > > > > > > >
> > > > > >
> > > https://github.com/thomashug/DeltaSpike-Mirror/commit/6177a9581b669457
> > > > > > > > > 0d3279d5d694d45ddb6e7ac1
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Nov 22, 2013 at 12:15 PM, Romain Manni-Bucau
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > >> sounds great, thks!
> > > > > > > > >> Romain Manni-Bucau
> > > > > > > > >> Twitter: @rmannibucau
> > > > > > > > >> Blog: http://rmannibucau.wordpress.com/
> > > > > > > > >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > > > > > > >> Github: https://github.com/rmannibucau
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > &

Re: Any plan to port @Startup?

[Romain Manni-Bucau]

Why not just supporting @eager, doing a tostring in
afterdeploymentvalidation should do the trick
Le 27 nov. 2013 13:15, "Thomas Andraschko"  a
écrit :

> Gerhard, one question about the system events.
> We could also do somelike like (@Observers @ViewRef(config = MyView.class)
> PreRenderViewEvent event) but the #config in ViewRef has a @NonBinding.
> Is this by design?
>
>
> 2013/11/27 Gerhard Petracek 
>
> > yes - you are very welcome to do it (don't forget to use Deactivatable)
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2013/11/27 Thomas Andraschko 
> >
> > > How is it handled it DS?
> > > Should i just create a issue + providing a patch or something?
> > >
> > >
> > > 2013/11/27 Gerhard Petracek 
> > >
> > > > yes - we can do that.
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2013/11/27 Thomas Andraschko 
> > > >
> > > > > What about providing a CDI Event for such events?
> > > > >
> > > > > (@Observers PostConstructApplicationEvent event) would be a great
> > > thing.
> > > > >
> > > > >
> > > > > 2013/11/27 Thomas Andraschko 
> > > > >
> > > > > > Is a SystemEventListener CDI-aware with DS?
> > > > > >
> > > > > >
> > > > > > 2013/11/27 Gerhard Petracek 
> > > > > >
> > > > > >> with jsf2+ you can use PostConstructApplicationEvent
> > > > > >>
> > > > > >> regards,
> > > > > >> gerhard
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> 2013/11/27 Thomas Andraschko 
> > > > > >>
> > > > > >> > Hi,
> > > > > >> >
> > > > > >> > is there any to plan to port @Startup for JSF Applications?
> > > > > >> >
> > > > > >> > Regards,
> > > > > >> > Thomas
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] unit-test cdi-control

[Romain Manni-Bucau]

we have something like it in openejb and it is really nicer than
arquillian for real apps and unit tests since you don't need
deployment or heavy enrichments processes
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2013/12/2 John D. Ament :
> I'd personally prefer to see this as an Arquillian add on, especially
> since the embedded containers have such little over head.
>
> On Mon, Dec 2, 2013 at 6:32 AM, Mark Struberg  wrote:
>>
>>
>> yup +1
>>
>> TestNG support would also be handy later.
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>>>
>>> From: Thomas Andraschko 
>>>To: dev@deltaspike.apache.org
>>>Sent: Monday, 2 December 2013, 11:22
>>>Subject: Re: [DISCUSS] unit-test cdi-control
>>>
>>>
>>>+1
>>>simple and nice approach
>>>
>>>
>>>
>>>2013/12/2 Gerhard Petracek 
>>>
>>>> hi @ all,
>>>>
>>>> please have a look at [1].
>>>>
>>>> it's just a first (and quick) draft based on major use-cases.
>>>> however, it's working already and the api/spi is minimal -> we can think
>>>> about adding it to deltaspike.
>>>> (it's already prepared for additional use-cases, however, for sure we can
>>>> simplify/change/improve any part of it easily.)
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>> [1]
>>>> http://os890.blogspot.com/2013/12/add-on-cdi-tests-with-deltaspike-05.html
>>>>
>>>
>>>
>>>

Re: [DISCUSS] unit-test cdi-control

[Romain Manni-Bucau]

Which gain supporting testng?

Testng supports junit iirc
Le 2 déc. 2013 18:11, "Christian Kaltepoth"  a
écrit :

> I really like this. So +1 for adding it. Great work Gerhard. :)
>
> And I agree with Mark that we should also support TestNG later. So the
> module name should indicate that it is JUnit specific.
>
> Christian
>
>
> 2013/12/2 Gerhard Petracek 
>
> > hi @ all,
> >
> > please have a look at [1].
> >
> > it's just a first (and quick) draft based on major use-cases.
> > however, it's working already and the api/spi is minimal -> we can think
> > about adding it to deltaspike.
> > (it's already prepared for additional use-cases, however, for sure we can
> > simplify/change/improve any part of it easily.)
> >
> > regards,
> > gerhard
> >
> > [1]
> >
> http://os890.blogspot.com/2013/12/add-on-cdi-tests-with-deltaspike-05.html
> >
>
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>

Re: [DISCUSS] unit-test cdi-control

[Romain Manni-Bucau]

well I asked cause I used it and found something to replace in junit
for everything (all you speak about)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2013/12/2 Mark Struberg :
> I use it ;P
>
> Nah, testNG is really cool if you have a bit of a mixture of pure unit tests 
> with a slight touch of integration testing. groups, parallel executions, 
> shuffled executions, etc. _really_ useful stuff!
>
> LieGrue,
> strub
>
>
>
>
> - Original Message -
>> From: Romain Manni-Bucau 
>> To: dev@deltaspike.apache.org
>> Cc:
>> Sent: Monday, 2 December 2013, 19:59
>> Subject: Re: [DISCUSS] unit-test cdi-control
>>
>> Which gain supporting testng?
>>
>> Testng supports junit iirc
>> Le 2 déc. 2013 18:11, "Christian Kaltepoth"
>>  a
>> écrit :
>>
>>
>>>  I really like this. So +1 for adding it. Great work Gerhard. :)
>>>
>>>  And I agree with Mark that we should also support TestNG later. So the
>>>  module name should indicate that it is JUnit specific.
>>>
>>>  Christian
>>>
>>>
>>>  2013/12/2 Gerhard Petracek 
>>>
>>>  > hi @ all,
>>>  >
>>>  > please have a look at [1].
>>>  >
>>>  > it's just a first (and quick) draft based on major use-cases.
>>>  > however, it's working already and the api/spi is minimal -> we
>> can think
>>>  > about adding it to deltaspike.
>>>  > (it's already prepared for additional use-cases, however, for sure
>> we can
>>>  > simplify/change/improve any part of it easily.)
>>>  >
>>>  > regards,
>>>  > gerhard
>>>  >
>>>  > [1]
>>>  >
>>>  http://os890.blogspot.com/2013/12/add-on-cdi-tests-with-deltaspike-05.html
>>>  >
>>>
>>>
>>>
>>>  --
>>>  Christian Kaltepoth
>>>  Blog: http://blog.kaltepoth.de/
>>>  Twitter: http://twitter.com/chkal
>>>  GitHub: https://github.com/chkal
>>>
>>

Re: Simple Cron Module

[Romain Manni-Bucau]

Oh, so something else ;).

I'm +0 on this feature since IMO JavaEE 6 offers what is needed but I
understand your constraint
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2013/12/3 Thomas Andraschko :
> My problem is that some customers just have a tomcat, without JavaEE.
>
>
>
>
> 2013/12/3 Romain Manni-Bucau 
>
>> Hi
>>
>> what is issing in JavaEE 6 for you (TimerService already allows a lot)?
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2013/12/3 Nathan Dennis :
>> > Beyond what JEE6 Time Service offers,  (and maybe I missed this
>> somewhere in there), the ability to store, recall, pause, edit jobs would
>> be nice using some sort of handle. I was definitely making use of these
>> features in Seam 2. Actually, I'm still running that code in places in
>> production just for the easy integration with Quartz scheduler. That being
>> said, the follow up question would be is Delta Spike the right place for
>> this type of functionality?
>> >
>> >
>> > best regards,
>> >
>> > Nathan Dennis | Software Developer
>> > 732 Greenwood Street | Albemarle, NC | 28001
>> > Main (800) 230-7525 | Direct: 704-986-7211 | Mobile 704.984.0829
>> > www.monarchnc.org | nathan.den...@monarchnc.org
>> >
>> >
>> > -Original Message-
>> > From: Thomas Andraschko [mailto:andraschko.tho...@gmail.com]
>> > Sent: Tuesday, December 03, 2013 7:43 AM
>> > To: dev@deltaspike.apache.org
>> > Subject: Simle Cron Module
>> >
>> > Hi,
>> >
>> > what do you think about a simple cron module like in Seam?
>> >
>> > Regards,
>> > Thomas
>> >
>> >
>> > [http://monarchnc.org/images/monarch/env.png]Please consider the
>> environment before printing this email.
>> > WARNING: This email is intended solely for the person or entity to which
>> it is addressed and may contain confidential and/or privileged information.
>> Any review, dissemination, copying, printing or other use of the email by
>> persons or entities other than the addressee is prohibited. If you have
>> received this email in error, please contact the sender immediately and
>> delete the material from any computer. If you are unable to determine the
>> sender of this email, please email Monarch at supp...@monarchnc.org or
>> contact us at toll free (800) 230-7525, and advise us of the error.
>>

Re: Simple Cron Module

[Romain Manni-Bucau]

Hi

what is issing in JavaEE 6 for you (TimerService already allows a lot)?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2013/12/3 Nathan Dennis :
> Beyond what JEE6 Time Service offers,  (and maybe I missed this somewhere in 
> there), the ability to store, recall, pause, edit jobs would be nice using 
> some sort of handle. I was definitely making use of these features in Seam 2. 
> Actually, I'm still running that code in places in production just for the 
> easy integration with Quartz scheduler. That being said, the follow up 
> question would be is Delta Spike the right place for this type of 
> functionality?
>
>
> best regards,
>
> Nathan Dennis | Software Developer
> 732 Greenwood Street | Albemarle, NC | 28001
> Main (800) 230-7525 | Direct: 704-986-7211 | Mobile 704.984.0829
> www.monarchnc.org | nathan.den...@monarchnc.org
>
>
> -Original Message-
> From: Thomas Andraschko [mailto:andraschko.tho...@gmail.com]
> Sent: Tuesday, December 03, 2013 7:43 AM
> To: dev@deltaspike.apache.org
> Subject: Simle Cron Module
>
> Hi,
>
> what do you think about a simple cron module like in Seam?
>
> Regards,
> Thomas
>
>
> [http://monarchnc.org/images/monarch/env.png]Please consider the environment 
> before printing this email.
> WARNING: This email is intended solely for the person or entity to which it 
> is addressed and may contain confidential and/or privileged information. Any 
> review, dissemination, copying, printing or other use of the email by persons 
> or entities other than the addressee is prohibited. If you have received this 
> email in error, please contact the sender immediately and delete the material 
> from any computer. If you are unable to determine the sender of this email, 
> please email Monarch at supp...@monarchnc.org or contact us at toll free 
> (800) 230-7525, and advise us of the error.

Re: Parent vs BOM

[Romain Manni-Bucau]

+-0 while deltaspike doesnt use itself the bom (they lead too often to dep
issues in practise)
Le 23 déc. 2013 02:09, "John D. Ament"  a écrit :

> Hi all
>
> Recently for the binary distribution task, I added a bom.  I added
> this because the parent pom includes our dependencies, as well as our
> developer list.  For someone importing the project to build against, I
> figured this was a bad idea (we would show as developers in that
> imported pom).  However, this ended up adding some double entry.
>
> So I'd like to propose moving this bom up a few directories, and leave
> this up as the only place to have the modules listed.  Importing this
> one into our parent.
>
> WDYT?
>
> John
>

Re: Fwd: Support of Instance<> in OWB

[Romain Manni-Bucau]

@john: I guess the issue you got with tomee is linked to the
dependencies in DS more than to tomee itself (answered your jira)

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



2013/12/29 Gerhard Petracek :
> @john: please update all arquillian.xml files (not just one).
>
> thx & regards,
> gerhard
>
>
>
> 2013/12/29 John D. Ament 
>
>> Should be fixed now (and fixed the AS7 issue).
>>
>> On Sun, Dec 29, 2013 at 11:33 AM, Gerhard Petracek
>>  wrote:
>> > that means we can't keep it that way (due to this issue).
>> >
>> > regards,
>> > gerhard
>> >
>> >
>> >
>> > 2013/12/29 John D. Ament 
>> >
>> >> The NPE in TomEE appears to be a TomEE bug, not injecting test method
>> >> arguments.
>> >>
>> >> On Sun, Dec 29, 2013 at 10:23 AM, Gerhard Petracek
>> >>  wrote:
>> >> > @john:
>> >> > your change also causes a NullPointerException in
>> >> > ClasspathWebProfileTest#testSuccessfulAmbiguousLookup
>> >> > (with tomee)
>> >> >
>> >> > regards,
>> >> > gerhard
>> >> >
>> >> >
>> >> >
>> >> > 2013/12/29 Gerhard Petracek 
>> >> >
>> >> >> @john:
>> >> >>
>> >> >> you changed it to:
>> >> >>
>> >> >> @Test
>> >> >> public void
>> >> >>
>> >>
>> testAmbiguousFileLookup(@ExternalResource(storage=ClasspathStorage.class,
>> >> >> location="META-INF/beans.xml") InputStream inputStream) {/*...*/}
>> >> >>
>> >> >> -> the exception still occurs, but junit can't handle it any longer
>> >> >> (because it occurs too early).
>> >> >>
>> >> >> regards,
>> >> >> gerhard
>> >> >>
>> >> >>
>> >> >>
>> >> >> 2013/12/29 John D. Ament 
>> >> >>
>> >> >> That's no big deal (& fixed).  I had to add a separate SE &
>> WebProfile
>> >> >>> test since now we're checking for duplicates and the embedded/SE
>> >> >>> containers are picking up the target folders are bean archives (I
>> hope
>> >> >>> TomEE embedded doesn't do this... >_< ).  Using method injection
>> >> >>> delays the injection, however we have a catch that /tmp must be your
>> >> >>> tmpdir (I haven't checked on windows yet, but I'm assuming c:/tmp
>> >> >>> should be fine..)
>> >> >>>
>> >> >>> @gerhard for some reason now your test doesn't throw a
>> >> >>> RuntimeException, but instead the injected instance is null.
>> >> >>>
>> >> >>> On Sun, Dec 29, 2013 at 6:18 AM, Mark Struberg 
>> >> wrote:
>> >> >>> >
>> >> >>> >
>> >> >>> > Well, the explanation is not in the spec but in the JavaDoc.
>> >> >>> >
>> >> >>> > Compare
>> >> >>> >
>> >> >>>
>> >>
>> http://docs.jboss.org/cdi/api/1.0/javax/enterprise/inject/spi/InjectionPoint.html
>> >> >>> >
>> >> >>> > with the new wording in CDI-1.1
>> >> >>> >
>> >> >>> >
>> >> >>>
>> >>
>> http://docs.oracle.com/javaee/7/api/javax/enterprise/inject/spi/InjectionPoint.html
>> >> >>> >
>> >> >>> > I refer to the new sentence
>> >> >>> >
>> >> >>> > "If the injection point is a dynamically selected reference
>> obtained
>> >> >>> then the metadata obtain reflects the injection point of the
>> Instance,
>> >> with
>> >> >>> the required type and any additional required qualifers defined by
>> >> >>> Instance.select()."
>> >> >>> >
>> >> >>> >
>> >> >>> > This theoretically should work in CDI-1.1 containers. Sadly there
>> is
>> >> no
>> >> >>> single

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

[Romain Manni-Bucau]

-0 both injections can be different depending on containers using some
advanced stuff out of ee but affecting ee lifecycle (at least in tomcat)
but your proposal sounds acceptable.
Le 3 janv. 2014 17:58, "Thomas Andraschko"  a
écrit :

> Hi,
>
> IMHO @Web is somehow annoying.
> HttpServlet e.g. is always "web", so @Web is just a overhead and doesn't
> look nice.
>
> Can't we just veto the producers if CDI1.1 is available?
> The code would be the same with CDI 1.0 + DS, CDI 1.1 without or with DS.
>
> Regards,
> Thomas
>

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

[Romain Manni-Bucau]

well in fact I saw a lot of cdi 1.0 app producing http* objects
without qualifier cause it was missing in cdi so conflicts can occurs
and are quite common
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 :
> we had no qualifier for FacesContext (in codi, seam3,...). since it used to
> be a common producer, we saw "compatibility issues".
> however, with a proper documentation (how to veto one of them), no user
> (i'm aware of) had a real issue with it and for the majority it was easier
> to use (because there wasn't an issue at all).
>
> regards,
> gerhard
>
>
>
> 2014/1/4 Mark Struberg 
>
>>
>>
>> The question for me is: are there already known producers for it or is
>> there any spec which introduces this?
>> In that case a custom qualifier is always a good idea imo. Otherwise we
>> would face different behaviour on different containers. They most times
>> behave different...
>> I just would like to avoid possible incompatibilities. And for this a
>> Qualifier certainly works great - without much additional complexity.
>>
>> Does all the needed detection + veto really pay off? How do you know you
>> are running in an environment which already has such a producer registered?
>> This is not easy to accomplish!
>>
>>
>> Thus I'm for keeping it.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> >
>> > From: Gerhard Petracek 
>> >To: dev@deltaspike.apache.org
>> >Sent: Saturday, 4 January 2014, 12:57
>> >Subject: Re: Servlet Module - Do we really need @Web?
>> >
>> >
>> >+1 for a veto in case of cdi 1.1.
>> >
>> >@external producers:
>> >we can document it (how users can veto e.g. producers, if they see any
>> >overlap).
>> >however, deltaspike shouldn't add complexity just because there might be a
>> >custom producer (for the same).
>> >
>> >regards,
>> >gerhard
>> >
>> >
>> >
>> >
>> >2014/1/4 Christian Kaltepoth 
>> >
>> >> @John: Actually the Servlet module provides more than what CDI 1.1 adds.
>> >> For example the event propagation and the recently added "WebStorage"
>> for
>> >> the resource loading and so on. So people may want to add the Servlet
>> >> module even in a CDI 1.1 container.
>> >>
>> >> I'm also +0 for that. Of cause it would be nice to get rid of @Web. For
>> the
>> >> CDI 1.1 case we could actually veto our produces as Thomas suggested.
>> But
>> >> what about other portable extensions that may have producers for
>> @Default.
>> >> Say I'm using CDI 1.0 and also have Solder on the classpath. I think
>> Solder
>> >> is still a common dependency of some libraries, correct? In some regard
>> it
>> >> is nice to have a custom "namespace" for the producers.
>> >>
>> >>
>> >>
>> >> 2014/1/3 Thomas Andraschko 
>> >>
>> >> > Because our customers have different servers (tomcat7 and even 6,
>> >> > glassfish, jboss), so it would be a great enhancement for product
>> >> > development.
>> >> >
>> >> >
>> >> > 2014/1/3 John D. Ament 
>> >> >
>> >> > > If you're in servlet 3.1/CDI 1.1 you don't even need the servlet
>> >> > > module (so why include it as a dependency?)
>> >> > >
>> >> > > On Fri, Jan 3, 2014 at 1:09 PM, Romain Manni-Bucau
>> >> > >  wrote:
>> >> > > > -0 both injections can be different depending on containers using
>> >> some
>> >> > > > advanced stuff out of ee but affecting ee lifecycle (at least in
>> >> > tomcat)
>> >> > > > but your proposal sounds acceptable.
>> >> > > > Le 3 janv. 2014 17:58, "Thomas Andraschko" <
>> >> > andraschko.tho...@gmail.com>
>> >> > > a
>> >> > > > écrit :
>> >> > > >
>> >> > > >> Hi,
>> >> > > >>
>> >> > > >> IMHO @Web is somehow annoying.
>> >> > > >> HttpServlet e.g. is always "web", so @Web is just a overhead and
>> >> > doesn't
>> >> > > >> look nice.
>> >> > > >>
>> >> > > >> Can't we just veto the producers if CDI1.1 is available?
>> >> > > >> The code would be the same with CDI 1.0 + DS, CDI 1.1 without or
>> >> with
>> >> > > DS.
>> >> > > >>
>> >> > > >> Regards,
>> >> > > >> Thomas
>> >> > > >>
>> >> > >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> 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?

[Romain Manni-Bucau]

yes and no, depend what you do of it, the point is if you base your
app on CDI (as much as possible I mean) and it starts to be common,
you can put logic in these producers, typically wrapping of
requests/responses (can be easier than using filters) and in this case
this is often not 1-1 replacement. I know it is doable but needs to
update the app and can break "big apps" where you aggregate multiple
parts.

Having a namespace should be a best practise IMHO.
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:
> i don't see an issue here - if you add the ds-servlet-module, you just drop
> your own producers (which overlap and should do the same anyway).
>
> regards,
> gerhard
>
>
>
> 2014/1/4 Romain Manni-Bucau 
>
>> well in fact I saw a lot of cdi 1.0 app producing http* objects
>> without qualifier cause it was missing in cdi so conflicts can occurs
>> and are quite common
>> 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 :
>> > we had no qualifier for FacesContext (in codi, seam3,...). since it used
>> to
>> > be a common producer, we saw "compatibility issues".
>> > however, with a proper documentation (how to veto one of them), no user
>> > (i'm aware of) had a real issue with it and for the majority it was
>> easier
>> > to use (because there wasn't an issue at all).
>> >
>> > regards,
>> > gerhard
>> >
>> >
>> >
>> > 2014/1/4 Mark Struberg 
>> >
>> >>
>> >>
>> >> The question for me is: are there already known producers for it or is
>> >> there any spec which introduces this?
>> >> In that case a custom qualifier is always a good idea imo. Otherwise we
>> >> would face different behaviour on different containers. They most times
>> >> behave different...
>> >> I just would like to avoid possible incompatibilities. And for this a
>> >> Qualifier certainly works great - without much additional complexity.
>> >>
>> >> Does all the needed detection + veto really pay off? How do you know you
>> >> are running in an environment which already has such a producer
>> registered?
>> >> This is not easy to accomplish!
>> >>
>> >>
>> >> Thus I'm for keeping it.
>> >>
>> >>
>> >> LieGrue,
>> >> strub
>> >>
>> >>
>> >>
>> >>
>> >> >
>> >> > From: Gerhard Petracek 
>> >> >To: dev@deltaspike.apache.org
>> >> >Sent: Saturday, 4 January 2014, 12:57
>> >> >Subject: Re: Servlet Module - Do we really need @Web?
>> >> >
>> >> >
>> >> >+1 for a veto in case of cdi 1.1.
>> >> >
>> >> >@external producers:
>> >> >we can document it (how users can veto e.g. producers, if they see any
>> >> >overlap).
>> >> >however, deltaspike shouldn't add complexity just because there might
>> be a
>> >> >custom producer (for the same).
>> >> >
>> >> >regards,
>> >> >gerhard
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >2014/1/4 Christian Kaltepoth 
>> >> >
>> >> >> @John: Actually the Servlet module provides more than what CDI 1.1
>> adds.
>> >> >> For example the event propagation and the recently added "WebStorage"
>> >> for
>> >> >> the resource loading and so on. So people may want to add the Servlet
>> >> >> module even in a CDI 1.1 container.
>> >> >>
>> >> >> I'm also +0 for that. Of cause it would be nice to get rid of @Web.
>> For
>> >> the
>> >> >> CDI 1.1 case we could actually veto our produces as Thomas suggested.
>> >> But
>> >> >> what about other portable extensions that may have producers for
>> >> @Default.
>> >> >> Say I'm using CDI 1.0 and also have Solder on the classpath. I think
>> >> Solder
>> >> 

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

[Romain Manni-Bucau]

@gerhard: @Decorator is broken in 85% of the case and doesn't work
with producers IIRC
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 can use e.g. @Decorator in such special cases or just do the wrapping
> like you would without cdi.
>
> regards,
> gerhard
>
>
>
> 2014/1/4 Romain Manni-Bucau 
>
>> yes and no, depend what you do of it, the point is if you base your
>> app on CDI (as much as possible I mean) and it starts to be common,
>> you can put logic in these producers, typically wrapping of
>> requests/responses (can be easier than using filters) and in this case
>> this is often not 1-1 replacement. I know it is doable but needs to
>> update the app and can break "big apps" where you aggregate multiple
>> parts.
>>
>> Having a namespace should be a best practise IMHO.
>> 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:
>> > i don't see an issue here - if you add the ds-servlet-module, you just
>> drop
>> > your own producers (which overlap and should do the same anyway).
>> >
>> > regards,
>> > gerhard
>> >
>> >
>> >
>> > 2014/1/4 Romain Manni-Bucau 
>> >
>> >> well in fact I saw a lot of cdi 1.0 app producing http* objects
>> >> without qualifier cause it was missing in cdi so conflicts can occurs
>> >> and are quite common
>> >> 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 :
>> >> > we had no qualifier for FacesContext (in codi, seam3,...). since it
>> used
>> >> to
>> >> > be a common producer, we saw "compatibility issues".
>> >> > however, with a proper documentation (how to veto one of them), no
>> user
>> >> > (i'm aware of) had a real issue with it and for the majority it was
>> >> easier
>> >> > to use (because there wasn't an issue at all).
>> >> >
>> >> > regards,
>> >> > gerhard
>> >> >
>> >> >
>> >> >
>> >> > 2014/1/4 Mark Struberg 
>> >> >
>> >> >>
>> >> >>
>> >> >> The question for me is: are there already known producers for it or
>> is
>> >> >> there any spec which introduces this?
>> >> >> In that case a custom qualifier is always a good idea imo. Otherwise
>> we
>> >> >> would face different behaviour on different containers. They most
>> times
>> >> >> behave different...
>> >> >> I just would like to avoid possible incompatibilities. And for this a
>> >> >> Qualifier certainly works great - without much additional complexity.
>> >> >>
>> >> >> Does all the needed detection + veto really pay off? How do you know
>> you
>> >> >> are running in an environment which already has such a producer
>> >> registered?
>> >> >> This is not easy to accomplish!
>> >> >>
>> >> >>
>> >> >> Thus I'm for keeping it.
>> >> >>
>> >> >>
>> >> >> LieGrue,
>> >> >> strub
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > From: Gerhard Petracek 
>> >> >> >To: dev@deltaspike.apache.org
>> >> >> >Sent: Saturday, 4 January 2014, 12:57
>> >> >> >Subject: Re: Servlet Module - Do we really need @Web?
>> >> >> >
>> >> >> >
>> >> >> >+1 for a veto in case of cdi 1.1.
>> >> >> >
>> >> >> >@external producers:
>> >> >> >we can document it (how users can veto e.g. producers, if they see
>> 

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

[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 like you would do it without cdi anyway.
>
> regards,
> gerhard
>
>
>
> 2014/1/4 Romain Manni-Bucau 
>
>> @gerhard: @Decorator is broken in 85% of the case and doesn't work
>> with producers IIRC
>> 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 can use e.g. @Decorator in such special cases or just do the wrapping
>> > like you would without cdi.
>> >
>> > regards,
>> > gerhard
>> >
>> >
>> >
>> > 2014/1/4 Romain Manni-Bucau 
>> >
>> >> yes and no, depend what you do of it, the point is if you base your
>> >> app on CDI (as much as possible I mean) and it starts to be common,
>> >> you can put logic in these producers, typically wrapping of
>> >> requests/responses (can be easier than using filters) and in this case
>> >> this is often not 1-1 replacement. I know it is doable but needs to
>> >> update the app and can break "big apps" where you aggregate multiple
>> >> parts.
>> >>
>> >> Having a namespace should be a best practise IMHO.
>> >> 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:
>> >> > i don't see an issue here - if you add the ds-servlet-module, you just
>> >> drop
>> >> > your own producers (which overlap and should do the same anyway).
>> >> >
>> >> > regards,
>> >> > gerhard
>> >> >
>> >> >
>> >> >
>> >> > 2014/1/4 Romain Manni-Bucau 
>> >> >
>> >> >> well in fact I saw a lot of cdi 1.0 app producing http* objects
>> >> >> without qualifier cause it was missing in cdi so conflicts can occurs
>> >> >> and are quite common
>> >> >> 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 :
>> >> >> > we had no qualifier for FacesContext (in codi, seam3,...). since it
>> >> used
>> >> >> to
>> >> >> > be a common producer, we saw "compatibility issues".
>> >> >> > however, with a proper documentation (how to veto one of them), no
>> >> user
>> >> >> > (i'm aware of) had a real issue with it and for the majority it was
>> >> >> easier
>> >> >> > to use (because there wasn't an issue at all).
>> >> >> >
>> >> >> > regards,
>> >> >> > gerhard
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > 2014/1/4 Mark Struberg 
>> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> The question for me is: are there already known producers for it
>> or
>> >> is
>> >> >> >> there any spec which introduces this?
>> >> >> >> In that case a custom qualifier is always a good idea imo.
>> Otherwise
>> >> we
>> >> >> >> would face different behaviour on different containers. They most
>> >> times
>> >> >> >> behave different...
>> >> >> >> I just would like to avoid possible incompatibilities. And for
>> this a
>> >> >> >> Qualifier certainly works great - without much additional
>> complexity.
>> >> >&g

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

[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 like you would do it without cdi anyway.
>> >
>> > regards,
>> > gerhard
>> >
>> >
>> >
>> > 2014/1/4 Romain Manni-Bucau 
>> >
>> >> @gerhard: @Decorator is broken in 85% of the case and doesn't work
>> >> with producers IIRC
>> >> 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 can use e.g. @Decorator in such special cases or just do the
>> wrapping
>> >> > like you would without cdi.
>> >> >
>> >> > regards,
>> >> > gerhard
>> >> >
>> >> >
>> >> >
>> >> > 2014/1/4 Romain Manni-Bucau 
>> >> >
>> >> >> yes and no, depend what you do of it, the point is if you base your
>> >> >> app on CDI (as much as possible I mean) and it starts to be common,
>> >> >> you can put logic in these producers, typically wrapping of
>> >> >> requests/responses (can be easier than using filters) and in this
>> case
>> >> >> this is often not 1-1 replacement. I know it is doable but needs to
>> >> >> update the app and can break "big apps" where you aggregate multiple
>> >> >> parts.
>> >> >>
>> >> >> Having a namespace should be a best practise IMHO.
>> >> >> 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:
>> >> >> > i don't see an issue here - if you add the ds-servlet-module, you
>> just
>> >> >> drop
>> >> >> > your own producers (which overlap and should do the same anyway).
>> >> >> >
>> >> >> > regards,
>> >> >> > gerhard
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > 2014/1/4 Romain Manni-Bucau 
>> >> >> >
>> >> >> >> well in fact I saw a lot of cdi 1.0 app producing http* objects
>> >> >> >> without qualifier cause it was missing in cdi so conflicts can
>> occurs
>> >> >> >> and are quite common
>> >> >> >> 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 :
>> >> >> >> > we had no qualifier for FacesContext (in codi, seam3,...).
>> since it
>> >> >> used
>> >> >> >> to
>> >> >

Re: [VOTE] Get rid of @Web in the servlet module

[Romain Manni-Bucau]

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



2014/1/7 Thomas Andraschko :
> Hi all,
>
> based on the discusstion in "Servlet Module - Do we really need @Web?" so
> far, I'd like to call a vote.
>
> +1 get rid of @Web
> +0 no opinion
> -1 keep it
>
> Please vote.
>
> Regards,
> Thomas

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

[Romain Manni-Bucau]

I'd release 0.6 before having it, it will surely create discussion
once we'll get something and it is easy to do something totally
brokenn in particular when we'll want to get something clever in a web
context

btw we shouldn't do it without pivotal IMO
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014/1/22 Jason Porter :
> Do we just want to take what we had in Seam 3 and move it over?
>
>
> On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek <
> gerhard.petra...@gmail.com> wrote:
>
>> hi jason,
>>
>> the bridge doesn't introduce an api and the spi just provides a simple
>> contract for starting the container as well as a bean-filter.
>> -> if needed, we could improve the implementation at any time.
>> imo we should add it before the release of v0.6 (since a lot of users
>> requested such a bridge).
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2014/1/22 Jason Porter 
>>
>> > I'd like to engage the Pivotal Team (anyone have contacts?) to see if we
>> > can get some of there help as well to create a really good integration.
>> >
>> >
>> > On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek <
>> > gerhard.petra...@gmail.com> wrote:
>> >
>> >> hi @ all,
>> >>
>> >> i would like to continue with this discussion.
>> >>
>> >> [1] describes a two-way bridge which is already based on deltaspike.
>> >> it offers a simple spi which allows more advanced add-ons like it is
>> >> mentioned in [2].
>> >>
>> >> regards,
>> >> gerhard
>> >>
>> >> [1]
>> >>
>> http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html
>> >> [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html
>> >>
>> >>
>> >>
>> >> 2013/2/19 Matt Benson 
>> >>
>> >>> Okay, I spent some time with Sam on IRC hashing this out.  Assuming
>> that
>> >>> Seam-Spring is covered under the SG(s?) Red Hat has filed for
>> deltaspike,
>> >>> his view is that it's not terribly important who does the initial code
>> >>> import, though it would be best for a so-authorized Red Hatter to be
>> the
>> >>> one to change the file headers.  I will be out of pocket for the rest
>> of
>> >>> the week beyond today, so if you, Marius, are able to work on the
>> import
>> >>> end of this week/early next then that's in any event as soon as I would
>> >>> have been able to get to it anyway.  Otherwise, anyone can do that,
>> with
>> >>> someone still employed by RH finally applying the change that modifies
>> >>> the
>> >>> headers--which, I suppose, could be prepared by anyone else and simply
>> >>> shared among our private git repos.
>> >>>
>> >>> Matt
>> >>>
>> >>>
>> >>> On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici <
>> >>> marius.bogoev...@gmail.com> wrote:
>> >>>
>> >>> > I still am a participant on this thread, but doing more reading than
>> >>> > writing as of late :)
>> >>> >
>> >>> > So, yes, I've been strapped for time with the job and the transition,
>> >>> but
>> >>> > I'd be happy to help out with this at the end of the week or early
>> >>> next.
>> >>> >
>> >>> > With my CLA on file, and the code being granted already, I'm not sure
>> >>> what
>> >>> > else needs to be done. I'm happy for the code to live in DeltaSpike,
>> >>> fwiw.
>> >>> >
>> >>> > On 2013-02-18, at 6:50 PM, Matt Benson  wrote:
>> >>> >
>> >>> > > Seems Marius's prior participation on this thread was via a gmail
>> >>> > address.
>> >>> > > With him no longer at Red Hat we definitely want to make sure we
>> >>> take the
>> >>> > > necessary precautions wrt IP.
>> >>> > >
>> >>> > > Matt
>> >>> > >
>> >>> > >
>> >>> > > On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter <
>> >>> lightguard

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

[Romain Manni-Bucau]

@Charles: ? don't get the point. You would like to use camel to bridge
spring and cdi? seems just overengineered and not efficient compared
to real integration + why doing a route, setuping camel context just
for it + you need then to use camel proxies to get a "normal" API
which is a lot to get nothing fancy and surely slow.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014/1/23 Charles Moulliard :
> -1. Why would you like to support Spring Integration while we have Apache
> Camel which is the most elaborated Spring Java Integration Framework
> available today, easier to setup, ... proposing also annotations @Produce,
> @Consume to produce an exchange from and to a Camel Route (= list of
> processors)
>
>
> On Wed, Jan 22, 2014 at 7:36 PM, Jason Porter wrote:
>
>> +1 for adding the Spring integration
>>
>>
>> On Wed, Jan 22, 2014 at 11:21 AM, John D. Ament > >wrote:
>>
>> > +1 to Romain
>> > I'd like to see something like this for a 1.0 release.  It would be a
>> > real game changer.
>> >
>> > On Wed, Jan 22, 2014 at 12:03 PM, Romain Manni-Bucau
>> >  wrote:
>> > > I'd release 0.6 before having it, it will surely create discussion
>> > > once we'll get something and it is easy to do something totally
>> > > brokenn in particular when we'll want to get something clever in a web
>> > > context
>> > >
>> > > btw we shouldn't do it without pivotal IMO
>> > > Romain Manni-Bucau
>> > > Twitter: @rmannibucau
>> > > Blog: http://rmannibucau.wordpress.com/
>> > > LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> > > Github: https://github.com/rmannibucau
>> > >
>> > >
>> > >
>> > > 2014/1/22 Jason Porter :
>> > >> Do we just want to take what we had in Seam 3 and move it over?
>> > >>
>> > >>
>> > >> On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek <
>> > >> gerhard.petra...@gmail.com> wrote:
>> > >>
>> > >>> hi jason,
>> > >>>
>> > >>> the bridge doesn't introduce an api and the spi just provides a
>> simple
>> > >>> contract for starting the container as well as a bean-filter.
>> > >>> -> if needed, we could improve the implementation at any time.
>> > >>> imo we should add it before the release of v0.6 (since a lot of users
>> > >>> requested such a bridge).
>> > >>>
>> > >>> regards,
>> > >>> gerhard
>> > >>>
>> > >>>
>> > >>>
>> > >>> 2014/1/22 Jason Porter 
>> > >>>
>> > >>> > I'd like to engage the Pivotal Team (anyone have contacts?) to see
>> > if we
>> > >>> > can get some of there help as well to create a really good
>> > integration.
>> > >>> >
>> > >>> >
>> > >>> > On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek <
>> > >>> > gerhard.petra...@gmail.com> wrote:
>> > >>> >
>> > >>> >> hi @ all,
>> > >>> >>
>> > >>> >> i would like to continue with this discussion.
>> > >>> >>
>> > >>> >> [1] describes a two-way bridge which is already based on
>> deltaspike.
>> > >>> >> it offers a simple spi which allows more advanced add-ons like it
>> is
>> > >>> >> mentioned in [2].
>> > >>> >>
>> > >>> >> regards,
>> > >>> >> gerhard
>> > >>> >>
>> > >>> >> [1]
>> > >>> >>
>> > >>>
>> >
>> http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html
>> > >>> >> [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html
>> > >>> >>
>> > >>> >>
>> > >>> >>
>> > >>> >> 2013/2/19 Matt Benson 
>> > >>> >>
>> > >>> >>> Okay, I spent some time with Sam on IRC hashing this out.
>>  Assuming
>> > >>> that
>> > >>> >>> Seam-Spring is

Re: [DISCUSS] DeltaSpike Launch Module

[Romain Manni-Bucau]

Hi

I see the use case but deltaspike needs so much work on existing code (jsf,
security, transactional, data for the one I see) that I think we shouldnt
add new things while we dont propose something working fine out of the box.

Wdyt?
Le 7 févr. 2014 02:31, "John D. Ament"  a écrit :

> Hi all
>
> I've been working a bit on a POC.  The idea is to run a light weight
> Java SE application that does some basic bootstrapping and container
> services. The SE app would be configured with a basic socket listener
> using Netty and delegate requests to a REST provider.  The idea behind
> it is that CDI forms the low level core of the "container", where a
> developer can deploy services they build on their own.  The
> application is meant to be an API type server (deploy REST APIs) that
> runs using Netty, starts up a CDI container using DeltaSpike Container
> Control API.  The launch module would handle the basic bootstrap of
> the rest provider, instantiating the CDI container using
> ContainerControl, and handle the necessary bootstrap for lookup up
> resources and registering with the provider.  This type of module
> would compete with Spring Boot.
>
> Currently what I have leverages Weld 2.1.1 and RestEasy.  The
> equivalent should work for CXF.  There's no hard dependency on Weld.
>
> I was thinking the module structure would include an api, spi,
> impl-resteasy and impl-cxf.
>
> Some things I'd like to add:
>
> - Automatic bootstrap of JPA (via JPA module)
> - Transaction intercepting (probably need to pull in the Geronimo lib)
> - Probably also register some providers automatically as well.
>
> Let me know your thoughts.
>
> John
>

Re: Interceptors not being called in JUnit-aware CDI environment

[Romain Manni-Bucau]

HI

You want to intercept the test? so it means the runner needs to invoke
"business" methods of the test class which is not the case by default
(ie result shouldn't be built from a newInstance() but from a
beanManager.getXXX()).
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-02-07  :
> Hello,
>
> I've been trying to start the CDI container during Junit-Testing as described 
> at the following page,
>
> http://struberg.wordpress.com/2012/03/27/unit-testing-strategies-for-cdi-based-projects/
>
> though I'm using Junit 4 and implemented everything using a new Runner (to 
> annotate tests with @RunWith). I kind of got inspired by he CDIUnit project, 
> but it works only with Weld and I want to use OpenWebBeans.
> The major things like injection work perfectly, however, I realized, that 
> even though I implemented the following code to provided a CDI aware 
> Test-Class, an interceptor annotation on a test method is completely ignored, 
> thus the interceptors AroundInvoke annotated method is not called.
>
> private  T createTest(final Class testClass) throws Exception
> {
> final BeanManager beanManager = cdiContainer.getBeanManager();
>
> final CreationalContext creationalContext = 
> beanManager.createCreationalContext(null);
>
> final AnnotatedType annotatedType = 
> beanManager.createAnnotatedType(testClass);
> final InjectionTarget injectionTarget = 
> beanManager.createInjectionTarget(annotatedType);
>
> final T result = (T) 
> getTestClass().getOnlyConstructor().newInstance();
>
> injectionTarget.inject(result, creationalContext);
>
> return result;
> }
>
> Is this expected behaviour? I'm not so familiar with how interceptors are 
> really implemented, but I would have guest that after providing a creational 
> context and complete injection for the test class, interceptor annotations 
> should work too. The interceptor itself is registered correctly. It is listed 
> among all interceptors when calling
>
> WebBeansContext.currentInstance().getInterceptorsManager().getCdiInterceptors()
>
> however, a test annotated with the interceptor does not trigger execution of 
> the AroundInvoke-method.
>
> Would be great, if somebody has a thought or a hint on this.
>
> Thanks,
>
> Heiko
>
>
> If you are not the addressee, please inform us immediately that you have 
> received this e-mail by mistake, and delete it. We thank you for your support.
>

Re: Interceptors not being called in JUnit-aware CDI environment

[Romain Manni-Bucau]

is you test class scanned by cdi? I mean did you provide a
META-INF/beans.xml for tests?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-02-07  :
> Hello Romain,
>
> thank you for your fast response. Yes I want to intercept the test itself.
>
> I've checked into various ways on how to actually create a bean, however 
> nothing worked out. You mention to call beanManager.getXXX() but for my point 
> that is not enough information.
>
> I tried to retrieve the beans of the test class via beanManager.getBeans() 
> but regardless of what I try as annotation literals there (non, Any, etc.) 
> nothing works, the list is always empty. What method exactly did you have in 
> mind here?
>
> Thanks,
>
> Heiko
>
>> -Ursprüngliche Nachricht-
>> Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
>> Gesendet: Freitag, 7. Februar 2014 08:26
>> An: dev@deltaspike.apache.org
>> Betreff: Re: Interceptors not being called in JUnit-aware CDI environment
>>
>> =
>> ==
>>
>> ATTENTION! This message contains suspicious URL(s) possibly redirecting to
>> malicious content. Our security gateways target known problem URLs like
>> freeweb or URL Shorteners that are being abused by spammers. Some
>> examples would be groups.google.com or tinyurl.com. Please check the sender
>> and hyperlinks in the e-mail accurately before clicking on a link. If this 
>> email
>> seems obviously bad to you please delete it.  More information is available 
>> on
>> our website Information Security @ Daimler: http://intra.corpintra.net/intra-
>> is-e/spam
>>
>> =
>> ==
>>
>> ACHTUNG! Diese E-Mail enthält verdächtige URLs welche möglicherweise auf
>> schädlichen Inhalt verweisen. Die Security Gateways prüfen auf bekannte
>> Problem-URLs  wie zum Beispiel URL-Abkürzungen, die bevorzugt von
>> Spammern mißbraucht werden (tinyurl.com, groups.google.com, ...). Bitte
>> prüfen Sie den Absender und die URLs in dieser E-Mail gewissenhaft bevor sie
>> die verknüpften Inhalte aufrufen. Bitte löschen Sie diese E-Mail, wenn Sie 
>> der
>> Meinung sind, daß sich der Verdacht bestätigt. Weitere Informationen zu
>> unerwünschter E-Mail / SPAM finden Sie auf den Seiten der
>> Informationssicherheit bei Daimler unter: 
>> http://intra.corpintra.net/intra-is-
>> d/spam
>>
>> =========
>> ==
>>
>>
>> HI
>>
>> You want to intercept the test? so it means the runner needs to invoke
>> "business" methods of the test class which is not the case by default (ie 
>> result
>> shouldn't be built from a newInstance() but from a beanManager.getXXX()).
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2014-02-07  :
>> > Hello,
>> >
>> > I've been trying to start the CDI container during Junit-Testing as
>> > described at the following page,
>> >
>> > http://struberg.wordpress.com/2012/03/27/unit-testing-strategies-for-c
>> > di-based-projects/
>> >
>> > though I'm using Junit 4 and implemented everything using a new Runner (to
>> annotate tests with @RunWith). I kind of got inspired by he CDIUnit project, 
>> but
>> it works only with Weld and I want to use OpenWebBeans.
>> > The major things like injection work perfectly, however, I realized, that 
>> > even
>> though I implemented the following code to provided a CDI aware Test-Class,
>> an interceptor annotation on a test method is completely ignored, thus the
>> interceptors AroundInvoke annotated method is not called.
>> >
>> > private  T createTest(final Class testClass) throws Exception
>> > {
>> > final BeanManager beanManager = cdiContainer.getBeanManager();
>> >
>> > final CreationalContext creationalContext =
>> > beanManager.createCreationalContext(null);
>> >
>> > final AnnotatedType annotatedType =
>> beanManager.createAnnotatedType(testClass);
>> > final InjectionTarget injectionTarget =
>> > beanManager.createInjectionTarget(annotatedType);
>> >
>> > final T resu

Re: [jira] [Commented] (DELTASPIKE-518) DS Data should support Wrapped JPA APIs

[Romain Manni-Bucau]

@JL it should be running with snapshot too
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-02-07 Jean-Louis MONTEIRO :
> Sure, I cannot commit, so for now, my patch is running fine locally ;-)
> On Monday I can just refresh my local repo and recompile everything.
>
> Thanks anyway.
> JLouis
>
>
> 2014-02-07 Thomas Hug :
>
>> If it can wait 'til the weekend I can pick it up :-)
>>
>>
>> On Fri, Feb 7, 2014 at 9:21 AM, Jean-Louis MONTEIRO > >wrote:
>>
>> > Thanks Thomas.
>> > Will you do that yourself, or do you want me to do the arquillian test
>> and
>> > submit a new patch?
>> >
>> > JLouis
>> >
>> >
>> > 2014-02-07 Thomas Hug (JIRA) :
>> >
>> > >
>> > > [
>> > >
>> >
>> https://issues.apache.org/jira/browse/DELTASPIKE-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894286#comment-13894286
>> > ]
>> > >
>> > > Thomas Hug commented on DELTASPIKE-518:
>> > > ---
>> > >
>> > > Looks good. I'd prefer an Arquillian test though so we can also get rid
>> > of
>> > > the OpenJPA test dependency.
>> > >
>> > > > DS Data should support Wrapped JPA APIs
>> > > > ---
>> > > >
>> > > > Key: DELTASPIKE-518
>> > > > URL:
>> > > https://issues.apache.org/jira/browse/DELTASPIKE-518
>> > > > Project: DeltaSpike
>> > > >  Issue Type: Bug
>> > > >  Components: Data-Module
>> > > >Affects Versions: 0.5
>> > > >Reporter: Jean-Louis MONTEIRO
>> > > >Assignee: Romain Manni-Bucau
>> > > > Fix For: 0.6
>> > > >
>> > > > Attachments: DELTASPIKE-518.patch
>> > > >
>> > > >
>> > > > In containers like TomEE, you usually don't get the provider
>> > > implementation directly but a wrapper instead. Currently, DS data fails
>> > > saying it does not know the provider.
>> > >
>> > >
>> > >
>> > > --
>> > > This message was sent by Atlassian JIRA
>> > > (v6.1.5#6160)
>> > >
>> >
>> >
>> >
>> > --
>> > Jean-Louis
>> >
>>
>
>
>
> --
> Jean-Louis

Re: [DISCUSS] DeltaSpike Launch Module

[Romain Manni-Bucau]

not only, data module for insatnce is not that usable while not linked
to transactions so we need to see how we link modules between themself
(basically that's done for security at least) and get something
working out of the box (a basic JTA integration and another one with
@Transactional would be awesome).
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-02-07 Jean-Louis MONTEIRO :
> +1
> The core is very stable.
> Users are afraid by 0.5 or 0.6 in terms of quality.
> From my experience with DS, core module at least is very stable.
>
> JSF and Data work fine as well.
> Currently, we don't have a 1.0 mainly because some other modules are not
> totally merged nor stable maybe, right?
>
> Jean-Louis
>
>
> 2014-02-07 Mark Struberg :
>
>> Agree, it sounds good but I'd rather focus on (finnally!) shipping DS-1.0
>> for now.
>>
>> I'll give it a tough test drive in the next weeks to see what we miss
>> before the milestone.
>>
>> John, you could probably do a draft on github?
>>
>> LieGrue,
>> stru
>>
>>
>>
>>
>> On Friday, 7 February 2014, 6:15, Romain Manni-Bucau <
>> rmannibu...@gmail.com> wrote:
>>
>> Hi
>> >
>> >I see the use case but deltaspike needs so much work on existing code
>> (jsf,
>> >security, transactional, data for the one I see) that I think we shouldnt
>> >add new things while we dont propose something working fine out of the
>> box.
>> >
>> >Wdyt?
>> >
>> >Le 7 févr. 2014 02:31, "John D. Ament"  a écrit :
>> >
>> >> Hi all
>> >>
>> >> I've been working a bit on a POC.  The idea is to run a light weight
>> >> Java SE application that does some basic bootstrapping and container
>> >> services. The SE app would be configured with a basic socket listener
>> >> using Netty and delegate requests to a REST provider.  The idea behind
>> >> it is that CDI forms the low level core of the "container", where a
>> >> developer can deploy services they build on their own.  The
>> >> application is meant to be an API type server (deploy REST APIs) that
>> >> runs using Netty, starts up a CDI container using DeltaSpike Container
>> >> Control API.  The launch module would handle the basic bootstrap of
>> >> the rest provider, instantiating the CDI container using
>> >> ContainerControl, and handle the necessary bootstrap for lookup up
>> >> resources and registering with the provider.  This type of module
>> >> would compete with Spring Boot.
>> >>
>> >> Currently what I have leverages Weld 2.1.1 and RestEasy.  The
>> >> equivalent should work for CXF.  There's no hard dependency on Weld.
>> >>
>> >> I was thinking the module structure would include an api, spi,
>> >> impl-resteasy and impl-cxf.
>> >>
>> >> Some things I'd like to add:
>> >>
>> >> - Automatic bootstrap of JPA (via JPA module)
>> >> - Transaction intercepting (probably need to pull in the Geronimo lib)
>> >> - Probably also register some providers automatically as well.
>> >>
>> >> Let me know your thoughts.
>> >>
>> >> John
>> >>
>> >
>> >
>>
>
>
>
> --
> Jean-Louis

Re: AW: Interceptors not being called in JUnit-aware CDI environment

[Romain Manni-Bucau]

Side note: you can also use a JUnit @Rule ;)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-02-07 Gerhard Petracek :
> hi heiko,
>
> you can use CdiTestRunner + configure true for:
> deltaspike.testcontrol.use_test_class_as_cdi_bean
>
> 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-07 :
>
>> Hello Mark,
>>
>> thank you for your input. Your idea would have been much easier than what
>> I did :-)
>>
>> When you write a Junit Runner, you have the ability to control the test
>> class creation by overwriting createTest() and returning your instance. By
>> default this is simply the newInstance() call for the constructor with no
>> arguments of the test class. The following code will therefore not only
>> provide injection but even create a fully creational contexted bean that
>> even will trigger interceptors. I've made sure though, that after calling
>> all 'AfterClass'-Annotations, the creational context is released too, so
>> the bean does not stick around.
>>
>> I do not really have a clue though how this could be done with TestNg.
>>
>> I might miss out some clearContexts() here. I thought about cleaning the
>> contexts before a new test-method is run, however I loose all beans
>> discovered and created while the container booted, and that lead to failing
>> tests. I need the container being created BEFORE createTest() is called to
>> be able to do the bean creation. I have to dive into this more deeply.
>> Another Idea would be to simply boot the container again before each method
>> and shut it down afterwards, though this will slow down tests.
>>
>> public class TestRunner extends BlockJUnit4ClassRunner
>> {
>> private Class clazz;
>> private CreationalContext creationalContext;
>>
>> public TestRunner(final Class clazz) throws InitializationError
>> {
>> super(clazz);
>>
>> this.clazz = clazz;
>>
>> cdiContainer = CdiContainerLoader.getCdiContainer();
>> cdiContainer.boot();
>> cdiContainer.getContextControl().startContexts();
>> }
>>
>> @Override
>> protected Object createTest()
>> throws Exception
>> {
>> return createTest(clazz);
>> }
>>
>> @SuppressWarnings("unchecked")
>> private  T createTest(final Class testClass) throws Exception
>> {
>> final BeanManager beanManager = cdiContainer.getBeanManager();
>>
>> final Set> beans = beanManager.getBeans(testClass);
>>
>> assert !beans.isEmpty();
>>
>> final Bean bean = beans.iterator().next();
>> creationalContext = beanManager.createCreationalContext(bean);
>>
>> final T result = (T) beanManager.getReference(bean, testClass,
>> creationalContext);
>>
>> return result;
>> }
>>
>> @Override
>> protected Statement withAfterClasses(final Statement statement)
>> {
>> final Statement defaultStatement =
>> super.withAfterClasses(statement);
>>
>> return new Statement()
>> {
>>
>> @Override
>> public void evaluate()
>> throws Throwable
>> {
>> try
>> {
>> defaultStatement.evaluate();
>> }
>> finally
>> {
>> creationalContext.release();
>> }
>> }
>>
>> };
>> }
>>
>> Regards,
>>
>> Heiko
>>
>> > -Ursprüngliche Nachricht-
>> > Von: Mark Struberg [mailto:strub...@yahoo.de]
>> > Gesendet: Freitag, 7. Februar 2014 09:29
>> > An: dev@deltaspike.apache.org
>> > Betreff: Re: AW: Interceptors not being called in JUnit-aware CDI
>> environment
>> >
>> > =
>> > ==
>> >
>> > ATTENTION! This message contains suspicious URL(s) possibly redirecting
>> to
>> > malicious content. Our security gateways target known problem URLs like
>> > freeweb or URL Shortene

Re: Revisit cdiCtrl module name and how it's inconsistent with test-control?

[Romain Manni-Bucau]

test-control could be renamed cdi-unit or something like it IMHO
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-02-10 11:28 GMT+01:00 Gerhard Petracek :
> i wouldn't move test-control, since it's a module based on deltaspike-core.
> (cdictrl isn't based on deltaspike-core.)
>
> regards,
> gerhard
>
>
>
> 2014-02-10 11:15 GMT+01:00 Mark Struberg :
>
>> Well, cdictrl is released already. Thus I would rather not change it's
>> name.
>> test-control is not yet released. So that would be easier to change.
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>> On Sunday, 9 February 2014, 20:16, Karl Kildén 
>> wrote:
>>
>> Hello,
>> >
>> >I know it's been discussed before but now with a module called
>> test-control
>> >it just feel unnecessary to be inconsistent even though cdiCtrl is not a
>> >module it's not so pretty...
>> >
>> >Cheers / Karl
>> >
>> >
>> >
>>

Re: [Discuss] Data Module - Transactional Repositories

[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: Revisit cdiCtrl module name and how it's inconsistent with test-control?

[Romain Manni-Bucau]

well I don't agree on modules hierarchy which looks inconsistent but I
dont really care while code is here but I agree with Mark names are
already used 'in fact it is true for this and for core) so we
shouldn't change it anymore.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-02-14 9:38 GMT+01:00 Karl Kildén :
> As far as I understand , it would be more symmetric from the outside /
> overview but technically asymmetric because the dependencies are different.
>
> But the name change feels harmless and would bring balance to the force.
>
>
> On 14 February 2014 09:31, Thomas Andraschko 
> wrote:
>
>> IMHO there is no difference between our modules and cdictrl.
>>
>> However, we should rename it to something like "container-control" to match
>> our other project names.
>>
>>
>>
>> 2014-02-14 8:55 GMT+01:00 Mark Struberg :
>>
>> > I'm still -1 (veto) because I'm not convinced that it has ANY benefit.
>> >
>> >
>> > The issue is that CdiCtrl as a whole has NOTHING to do with our real
>> > 'modules'. They do not share even a single import, do not even have a
>> > dependency to ds-core.
>> >
>> >
>> > How would you explain a fresh user who is looking at our code that all
>> the
>> > parent pom dependencies do not get used only in this very project? How do
>> > you prevent other people from adding dependencies randomly?
>> >
>> > It also has a different build lifecycle basically. Actually it's really
>> > more a project part on it's own than just a module for ds-core.
>> >
>> > I'm a bit undecided about the test-control. It needs CdiCtrl _and_
>> > ds-core. But it's also essentially not a ds module neither.
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> >
>> >
>> > On Monday, 10 February 2014, 13:23, Gerhard Petracek <
>> > gerhard.petra...@gmail.com> wrote:
>> >
>> > +1 there is no issue with api-/name-/... changes >before< v1. we had a
>> > >similar change in codi (before v1) and there was no issue with it.
>> > >(+ we emphasized the possibility of such changes from the very
>> beginning).
>> > >
>> > >if we change something like that, we should also re-visit the
>> > >security-module (the initial reason for creating an own module isn't
>> there
>> > >any longer).
>> > >
>> > >regards,
>> > >gerhard
>> > >
>> > >
>> > >
>> > >
>> > >2014-02-10 13:17 GMT+01:00 Thomas Andraschko <
>> andraschko.tho...@gmail.com
>> > >:
>> > >
>> > >> Can't we change the parent?
>> > >> IMHO renaming isn't a problem if we do it BEFORE 1.0.
>> > >>
>> > >>
>> > >> 2014-02-10 13:07 GMT+01:00 Mark Struberg :
>> > >>
>> > >> > We could rename the module, but I'd rather not move it under modules
>> > >> > because they don't have the same parent. And we also must not change
>> > the
>> > >> > artifactId as cdictrl is already heavily used in projects.
>> > >> >
>> > >> >
>> > >> > LieGrue,
>> > >> > strub
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> > On Monday, 10 February 2014, 13:05, Thomas Andraschko <
>> > >> > andraschko.tho...@gmail.com> wrote:
>> > >> >
>> > >> > +1 for renaming to container-controler and both under modules
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > >2014-02-10 12:28 GMT+01:00 John D. Ament :
>> > >> > >
>> > >> > >> -1 for cdi unit (name already in use for the exact same purpose)
>> > >> > >>
>> > >> > >> +1 for renaming cdictrl to container-control
>> > >> > >>
>> > >> > >> +1 for aligning both under modules (even though cdictrl has no
>> > deps on
>> > >> > >> core, making it a module makes it easier to understand from a
>> > user's
>> > >> > >> point of view).
>> >

Re: Revisit cdiCtrl module name and how it's inconsistent with test-control?

[Romain Manni-Bucau]

that's not true at all, depend the virality of the code. CdiCtrl and
core are viral now. So either we say users to not use DS before 0.1 or
we keep stability on used modules. Honestly I don't think we have the
choice if we want to promote what we propose. We are late for a 1.0 so
already too much used so we have 1.0 constraints already. Only new
modules don't have them.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-02-14 10:46 GMT+01:00 Gerhard Petracek :
> imo the definition should be simple: if it depends on deltaspike-core, it's
> a module
>
> @romain:
>
> again:
>> there is no issue with api-/name-/... changes >before< v1. we had a
> similar change in codi (before v1) and there was no issue with it.
>> (+ we emphasized the possibility of such changes from the very beginning).
>
> regards,
> gerhard
>
>
>
> 2014-02-14 10:08 GMT+01:00 Romain Manni-Bucau :
>
>> well I don't agree on modules hierarchy which looks inconsistent but I
>> dont really care while code is here but I agree with Mark names are
>> already used 'in fact it is true for this and for core) so we
>> shouldn't change it anymore.
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2014-02-14 9:38 GMT+01:00 Karl Kildén :
>> > As far as I understand , it would be more symmetric from the outside /
>> > overview but technically asymmetric because the dependencies are
>> different.
>> >
>> > But the name change feels harmless and would bring balance to the force.
>> >
>> >
>> > On 14 February 2014 09:31, Thomas Andraschko <
>> andraschko.tho...@gmail.com>wrote:
>> >
>> >> IMHO there is no difference between our modules and cdictrl.
>> >>
>> >> However, we should rename it to something like "container-control" to
>> match
>> >> our other project names.
>> >>
>> >>
>> >>
>> >> 2014-02-14 8:55 GMT+01:00 Mark Struberg :
>> >>
>> >> > I'm still -1 (veto) because I'm not convinced that it has ANY benefit.
>> >> >
>> >> >
>> >> > The issue is that CdiCtrl as a whole has NOTHING to do with our real
>> >> > 'modules'. They do not share even a single import, do not even have a
>> >> > dependency to ds-core.
>> >> >
>> >> >
>> >> > How would you explain a fresh user who is looking at our code that all
>> >> the
>> >> > parent pom dependencies do not get used only in this very project?
>> How do
>> >> > you prevent other people from adding dependencies randomly?
>> >> >
>> >> > It also has a different build lifecycle basically. Actually it's
>> really
>> >> > more a project part on it's own than just a module for ds-core.
>> >> >
>> >> > I'm a bit undecided about the test-control. It needs CdiCtrl _and_
>> >> > ds-core. But it's also essentially not a ds module neither.
>> >> >
>> >> > LieGrue,
>> >> > strub
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Monday, 10 February 2014, 13:23, Gerhard Petracek <
>> >> > gerhard.petra...@gmail.com> wrote:
>> >> >
>> >> > +1 there is no issue with api-/name-/... changes >before< v1. we had a
>> >> > >similar change in codi (before v1) and there was no issue with it.
>> >> > >(+ we emphasized the possibility of such changes from the very
>> >> beginning).
>> >> > >
>> >> > >if we change something like that, we should also re-visit the
>> >> > >security-module (the initial reason for creating an own module isn't
>> >> there
>> >> > >any longer).
>> >> > >
>> >> > >regards,
>> >> > >gerhard
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >2014-02-10 13:17 GMT+01:00 Thomas Andraschko <
>> >> andraschko.tho...@gmail.com
>> >> > >:
>> >> > >
>> >> 

Re: Revisit cdiCtrl module name and how it's inconsistent with test-control?

[Romain Manni-Bucau]

that's the main point of the discussion I think. We are consistent
with what we said but users can't wait for years so we are too used to
maintain it.

+1 for a vote
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-02-14 11:33 GMT+01:00 Gerhard Petracek :
> we would need a vote about your statement, because it changes our official
> statement.
> if the majority agrees, we have to postpone such discussions (e.g. until
> v2).
>
> a lot of users are still waiting for v1 before they start with deltaspike.
> -> we are late, but according to our official statement we are still in the
> pre v1 mode/phase.
>
> regards,
> gerhard
>
>
>
> 2014-02-14 10:49 GMT+01:00 Romain Manni-Bucau :
>
>> that's not true at all, depend the virality of the code. CdiCtrl and
>> core are viral now. So either we say users to not use DS before 0.1 or
>> we keep stability on used modules. Honestly I don't think we have the
>> choice if we want to promote what we propose. We are late for a 1.0 so
>> already too much used so we have 1.0 constraints already. Only new
>> modules don't have them.
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2014-02-14 10:46 GMT+01:00 Gerhard Petracek :
>> > imo the definition should be simple: if it depends on deltaspike-core,
>> it's
>> > a module
>> >
>> > @romain:
>> >
>> > again:
>> >> there is no issue with api-/name-/... changes >before< v1. we had a
>> > similar change in codi (before v1) and there was no issue with it.
>> >> (+ we emphasized the possibility of such changes from the very
>> beginning).
>> >
>> > regards,
>> > gerhard
>> >
>> >
>> >
>> > 2014-02-14 10:08 GMT+01:00 Romain Manni-Bucau :
>> >
>> >> well I don't agree on modules hierarchy which looks inconsistent but I
>> >> dont really care while code is here but I agree with Mark names are
>> >> already used 'in fact it is true for this and for core) so we
>> >> shouldn't change it anymore.
>> >> Romain Manni-Bucau
>> >> Twitter: @rmannibucau
>> >> Blog: http://rmannibucau.wordpress.com/
>> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> >> Github: https://github.com/rmannibucau
>> >>
>> >>
>> >>
>> >> 2014-02-14 9:38 GMT+01:00 Karl Kildén :
>> >> > As far as I understand , it would be more symmetric from the outside /
>> >> > overview but technically asymmetric because the dependencies are
>> >> different.
>> >> >
>> >> > But the name change feels harmless and would bring balance to the
>> force.
>> >> >
>> >> >
>> >> > On 14 February 2014 09:31, Thomas Andraschko <
>> >> andraschko.tho...@gmail.com>wrote:
>> >> >
>> >> >> IMHO there is no difference between our modules and cdictrl.
>> >> >>
>> >> >> However, we should rename it to something like "container-control" to
>> >> match
>> >> >> our other project names.
>> >> >>
>> >> >>
>> >> >>
>> >> >> 2014-02-14 8:55 GMT+01:00 Mark Struberg :
>> >> >>
>> >> >> > I'm still -1 (veto) because I'm not convinced that it has ANY
>> benefit.
>> >> >> >
>> >> >> >
>> >> >> > The issue is that CdiCtrl as a whole has NOTHING to do with our
>> real
>> >> >> > 'modules'. They do not share even a single import, do not even
>> have a
>> >> >> > dependency to ds-core.
>> >> >> >
>> >> >> >
>> >> >> > How would you explain a fresh user who is looking at our code that
>> all
>> >> >> the
>> >> >> > parent pom dependencies do not get used only in this very project?
>> >> How do
>> >> >> > you prevent other people from adding dependencies randomly?
>> >> >> >
>> >> >> > It also has a different build lifecycle basically. Actually it

Re: Revisit cdiCtrl module name and how it's inconsistent with test-control?

[Romain Manni-Bucau]

+0 for position
-1 for name or maven coordinates
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-02-14 13:21 GMT+01:00  :
> Seems this way. I think this whole dicussion is becoming ridicuolus. Change 
> it to comply with the rest. I personally never understood why this very 
> lonely 'module' cdiCtrl is located elsewhere, regardless on whether it has 
> different dependencies or not.  Additionally it does not fit into the naming 
> scheme used otherwise. It's a version 0.6 and regardless of how often it is 
> used, the name change can be reflected on the website and we are dealing with 
> developers here. They are most likely capable of changing an artifact's name, 
> don't you think?
>
> So for a vote:
>
> +1 for changing it's name.
> +1 for changing it's position.
>
> My two cents,
>
> Heiko
>
>> -Ursprüngliche Nachricht-
>> Von: John D. Ament [mailto:john.d.am...@gmail.com]
>> Gesendet: Freitag, 14. Februar 2014 12:28
>> An: deltaspike
>> Betreff: Re: Revisit cdiCtrl module name and how it's inconsistent with test-
>> control?
>>
>>
>> So, we're voting on starting a vote at this point as to whether or not we can
>> change a JAR's name pre 1.0?
>>
>> On Fri, Feb 14, 2014 at 5:42 AM, Romain Manni-Bucau
>>  wrote:
>> > that's the main point of the discussion I think. We are consistent
>> > with what we said but users can't wait for years so we are too used to
>> > maintain it.
>> >
>> > +1 for a vote
>> > Romain Manni-Bucau
>> > Twitter: @rmannibucau
>> > Blog: http://rmannibucau.wordpress.com/
>> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> > Github: https://github.com/rmannibucau
>> >
>> >
>> >
>> > 2014-02-14 11:33 GMT+01:00 Gerhard Petracek
>> :
>> >> we would need a vote about your statement, because it changes our
>> >> official statement.
>> >> if the majority agrees, we have to postpone such discussions (e.g.
>> >> until v2).
>> >>
>> >> a lot of users are still waiting for v1 before they start with deltaspike.
>> >> -> we are late, but according to our official statement we are still
>> >> -> in the
>> >> pre v1 mode/phase.
>> >>
>> >> regards,
>> >> gerhard
>> >>
>> >>
>> >>
>> >> 2014-02-14 10:49 GMT+01:00 Romain Manni-Bucau
>> :
>> >>
>> >>> that's not true at all, depend the virality of the code. CdiCtrl and
>> >>> core are viral now. So either we say users to not use DS before 0.1
>> >>> or we keep stability on used modules. Honestly I don't think we have
>> >>> the choice if we want to promote what we propose. We are late for a
>> >>> 1.0 so already too much used so we have 1.0 constraints already.
>> >>> Only new modules don't have them.
>> >>> Romain Manni-Bucau
>> >>> Twitter: @rmannibucau
>> >>> Blog: http://rmannibucau.wordpress.com/
>> >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> >>> Github: https://github.com/rmannibucau
>> >>>
>> >>>
>> >>>
>> >>> 2014-02-14 10:46 GMT+01:00 Gerhard Petracek
>> :
>> >>> > imo the definition should be simple: if it depends on
>> >>> > deltaspike-core,
>> >>> it's
>> >>> > a module
>> >>> >
>> >>> > @romain:
>> >>> >
>> >>> > again:
>> >>> >> there is no issue with api-/name-/... changes >before< v1. we had
>> >>> >> a
>> >>> > similar change in codi (before v1) and there was no issue with it.
>> >>> >> (+ we emphasized the possibility of such changes from the very
>> >>> beginning).
>> >>> >
>> >>> > regards,
>> >>> > gerhard
>> >>> >
>> >>> >
>> >>> >
>> >>> > 2014-02-14 10:08 GMT+01:00 Romain Manni-Bucau
>> :
>> >>> >
>> >>> >> well I don't agree on modules hierarchy which looks inconsistent
>> >>> >> but I dont really care while code is here but I agree with Mark
>> >>> >

Re: Revisit cdiCtrl module name and how it's inconsistent with test-control?

[Romain Manni-Bucau]

Hmm deprecating is pushing it later imo
Le 14 févr. 2014 19:47, "John D. Ament"  a écrit :

> I'm fine with that approach.  I was thinking we could provide a shaded
> jar under the old coordinates and old package, perhaps even with a
> warning in the log that you should not be using this.
>
> On Fri, Feb 14, 2014 at 12:54 PM, Matt Benson 
> wrote:
> > It seems that the inertia of users already relying on cdiCtrl is the
> > stickiest point. Why not complete the move and continue to publish a
> > deprecated version under the existing coordinates and packaging, with the
> > warning that users should be ready to switch by 1.0 or perhaps 1.1? This
> > would be simple to accomplish with Maven.
> >
> > $0.02 in the interest of peace,
> > Matt
> > On Feb 14, 2014 10:41 AM, "John D. Ament" 
> wrote:
> >
> >> I guess I'm kind of curious why this is such a polarized issue.
> >>
> >> On Fri, Feb 14, 2014 at 9:07 AM, Thomas Andraschko
> >>  wrote:
> >> > +1 for changing the name and location BEFORE 1.0
> >> >
> >> > Otherwise it will probably not happen...
> >> >
> >> >
> >> > 2014-02-14 15:04 GMT+01:00 Gerhard Petracek <
> gerhard.petra...@gmail.com
> >> >:
> >> >
> >> >> +1 for changing the name and location of cdictrl
> >> >>
> >> >> regards,
> >> >> gerhard
> >> >>
> >> >>
> >> >>
> >> >> 2014-02-14 13:27 GMT+01:00 Romain Manni-Bucau  >:
> >> >>
> >> >> > +0 for position
> >> >> > -1 for name or maven coordinates
> >> >> > Romain Manni-Bucau
> >> >> > Twitter: @rmannibucau
> >> >> > Blog: http://rmannibucau.wordpress.com/
> >> >> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> >> > Github: https://github.com/rmannibucau
> >> >> >
> >> >> >
> >> >> >
> >> >> > 2014-02-14 13:21 GMT+01:00  :
> >> >> > > Seems this way. I think this whole dicussion is becoming
> ridicuolus.
> >> >> > Change it to comply with the rest. I personally never understood
> why
> >> this
> >> >> > very lonely 'module' cdiCtrl is located elsewhere, regardless on
> >> whether
> >> >> it
> >> >> > has different dependencies or not.  Additionally it does not fit
> into
> >> the
> >> >> > naming scheme used otherwise. It's a version 0.6 and regardless of
> how
> >> >> > often it is used, the name change can be reflected on the website
> and
> >> we
> >> >> > are dealing with developers here. They are most likely capable of
> >> >> changing
> >> >> > an artifact's name, don't you think?
> >> >> > >
> >> >> > > So for a vote:
> >> >> > >
> >> >> > > +1 for changing it's name.
> >> >> > > +1 for changing it's position.
> >> >> > >
> >> >> > > My two cents,
> >> >> > >
> >> >> > > Heiko
> >> >> > >
> >> >> > >> -Ursprüngliche Nachricht-
> >> >> > >> Von: John D. Ament [mailto:john.d.am...@gmail.com]
> >> >> > >> Gesendet: Freitag, 14. Februar 2014 12:28
> >> >> > >> An: deltaspike
> >> >> > >> Betreff: Re: Revisit cdiCtrl module name and how it's
> inconsistent
> >> >> with
> >> >> > test-
> >> >> > >> control?
> >> >> > >>
> >> >> > >>
> >> >> > >> So, we're voting on starting a vote at this point as to whether
> or
> >> not
> >> >> > we can
> >> >> > >> change a JAR's name pre 1.0?
> >> >> > >>
> >> >> > >> On Fri, Feb 14, 2014 at 5:42 AM, Romain Manni-Bucau
> >> >> > >>  wrote:
> >> >> > >> > that's the main point of the discussion I think. We are
> >> consistent
> >> >> > >> > with what we said but users can't wait for years so we are too
> >> used
> >> >> to
> >> >> > >> > maintain it.

Re: [Discuss] Data Module - Transactional Repositories

[Romain Manni-Bucau]

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] Data Module - Transactional Repositories

[Romain Manni-Bucau]

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?

[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!
>>
>>
>>