Re: [DISCUSS] deltaspike-0.5 features

[Karl Kildén]

1+ For JSF stuff The bridge between JSF ExceptionHandler and DS Exception
Handling  feels like pretty low hanging fruit? The implementation from Seam
Faces seems good to me, maybe use BeanManagerProvider to fire the event
instead.

1+ For JPA Generic Repository. But if it hinders the plan to release 0.5
after a shorter cycle I'd rather wait.

1+ Servlet Module - same as above.

Thanks a lot for 0.4 release btw

Cheers / Karl



2013/6/3 Adrian Gonzalez 

> 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
> >
> >
> > On 6/1/2013 23:45, Matt Benson wrote:
> >> RE Bean Validation, I agree and enthusiastically invite anyone who has
> an
> >> itch to work on Bean Validation and CDI to come help out implementing BV
> >> 1.1 at Apache BVal :D
> >>
> >> Matt
> >>
> >>
> >> On Sat, Jun 1, 2013 at 8:20 AM, Gerhard Petracek <
> gerhard.petra...@gmail.com
> >>> wrote:
> >>> as mentioned earlier i'm not sure about the bv parts (just for
> injection).
> >>> therefore you just need to enable any bv 1.1 implementation (via
> >>> default-provider) and you get even more.
> >>>
> >>> @thomas:
> >>> the only missing parts besides that are the remaining scopes (the rest
> is
> >>> in already).
> >>>
> >>> imo it's way more important to finish [1].
> >>>
> >>> regards,
> >>> gerhard
> >>>
> >>> [1] https://issues.apache.org/jira/browse/DELTASPIKE-335
> >>>
> >>>
> >>>
> >>> 2013/6/1 Thomas Andraschko 
> >>>
>  the most important feature are propably:
>  - finish the extended JSF scopes
>  - type view navigation
>  - injection BV artifacts
> 
>  so the most users could switch from CODI to DS. We currently do not
> use
>  more features in the most apps.
> 
> 
>  2013/6/1 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 t

Re: CDI Query import

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

Re: CDI Query import

[Karl Kildén]

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

Re: CDI Query import

[Karl Kildén]

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

Re: Deltaspike fails to detect Javascript in IE8

[Karl Kildén]

John,

  always worked for me
so it sounds pretty weird I think but then again it's IE...

Regarding this whole feature and the decisions and configuration one must
do I feel it's a bit tough. I have not read the current docs for this but I
tried it in CODI and  felt uncomfortable with it. Good doc + examples are
really needed for a feature like this imo.

cheers


2013/7/18 John D. Ament 

> Hi Martjin,
>
> Actually, we found a very similar issue in our apps at work.  We have some
> machines w/ IE8, others with IE9 and IE10.  For some reason, IE8 was
> downgrading to IE7.  Found that there was a browser setting causing it to
> render all intranet sites in "compatibility mode."  Thanks MS!  We're not
> using a JSF front end, instead bootstrap + backbone + lots of other jquery
> goodies.  As far as  i know, this isn't something the app can fix (in fact,
> when I tried putting in headers to fix it, I was able to fix it locally but
> not when it was running on our QA machines).
>
> John
>
>
> On Thu, Jul 18, 2013 at 11:51 AM, Martijn Hiemstra  >wrote:
>
> > Hi everybody, Strub,
> >
> > You mention the following:
> > In general I'd say that any inhouse application utilizing JFS-2 should
> have
> > JavaScript enabled. The non-javascript days are gone - we must get over
> it
> > ;)
> > Without JavaScript your app would not work anyway.
> >
> > That is the issue. We have Javascript enabled. Primefaces with all it's
> > Javascript worked perfectly together with Myfaces CODI on all browsers
> even
> > the older ones. This issue started once we switched to Deltaspike and now
> > any browser that doesn't support html5 sees the message. In deltaspike
> > there is a file called windowhandler.html and it's causing the message to
> > appear. The message appears if the browser doesn't support html5 even
> when
> > you have Javascript enabled.
> >
> > Our clients want to open our website in different tabs to view different
> > pages at the same time so that they can compare information on the
> website
> > so as I understand setting ClientWindowRenderMode.NONE isn't an option?
> >
> > Perhaps I don't understand how the window handeling works however if we
> are
> > using the "default" settings won't alot of people get this Javascript
> error
> > detection? Clients who visit your website will be forced to use the most
> > modern version of their browser to view the website and that's not always
> > possible.
> >
> > Thanks in advance,
> > Martijn
> >
> >
> >
> > 2013/7/18 Mark Struberg 
> >
> > > Hi Martin!
> > >
> > > Heiko already pointed you in the right direction. You can even disable
> or
> > > tweak the window handling depending on e.g. the UserAgent (we already
> > > exclude bots for example).
> > >
> > >
> > > > Will there be a permanent solution? Is it solvable in Deltapike? Or
> is
> > it
> > > > perhaps an Internet explorer issue?
> > >
> > > In general I'd say that any inhouse application utilizing JFS-2 should
> > > have JavaScript enabled. The non-javascript days are gone - we must get
> > > over it ;)
> > > Without JavaScript your app would not work anyway.
> > >
> > > There are basically 3 modes for the window detection.
> > >
> > > * none - all browser tab see the same information
> > >
> > > * lazy - rewrite the windowId in JavaScript on the target page. Be
> aware
> > > that the first page hit might trash the beans from your original
> browser
> > > tab! It works fine if you take care about this in your app design.
> > >
> > > * clientwindow - we render a small and fast intermediate page which
> does
> > > the browser tab detection and then forwards to the destination page.
> > >
> > > I did installations where we use the clientwindow mode for all in-house
> > > clients but switch to lazy mode for all public internet usage (based on
> > the
> > > request IP). We also only enable clientwindow for UserAgents which are
> > > known to support html5 (due to the localstorage trick for getting rid
> of
> > > the flickering).
> > >
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > > - Original Message -
> > > From: Martijn Hiemstra 
> > > To: dev@deltaspike.apache.org
> > > Cc:
> > > Sent: Wednesday, 17 July 2013, 14:41
> > > Subject: Re: Deltaspike fails to detect Javascript in IE8
> > >
> > > Our clients have found a work around by putting our website in the list
> > of
> > > trusted websites.
> > >
> > > Will there be a permanent solution? Is it solvable in Deltapike? Or is
> it
> > > perhaps an Internet explorer issue?
> > >
> > > Martijn Hiemstra
> > >
> > >
> > >
> > >
> > >
> > > 2013/7/17 
> > >
> > > > Hello Martijn,
> > > >
> > > > we've had the same issue. This is related to the client window
> > handling,
> > > > that targets modern browsers supporting HTML5.
> > > >
> > > > Simply add a class to your application with the following content:
> > > >
> > > > @Specializes
> > > > public class OurClientWindowConfig extends DefaultClientWindowConfig
> > > > {
> > > > private static final l

CMS diff: Documentation

[Karl Kildén]

Clone URL (Committers only):
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://deltaspike.apache.org/documentation.mdtext

Karl Kildén

Index: trunk/content/documentation.mdtext
===
--- trunk/content/documentation.mdtext  (revision 1528283)
+++ trunk/content/documentation.mdtext  (working copy)
@@ -56,13 +56,13 @@
 In the listings below replace the placeholders for the version with the 
version of your choice or use:
 
 
-0.4
+0.5
 
  
 Or if you want to very bleeding edge, point to our current snapshot.
 
 
-0.5-SNAPSHOT
+0.6-SNAPSHOT
 
 
 ### Configuration of DeltaSpike Core

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

[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 *
> >*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/d

Re: CDI ContextControl - only available in SE mode?

[Karl Kildén]

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?

[Karl Kildén]

I think 1.0 sounds great. Improving docs would be the best way to move
deltaspike forward imo. My major concern right now is the windowId stuff. I
like many want the functionality but struggles with dual ids (windowId &
dsRid) a loading splash. Would love docs here that covers the different
strategies and routes one can take.

cheers



On 15 November 2013 14:31, Christian Kaltepoth wrote:

> +1 for releasing 1.0 next
> -1 for subreleases. This would be very confusing.
> +1 for improving the documentation before the 1.0 release. This is IMHO
> more important than examples.
>
>
> 2013/11/11 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
> > > >
> > >
> >
>
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>

Re: Simple Cron Module

[Karl Kildén]

I really like this idea! 1+

cheers / Karl


On 16 December 2013 17:55, Gerhard Petracek wrote:

> hi @ all,
>
> we could also combine it with [1].
>
> regards,
> gerhard
>
> [1] http://s.apache.org/MOc
>
>
>
> 2013/12/6 Thomas Andraschko 
>
> > Arne, can i rework it and provide a patch?
> > Do you know what needs to be reworked?
> >
> >
> > 2013/12/4 Thomas Andraschko 
> >
> > > Hi,
> > >
> > > Arne's extensions looks good.
> > > It's a different approach compared to seam but i like it.
> > >
> > > Regards,
> > > Thomas
> > >
> > >
> > > 2013/12/4 Arne Limburg 
> > >
> > >> Hi all,
> > >>
> > >> Gerhard is right. I wrote such stuff some time ago.
> > >> It needs some rework to be integrated in deltaspike, but we can take
> it.
> > >> You find the code here:
> > >>
> > >>
> >
> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-job
> > >> So, if anyone wants to review, feel free…
> > >>
> > >> Regards,
> > >> Arne
> > >>
> > >> Von: Gerhard Petracek  > >> gerhard.petra...@gmail.com>>
> > >> Datum: Mittwoch, 4. Dezember 2013 09:59
> > >> An: "dev@deltaspike.apache.org" <
> > >> dev@deltaspike.apache.org>
> > >> Cc: Arne Limburg  > >> arne.limb...@openknowledge.de>>
> > >> Betreff: Re: Simple Cron Module
> > >>
> > >> afaik arne has an existing quartz-integration to donate.
> > >>
> > >> regards,
> > >> gerhard
> > >>
> > >>
> > >>
> > >> 2013/12/3 Romain Manni-Bucau  > >> rmannibu...@gmail.com>>
> > >> 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  > >> andraschko.tho...@gmail.com>>:
> > >> > My problem is that some customers just have a tomcat, without
> JavaEE.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > 2013/12/3 Romain Manni-Bucau  > >> rmannibu...@gmail.com>>
> > >> >
> > >> >> 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  > >> nathan.den...@monarchnc.org>>:
> > >> >> > 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
> >  > >> 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: Servlet Module - Do we really need @Web?

[Karl Kildén]

This is my summary:

By following the discussion it seems to be seen as convenient vs
inconvenient and the vote is kinda even. What I would like to see is
cohesion in Deltaspike overall. Either you use namespaces or you don't. My
point is basically that it feels more like a project-wide decision.

To summarize, when a spec or w/e is expected to introduce the same producer
different strategies can be used. So either the strategy as a user is to a)
use the namespace and drop it when someone else provides it (i.e a spec) or
b) Trust Deltaspike to handle any conflicts.

pros:
- No conflicts or conflict management.
- Users can use both variants for example if Deltaspike offers extras.
Apparently already true for Servlet Module.
- Abolishes the idea of transparent replacement with the argument that
various enhancements might make it incompatible anyways.

cons:
- Must remove namespace when Deltaspike is superfluous. No namespace and
automatic veto would make it more seamless.
- More verbose and not as pretty to use.
- Does not see incompatibly as a big problem. Reasoning is:  End user must
test application behavior after upgrade anyway and problems should be minor.

Btw i'm +0


On 4 January 2014 17:09, Gerhard Petracek wrote:

> to summarize it:
> so far we haven't seen a real blocker for dropping the qualifier.
>
> regards,
> gerhard
>
>
>
> 2014/1/4 Romain Manni-Bucau 
>
> > never said it was blocking, just it shouldn't be done blindly and docs
> > should be very explicit on it and potential conflict (usually we don't
> > care to not mention we don't use a qualifier, here we do).
> > Romain Manni-Bucau
> > Twitter: @rmannibucau
> > Blog: http://rmannibucau.wordpress.com/
> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > Github: https://github.com/rmannibucau
> >
> >
> >
> > 2014/1/4 Gerhard Petracek :
> > > it was just one of several possibilities you have.
> > > in any case, the special case you mentioned is still easy enough ->
> there
> > > is no issue/blocker imo.
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2014/1/4 Romain Manni-Bucau 
> > >
> > >> so didnt get your comment on decorators...
> > >> Romain Manni-Bucau
> > >> Twitter: @rmannibucau
> > >> Blog: http://rmannibucau.wordpress.com/
> > >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >> Github: https://github.com/rmannibucau
> > >>
> > >>
> > >>
> > >> 2014/1/4 Gerhard Petracek :
> > >> > @romain:
> > >> > you should do the wrapping 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.li

Re: JSF - default ClientWindowRenderMode?

[Karl Kildén]

If I ever were to post a meme to this mail list it would probably be:

"If my application could have just one of dsRid and windowId and no loading
splash I would be so happy"

cheers


On 9 January 2014 22:52, Thomas Andraschko wrote:

> Hi,
>
> currently the default rendering mode is our windowhandler js/html way.
> Many people don't like it because you always get a loading screen for EACH
> GET request:
>
>
> http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike
> https://issues.apache.org/jira/browse/DELTASPIKE-454
>
> i readded a URL rendering mode in DS like it was in CODI.
> I know that it doesn't cover all cases but it's likely enough for the most
> users.
>
> What do you think about making the URL mode as default like it was in CODI
> before?
>
> Regards,
> Thomas
>

Re: JSF Security regression

[Karl Kildén]

/*q


On 6 February 2014 18:08, Jean-Louis MONTEIRO  wrote:

> Hello guys,
>
> I'm currently facing a regression on Securty module.
> Just wanted to know if you are aware of?
>
> I was using 0.5 with the following
> @View(basePath = "/", extension = "xhtml", navigation =
> View.NavigationMode.REDIRECT)
> public interface Navigation extends ViewConfig {
> @View
> class Index implements Navigation {}
>
> @View
> class Login implements Navigation {}
>
> @View(basePath = "/post/")
> interface PostsNavigation extends Navigation {}
>
> @View
> class Post implements PostsNavigation {}
>
> @Secured(LoggedInUserVoter.class)
> interface SecuredPostsNavigation extends PostsNavigation {}
>
> @View(name = "create-post")
> class CreatePost implements SecuredPostsNavigation {}
>
> @View(name = "edit-post")
> class EditPost implements SecuredPostsNavigation {}
> }
>
> When I switch to 0.6-SNAPSHOT (cause of the DS Data bug), it does not work
> anymore.
> Here is the error
> INFO - class:
> org.apache.deltaspike.jsf.impl.config.view.ViewConfigPathValidator
> activated=true
> SEVERE - invalid view-config found
> java.lang.IllegalStateException: path '/navigation/securedPostsNavigation/'
> is missing, but mapped by:
>
> com.github.rmannibucau.blog.front.controller.Navigation$SecuredPostsNavigation
>
> If you are not aware, I will investigate and propose a fix.
>
> JLouis
>
> --
> Jean-Louis
>

Re: JSF Security regression

[Karl Kildén]

I apologize for my last email, currently babysitting...


On 6 February 2014 19:30, Karl Kildén  wrote:

> /*q
>
>
> On 6 February 2014 18:08, Jean-Louis MONTEIRO  wrote:
>
>> Hello guys,
>>
>> I'm currently facing a regression on Securty module.
>> Just wanted to know if you are aware of?
>>
>> I was using 0.5 with the following
>> @View(basePath = "/", extension = "xhtml", navigation =
>> View.NavigationMode.REDIRECT)
>> public interface Navigation extends ViewConfig {
>> @View
>> class Index implements Navigation {}
>>
>> @View
>> class Login implements Navigation {}
>>
>> @View(basePath = "/post/")
>> interface PostsNavigation extends Navigation {}
>>
>> @View
>> class Post implements PostsNavigation {}
>>
>> @Secured(LoggedInUserVoter.class)
>> interface SecuredPostsNavigation extends PostsNavigation {}
>>
>> @View(name = "create-post")
>> class CreatePost implements SecuredPostsNavigation {}
>>
>> @View(name = "edit-post")
>> class EditPost implements SecuredPostsNavigation {}
>> }
>>
>> When I switch to 0.6-SNAPSHOT (cause of the DS Data bug), it does not work
>> anymore.
>> Here is the error
>> INFO - class:
>> org.apache.deltaspike.jsf.impl.config.view.ViewConfigPathValidator
>> activated=true
>> SEVERE - invalid view-config found
>> java.lang.IllegalStateException: path
>> '/navigation/securedPostsNavigation/'
>> is missing, but mapped by:
>>
>> com.github.rmannibucau.blog.front.controller.Navigation$SecuredPostsNavigation
>>
>> If you are not aware, I will investigate and propose a fix.
>>
>> JLouis
>>
>> --
>> Jean-Louis
>>
>
>

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

[Karl Kildén]

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

V 1.0 getting close... Logotype?

[Karl Kildén]

Hello! By following the discussions you seem to draw closer and closer to
1.0. I think it would be appropriate to end the project name (or was that
settled?) and logotype discussions before.

I myself is -1 for name change and +1 for the logotype that's currently in
the header

Cheers!

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

[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).
> > >> > >>
> > >> > >> Personally, since it's an upgrade of the version # people just
> > need to
> > >> > >> be aware of it when doing the upgrade locally in their projects
> > (e.g.
> > >> > >> we can put some notes out there on what needs to be done to
> > upgrade).
> > >> > >>
> > >> > >> On Mon, Feb 10, 2014 at 5:47 AM, Romain Manni-Bucau
> > >> > >>  wrote:
> > >> > >> > test-control could be renamed cdi-unit or something like it
> IMHO
> > >> > >> > Romain Manni-Bucau
> > >> > >> > Twitter: @rmannibucau
> > >> > >> > Blog: http://rmannibucau.wordpress.com/
> > >> > >> > LinkedI

Fwd: [ANNOUNCE] Release of Apache DeltaSpike 0.6

[Karl Kildén]

Big congratulations and thanks!

-- Forwarded message --
From: Gerhard Petracek 
Date: 20 March 2014 09:38
Subject: [ANNOUNCE] Release of Apache DeltaSpike 0.6
To: "dev@deltaspike.apache.org" ,
us...@deltaspike.apache.org


The Apache DeltaSpike team is pleased to announce the 6th release of
DeltaSpike.

Apache DeltaSpike is not a CDI-container, but a portable CDI extension.

Documentation:
http://deltaspike.apache.org/documentation.html

Release Notes:
http://s.apache.org/DeltaSpike_06

Enjoy!

Re: Extended Persistent Context

[Karl Kildén]

I am also curious about best practice for this (right now) and perhaps in
the future. The thing is the Deltaspike /CDI style is very nice to work
with and it would be a preferred API for me.


On 8 April 2014 13:33, Rafael Meireles  wrote:

> Hello everyone, I would like to know if you think about create an option
> that exists in seam 2, that I can open the entitymanager for many requests?
>

Problem with PreViewConfigNavigateEvent #getFromView

[Karl Kildén]

Hello,

PreViewConfigNavigateEvent getFromView() gives
me org.apache.deltaspike.core.api.config.view.ViewRef$Manual rather then my
actual source. toView works as expected.

This is a very simple demo app running on TomEE.

Should I create a jira and attach my project?

cheers

CMS diff: Container & Control

[Karl Kildén]

Clone URL (Committers only):
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://deltaspike.apache.org/container-control.mdtext

Karl Kildén

Index: trunk/content/container-control.mdtext
===
--- trunk/content/container-control.mdtext  (revision 1588841)
+++ trunk/content/container-control.mdtext  (working copy)
@@ -28,9 +28,26 @@
   - The **ContextControl** interface allows to control the life-cycle of the 
built-in contexts of the CDI container.
 
 ## CdiContainer
+You can use the CdiContainerLoader as a simple factory to gain access to the 
underlying CdiContainer implementation. This is of little interest for Java EE 
applications since the CDI Container 
+already gets properly booted and shut down by the Servlet container 
integration.
+
 
-See the Java SE part [above](#start-a-cdi-container-using-java-se).
+:::java
+// this will give you a CdiContainer for Weld or OWB, depending on the jar 
you added
+CdiContainer cdiContainer = CdiContainerLoader.getCdiContainer();
 
+// now we gonna boot the CDI container. This will trigger the classpath 
scan, etc
+   cdiContainer.boot();
+
+// and finally we like to start all built-in contexts
+cdiContainer.getContextControl().startContexts();
+
+// now we can use CDI in our SE application.
+// And there is not a single line of OWB or Weld specific code in your 
project!
+
+// finally we gonna stop the container
+cdiContainer.shutdown();
+
 ## ContextControl usage
 
 The `ContextControl` interface allows you to start and stop built-in standard 
Contexts like `@RequestScoped`, `@ConversationScoped`, `@SessionScoped`, etc. 
It is provided as `@Dependent` bean and can get injected in the classic CDI 
way. This is not only usable in Java SE projects but also very helpful in 
Servlets and Java EE containers.

Suggestion: Include CDI Bean Mock concept in Test-Control

[Karl Kildén]

Hello!

Sometimes odd use cases makes it hard to mock out stuff when you use
Test-Control. For that reason Gerhard wrote a test-control addon for
mocking. I think it should be added as a feature in Test-Control. Example
is for example to be able to mock Repositories from data-module.

http://os890.blogspot.com/2014/05/add-on-mock-cdi-beans-with-deltaspike.html

cheers

Re: [DISCUSS] next release as 1.0?

[Karl Kildén]

+0 because I would really like to see a logotype selected before 1.0.

I am aware of https://issues.jboss.org/browse/DESIGN-520 and I am also fine
with going with one already proposed. I just feel that every project needs
a good logo


On 19 May 2014 11:55, Christian Kaltepoth  wrote:

> +1
>
>
> 2014-05-19 11:34 GMT+02:00 Romain Manni-Bucau :
>
> > +1
> >
> >
> >
> > Romain Manni-Bucau
> > Twitter: @rmannibucau
> > Blog: http://rmannibucau.wordpress.com/
> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > Github: https://github.com/rmannibucau
> >
> >
> > 2014-05-19 11:13 GMT+02:00 Mark Struberg :
> >
> > > Hi!
> > >
> > > Is there ANYTHING which holds us back from moving our version to 1.0?
> > >
> > > We are long overdue and there are SOOO many companies using DeltaSpike
> in
> > > production since years now...
> > >
> > > LieGrue,
> > > strub
> > >
> >
>
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>

Re: [DISCUSS] next release as 1.0?

[Karl Kildén]

"Design help for the logo"

Saw that mail just now, sounds great :-)


On 19 May 2014 12:37, Karl Kildén  wrote:

> +0 because I would really like to see a logotype selected before 1.0.
>
> I am aware of https://issues.jboss.org/browse/DESIGN-520 and I am also
> fine with going with one already proposed. I just feel that every project
> needs a good logo
>
>
> On 19 May 2014 11:55, Christian Kaltepoth  wrote:
>
>> +1
>>
>>
>> 2014-05-19 11:34 GMT+02:00 Romain Manni-Bucau :
>>
>> > +1
>> >
>> >
>> >
>> > Romain Manni-Bucau
>> > Twitter: @rmannibucau
>> > Blog: http://rmannibucau.wordpress.com/
>> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> > Github: https://github.com/rmannibucau
>> >
>> >
>> > 2014-05-19 11:13 GMT+02:00 Mark Struberg :
>> >
>> > > Hi!
>> > >
>> > > Is there ANYTHING which holds us back from moving our version to 1.0?
>> > >
>> > > We are long overdue and there are SOOO many companies using
>> DeltaSpike in
>> > > production since years now...
>> > >
>> > > LieGrue,
>> > > strub
>> > >
>> >
>>
>>
>>
>> --
>> Christian Kaltepoth
>> Blog: http://blog.kaltepoth.de/
>> Twitter: http://twitter.com/chkal
>> GitHub: https://github.com/chkal
>>
>
>

Re: Data Module - Provide an abstract base entity class?

[Karl Kildén]

Hi,

The gain is that the collective behind the data module are pretty much the
people I would hire to write my base class if I could ;)

It also unifies how stuff is done etc...


On 20 May 2014 13:03, Romain Manni-Bucau  wrote:

> Hi
>
> +-0 nothing particular against but not sure the real gain is
>
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
> 2014-05-20 12:57 GMT+02:00 Thomas Andraschko  >:
>
> > Hi,
> >
> > WDYT about providing an abstract base entity?
> > I always copy this from project to project...
> >
> > Here is a example:
> > https://gist.github.com/tandraschko/a5a79c4edb3e742fc75b
> >
> > Regards,
> > Thomas
> >
>

Re: DeltaSpike examples; real uses of WindowScope and view-controller callbacks

[Karl Kildén]

Sounds awesome :-)

ConversationScoped is a do it yourself and could cover any need for this
reason but whenever you have data that is supposed to be unique per tab
then WindowScoped is very nice and a ready to use solution.

For example a text editor with the content saved in WindowScoped bean so
they can continue to navigate around in the system, come back and write
some more etc. And they can have several cases like this active at the same
time in different tabs. Many scopes could produce the same result but
WindowScoped is quite natural for a case like this imo.

Maybe the content needs to be saved more securely then just by memory but
"undo" and "redo" etc could still be useful to save.

 Imagine you save all user auth info in WindowScoped instead.  Then Another
thing is features like "view as someone else". I like this for sites like
facebook where I want to know exactly how my profile looks like for someone
else. That button that lets you preview it could open the preview in a new
tab and simply be authorized as a random other visitor in @WindowScoped


cheers Karl




On 6 June 2014 19:26, Gerhard Petracek  wrote:

> hi ron,
>
> first of all: great news & thx!
>
> @window-scope:
> e.g. menu-state per window or if you need to support one user per window,
> you can store the active user in a window-scoped holder.
>
> @view-controller:
> e.g. @PreRenderView to load data before the rendering-process,...
>
> you could have a look e.g. at [1]
>
> regards,
> gerhard
>
> [1] https://github.com/os890/tomee_mf_stack_001/tree/codi2ds
>
>
>
> 2014-06-06 19:14 GMT+02:00 Ron Smeral :
>
> > Hi,
> >
> > a small team in JBoss QE has started covering DeltaSpike with examples.
> > We've identified ~30 features/use-cases and come up with ~10 ideas for
> > examples that could demonstrate those features. We plan to implement this
> > during the summer.
> >
> > However, we had a hard time thinking of real world use cases for certain
> > features, like:
> > * multi-window handling, i.e. the window scope: What are the real uses
> for
> > this, where the conversation scope doesn't suffice?
> > * view-controller callbacks: I understand that it allows e.g. to have a
> > shared controller for multiple views (right?), which implements a common
> > aspect, or just to easily perform operations at certain JSF phases. But
> > what would that shared aspect or those operations be, in a real
> > application? Maybe except for the classics that are logging and security.
> >
> > I'm writing this to the dev list, as I assume that most DS committers use
> > DS in production and can provide some insight into how DeltaSpike is
> > commonly used.
> >
> > Thanks!
> >
> > Regards,
> > Ron
> >
> > --
> > Ron Smeral
> > JBoss Quality Engineer
> > Brno
> >
> >
>

Re: [data] dto and isNew

[Karl Kildén]

I wrote a response to the users list but not sure it came through. It kinda
belongs in this thread so here it goes.


So I ran into issues with the DTO mapper api and voiced my concerns in irc.
I saw this discussion and now I am trying the solution present in the
current SNAPSHOT. However I have one comment / question:

What if my Entity has a relationship to another Entity?

Like this:

public class User extends BaseAuditEntity {

@Column
private String name;

@Column
@ManyToOne
@JoinColumn(name="group_id")
private Group group;

This means my userDTO may come with a GroupDTO and how do I map that
relationship? Or to explain by code please fill in the question marks below
;) or if you feel my implementation is weird then I would gladly accept
comments on that too. But the way I see it I need to @Inject the
GroupMapper, use the EntityManager to find the Group then call
groupMapper.toEntity and then I think to myself that the API is worse now
because before I could call groupMapper.toEntity with only a dto argument.
At that point you had to use the entitymanager anyways to find "yourself"
and that feels clean compared to find your entities you form relationships
with.

@Override
protected User toEntity(final User user, final UserDTO userDTO) {
MapperUtil.toAuditEntity(user, userDTO);
user.setName(userDTO.getName());
user.setEmail(userDTO.getEmail());
user.setLocale(userDTO.getLocale());
user.setGroup(*?*);
return user;
}

Cheers / Karl


On 17 May 2014 16:40, Romain Manni-Bucau  wrote:

> Yep, missed it.
>
> Works for me. Maybe the name should be closer to other methods,
> mapKey? But whatever you choose as name this solution works :).
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
> 2014-05-17 15:54 GMT+02:00 Thomas Hug :
> > It's the PK, not the Entity ;) In SimpleQueryInOutMapperBase, it could be
> > something like
> >
> > @Inject
> > private QueryInvocationContext context;
> >
> > protected abstract Object getPrimaryKey(Dto dto);
> >
> > protected E findEntity(Object pk)
> > {
> > return (E) context.getEntityManager().find(context.getEntityClass(),
> > pk);
> > }
> >
> > @Override
> > public Object mapParameter(final Object parameter)
> > {
> > Object pk = getPrimaryKey((Dto) parameter);
> > if (pk != null)
> > {
> > E entity = findEntity(pk);
> > return toEntity(entity, (Dto) parameter);
> > }
> > return toEntity(newEntity(), (Dto) parameter);
> > }
> >
> >
> > On Sat, May 17, 2014 at 1:57 PM, Romain Manni-Bucau
> > wrote:
> >
> >> would work while return is  and not Object ;)
> >>
> >>
> >> Romain Manni-Bucau
> >> Twitter: @rmannibucau
> >> Blog: http://rmannibucau.wordpress.com/
> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> Github: https://github.com/rmannibucau
> >>
> >>
> >> 2014-05-17 11:47 GMT+02:00 Thomas Hug :
> >> > Or a protected abstract Object getPrimaryKey(Dto dto). We can get the
> EM
> >> > over an injected QueryInvocationContext.
> >> >
> >> >
> >> > On Thu, May 15, 2014 at 9:06 PM, Romain Manni-Bucau
> >> > wrote:
> >> >
> >> >> I think a protected findEntity(id) in the mapper can be enough.
> >> >>
> >> >>
> >> >> Romain Manni-Bucau
> >> >> Twitter: @rmannibucau
> >> >> Blog: http://rmannibucau.wordpress.com/
> >> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> >> Github: https://github.com/rmannibucau
> >> >>
> >> >>
> >> >> 2014-05-07 22:29 GMT+02:00 Thomas Hug :
> >> >> > Hi Romain,
> >> >> > See your point. But if we only get the DTO - with what would we
> call
> >> the
> >> >> > find? Could even be that the PK is a DTO or encoded / encrypted and
> >> needs
> >> >> > to go through the mapper first. Maybe we can provide some
> convenience
> >> >> > methods in the base mapper?
> >> >> >
> >> >> >
> >> >> > On Tue, May 6, 2014 at 7:41 PM, Romain Manni-Bucau <
> >> >> rmannibu...@gmail.com>wrote:
> >> >> >
> >> >> >> Hi guys,
> >> >> >>
> >> >> >> DTO feature is awesome but doesn't work in update mode since isNew
> >> >> >> doesn't use a managed entity.
> >> >> >>
> >> >> >> When using a mapper we should call find and pass it to the mapper
> (or
> >> >> >> create a new unmanaged entity if not found). So mapper signature
> >> >> >> should be Entity toEntity(Entity, DTO) no?
> >> >> >>
> >> >> >> Otherwise users need to do the find in the mapper...almost
> eveytime.
> >> >> >>
> >> >> >> wdyt?
> >> >> >>
> >> >> >>
> >> >> >> Romain Manni-Bucau
> >> >> >> Twitter: @rmannibucau
> >> >> >> Blog: http://rmannibucau.wordpress.com/
> >> >> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> >> >> Github: https://github.com/rmannibucau
> >> >> >>
> >> >>
> >>
>

Re: [data] dto and isNew

[Karl Kildén]

Hi and hrmmm,

What if user group was changed?  groupMapper.toEntity(user.getGroup(),
userDto.getGroup()); This would then operate on stale data unless you fetch
and send in correct group. And managing new groups is easy for me I think,
I would call the method using groupMapper.toEntity(new Group(),
userDto.getGroup());


I would much prefer all three methods to be non protected. Then I could
create my helper something along the lines of this:

I did not test this very well but unless I thought wrong completely it
would be a one time thing to implement. But using mappers from mappers are
hard because if the relationship is declared in both ways you can get
circular references. Anyways here's my helper I theorycrafted together:


Group g = fetch (new Group(), user.getGroup(), groupMapper);

public  Entity fetch(Entity entity, Dto dto,
SimpleQueryInOutMapperBase entityMapper){
Object pk = entityMapper.getPrimaryKey(dto);
Entity foundEntity = (Entity) entityManager.find(entity.getClass(),
pk);

if (foundEntity == null) {
foundEntity = entity;
}
return entityMapper.toEntity(foundEntity, dto);
}



One could always create their own base class overriding the protected
methods and adding that fetch helper I guess...

cheers








On 13 June 2014 12:54, Thomas Hug  wrote:

> Hey Karl
>
> Sorry missed your mail indeed - it's probably time I subscribe to the user
> mailing list too :-)
>
> You can still chain those mappers together, but I agree the casting and
> wiring is clunky. As options I see:
> - we add a public E toEntity(Dto dto) back which basically does the same as
> mapParameter now (just hides the casting) for new entities
> - we make the E toEntity(Entity e, Dto dto) public as well, so it's quite
> easy to chain mapper calls for updates
>
> groupMapper.toEntity(user.getGroup(), userDto.getGroup());
>
> You will still have to have some conditionals to see which one to call,
> also depends on your data model (required relations, lazy or eager fetch).
> How does that look? Better ideas?
>
>
>
> On Fri, Jun 13, 2014 at 8:42 AM, Karl Kildén 
> wrote:
>
> > I wrote a response to the users list but not sure it came through. It
> kinda
> > belongs in this thread so here it goes.
> >
> >
> > So I ran into issues with the DTO mapper api and voiced my concerns in
> irc.
> > I saw this discussion and now I am trying the solution present in the
> > current SNAPSHOT. However I have one comment / question:
> >
> > What if my Entity has a relationship to another Entity?
> >
> > Like this:
> >
> > public class User extends BaseAuditEntity {
> >
> > @Column
> > private String name;
> >
> > @Column
> > @ManyToOne
> > @JoinColumn(name="group_id")
> > private Group group;
> >
> > This means my userDTO may come with a GroupDTO and how do I map that
> > relationship? Or to explain by code please fill in the question marks
> below
> > ;) or if you feel my implementation is weird then I would gladly accept
> > comments on that too. But the way I see it I need to @Inject the
> > GroupMapper, use the EntityManager to find the Group then call
> > groupMapper.toEntity and then I think to myself that the API is worse now
> > because before I could call groupMapper.toEntity with only a dto
> argument.
> > At that point you had to use the entitymanager anyways to find "yourself"
> > and that feels clean compared to find your entities you form
> relationships
> > with.
> >
> > @Override
> > protected User toEntity(final User user, final UserDTO userDTO) {
> > MapperUtil.toAuditEntity(user, userDTO);
> > user.setName(userDTO.getName());
> > user.setEmail(userDTO.getEmail());
> > user.setLocale(userDTO.getLocale());
> > user.setGroup(*?*);
> > return user;
> > }
> >
> > Cheers / Karl
> >
> >
> > On 17 May 2014 16:40, Romain Manni-Bucau  wrote:
> >
> > > Yep, missed it.
> > >
> > > Works for me. Maybe the name should be closer to other methods,
> > > mapKey? But whatever you choose as name this solution works :).
> > >
> > >
> > > Romain Manni-Bucau
> > > Twitter: @rmannibucau
> > > Blog: http://rmannibucau.wordpress.com/
> > > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > Github: https://github.com/rmannibucau
> > >
> > >
> > > 2014-05-17 15:54 GMT+02:00 Thomas Hug :
> > > > It's the PK, not the Entity ;) In SimpleQueryInOutMapperBase, it
>

Re: [data] dto and isNew

[Karl Kildén]

Not sure I get myself ;)

Lets walk through how I see it:

1. User "foo" is created and is assigned to the preexisting group "Admin".

It goes like this in the flow: user = new UserDTO() ->
*user*.setGroupDTO(selectedGroup)
-> save

Some logic must make sure that we don't get EntityExistsException trying to
save that group.


2. Many sessions later user "foo" is edited. Flow: *user*.setGroupDTO(newGroup)
-> save

The variable *user *is a random object that happens to be the latest
version of that user that also has a new group set.

So  *PK, user.getGroup()*
*should lazyload the group - right? *This will result in the previous group
being loaded unless I am missing something. While it is technically correct
since the new group relationship has not been persisted yet it is actually
impossible to ever update group with this flow







On 13 June 2014 17:09, Thomas Hug  wrote:

> Hi Karl
> Sorry not sure if I get you right. Why would user.getGroup() be stale? As
> in the update case user has just been fetched by the PK, user.getGroup()
> should lazyload the group - right?
>
>
> On Fri, Jun 13, 2014 at 2:51 PM, Karl Kildén 
> wrote:
>
> > Hi and hrmmm,
> >
> > What if user group was changed?  groupMapper.toEntity(user.getGroup(),
> > userDto.getGroup()); This would then operate on stale data unless you
> fetch
> > and send in correct group. And managing new groups is easy for me I
> think,
> > I would call the method using groupMapper.toEntity(new Group(),
> > userDto.getGroup());
> >
> >
> > I would much prefer all three methods to be non protected. Then I could
> > create my helper something along the lines of this:
> >
> > I did not test this very well but unless I thought wrong completely it
> > would be a one time thing to implement. But using mappers from mappers
> are
> > hard because if the relationship is declared in both ways you can get
> > circular references. Anyways here's my helper I theorycrafted together:
> >
> >
> > Group g = fetch (new Group(), user.getGroup(), groupMapper);
> >
> > public  Entity fetch(Entity entity, Dto dto,
> > SimpleQueryInOutMapperBase entityMapper){
> > Object pk = entityMapper.getPrimaryKey(dto);
> > Entity foundEntity = (Entity)
> entityManager.find(entity.getClass(),
> > pk);
> >
> > if (foundEntity == null) {
> > foundEntity = entity;
> > }
> > return entityMapper.toEntity(foundEntity, dto);
> > }
> >
> >
> >
> > One could always create their own base class overriding the protected
> > methods and adding that fetch helper I guess...
> >
> > cheers
> >
> >
> >
> >
> >
> >
> >
> >
> > On 13 June 2014 12:54, Thomas Hug  wrote:
> >
> > > Hey Karl
> > >
> > > Sorry missed your mail indeed - it's probably time I subscribe to the
> > user
> > > mailing list too :-)
> > >
> > > You can still chain those mappers together, but I agree the casting and
> > > wiring is clunky. As options I see:
> > > - we add a public E toEntity(Dto dto) back which basically does the
> same
> > as
> > > mapParameter now (just hides the casting) for new entities
> > > - we make the E toEntity(Entity e, Dto dto) public as well, so it's
> quite
> > > easy to chain mapper calls for updates
> > >
> > > groupMapper.toEntity(user.getGroup(), userDto.getGroup());
> > >
> > > You will still have to have some conditionals to see which one to call,
> > > also depends on your data model (required relations, lazy or eager
> > fetch).
> > > How does that look? Better ideas?
> > >
> > >
> > >
> > > On Fri, Jun 13, 2014 at 8:42 AM, Karl Kildén 
> > > wrote:
> > >
> > > > I wrote a response to the users list but not sure it came through. It
> > > kinda
> > > > belongs in this thread so here it goes.
> > > >
> > > >
> > > > So I ran into issues with the DTO mapper api and voiced my concerns
> in
> > > irc.
> > > > I saw this discussion and now I am trying the solution present in the
> > > > current SNAPSHOT. However I have one comment / question:
> > > >
> > > > What if my Entity has a relationship to another Entity?
> > > >
> > > > Like this:
> > > >
> > > > public class User extends BaseAuditEntity {
> > > >
> > > > @Column
> > > >

Re: [VOTE] Release of Apache DeltaSpike 1.0.0

[Karl Kildén]

Hi,

Thomas do you think our recent discussions [1] about the mapper api for the
data module will break the API? It seems it will not imo. Possibly add a
new method or change visibility but nothing contract breaking right?

In that case I am +1 because all my apps run fine with snapshot

[1]
http://markmail.org/message/lsk4kvaxfmtnfbrx#query:+page:1+mid:owolpyxfk66bprpy+state:results


On 14 June 2014 18:01, Gerhard Petracek  wrote:

> +1
>
> regards,
> gerhard
>
>
>
> 2014-06-14 18:00 GMT+02:00 Gerhard Petracek :
>
> > Hi,
> >
> > I was running the needed tasks to get the 8th release of Apache
> DeltaSpike
> > out.
> > The artifacts are deployed to Nexus [1] (and [2]).
> >
> > The tag is available at [3] and will get pushed to the ASF repository
> once
> > the vote passed.
> >
> > Please take a look at the 1.0.0 artifacts and vote!
> >
> > Please note:
> > This vote is "majority approval" with a minimum of three +1 votes (see
> > [4]).
> >
> > 
> > [ ] +1 for community members who have reviewed the bits
> > [ ] +0
> > [ ] -1 for fatal flaws that should cause these bits not to be released,
> > and why..
> > 
> >
> > Thanks,
> > Gerhard
> >
> > [1]
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1008/
> > [2]
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1008/org/apache/deltaspike/deltaspike-project/1.0.0/deltaspike-project-1.0.0-source-release.zip
> > [3]
> https://github.com/os890/deltaspike-vote/tree/deltaspike-project-1.0.0
> > [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
> >
>

Re: [data] dto and isNew

[Karl Kildén]

Hi,

On could argue that the real problem is that the algorithm that decides if
it should be a save or persist. It uses some portable way of deciding this
that requires the entity to be managed.
That algorithm could be improved in each project.


@Override
@RequiresTransaction
public E save(E entity)
{
if (context.isNew(entity))
{
entityManager().persist(entity);
return entity;
}
return entityManager().merge(entity);
}



I would say that overriding this method would solve EntityExistsException
 in a cleaner way. For this project I have no natural keys only generated
long so it would be a cheap and easy way to fix it... This is fully
sufficient for me:


@Override
@RequiresTransaction
public E save(E entity)
{
BaseEntity e = (BaseEntity) entity;
if (e.getId == 0)
{
entityManager().persist(entity);
return entity;
}
return entityManager().merge(entity);
}




If not overridden then what happens if the group has changed in my example,
you are supposed to use entityManager and find it?

Maybe the API should provide something like the utility method I proposed
then... I will explain it a little better. All you need to do is inject the
groupMapper or whatever mapper you need. To get the group if it changed you
simply call fetch with a new Group instance, the DTO with the new
information and the groupMapper. Why send in new group instance? Well one
could also send in Group.class and use a reflection to create a new group
if needed. But new Group() vs Group.class I actually prefer the first
because it avoids reflection. Because the new Group() argument also allows
for getClass() the entityManager has all the info required except the id
but that is no problem since we also send in the mapper with the handy
#getPrimaryKey
method.

Group g = fetch (new Group(), user.getGroup(), groupMapper);

public  Entity fetch(Entity entity, Dto dto,
SimpleQueryInOutMapperBase entityMapper){
Object pk = entityMapper.getPrimaryKey(dto);
Entity foundEntity = (Entity) entityManager.find(entity.getClass(),
pk);

if (foundEntity == null) {
foundEntity = entity;
}
return entityMapper.toEntity(foundEntity, dto);
}


I have not tested this method at all, but something like it would work well
together with the default strategy for determine save or merge... But my
main wish now is to override the save logic actually.











On 16 June 2014 09:48, Thomas Hug  wrote:

> Thanks Karl for the clarification!
> If you assign a new group, I'd first make sure you have this one persisted
> as well (or we do too much in the mapper IMO). Then save the userDto with
> something like
>
> User toEntity(User user, UserDto dto) {
> ...
> user.setGroup(groupMapper.toEntity(dto.getGroup()); // or check before
> if ID changed
> }
>
> I guess that would even work if the group is not persisted if you adapt
> cascading.
>
> Makes sense?
>
> On Fri, Jun 13, 2014 at 5:56 PM, Karl Kildén 
> wrote:
>
> > Not sure I get myself ;)
> >
> > Lets walk through how I see it:
> >
> > 1. User "foo" is created and is assigned to the preexisting group
> "Admin".
> >
> > It goes like this in the flow: user = new UserDTO() ->
> > *user*.setGroupDTO(selectedGroup)
> > -> save
> >
> > Some logic must make sure that we don't get EntityExistsException trying
> to
> > save that group.
> >
> >
> > 2. Many sessions later user "foo" is edited. Flow:
> > *user*.setGroupDTO(newGroup)
> > -> save
> >
> > The variable *user *is a random object that happens to be the latest
> > version of that user that also has a new group set.
> >
> > So  *PK, user.getGroup()*
> > *should lazyload the group - right? *This will result in the previous
> group
> > being loaded unless I am missing something. While it is technically
> correct
> > since the new group relationship has not been persisted yet it is
> actually
> > impossible to ever update group with this flow
> >
> >
> >
> >
> >
> >
> >
> > On 13 June 2014 17:09, Thomas Hug  wrote:
> >
> > > Hi Karl
> > > Sorry not sure if I get you right. Why would user.getGroup() be stale?
> As
> > > in the update case user has just been fetched by the PK,
> user.getGroup()
> > > should lazyload the group - right?
> > >
> > >
> > > On Fri, Jun 13, 2014 at 2:51 PM, Karl Kildén 
> > > wrote:
> > >
> > > > Hi and hrmmm,
> > > >
> > > > What if user group was changed?
>  groupMapper.toEnt

Re: [data] dto and isNew

[Karl Kildén]

Hrmm maybe I mixed things up now.

If you have a relationship to another pre existing entity can it be
detached when you save? All I am really looking for is the groupId to be
updated but maybe JPA can't determine this in a good way. And updating the
entity itself is solved by including it as an argument to the mapper, all
though I am a wondering if that solution is optimal.

Romain and Thomas, your comments on the best way to handle relationships in
the Mapper? If the entity has not changed then you can just use
user.getGroup() but as I described previously this is wrong when the group
has changed.


On 16 June 2014 10:34, Romain Manni-Bucau  wrote:

> Cause mapping can be done through several transactions (think jaxrs) so it
> would be wrong. PersistenceUtil has some good things to gey id or null if
> new but IIRC some impl are broken.
> Le 16 juin 2014 09:31, "Thomas Andraschko"  a
> écrit :
>
> > Why don't we use entityManager#contains instead of checking the ID?
> >
> >
> > 2014-06-16 10:22 GMT+02:00 Karl Kildén :
> >
> > > Hi,
> > >
> > > On could argue that the real problem is that the algorithm that decides
> > if
> > > it should be a save or persist. It uses some portable way of deciding
> > this
> > > that requires the entity to be managed.
> > > That algorithm could be improved in each project.
> > >
> > >
> > > @Override
> > > @RequiresTransaction
> > > public E save(E entity)
> > > {
> > > if (context.isNew(entity))
> > > {
> > > entityManager().persist(entity);
> > > return entity;
> > > }
> > > return entityManager().merge(entity);
> > > }
> > >
> > >
> > >
> > > I would say that overriding this method would solve
> EntityExistsException
> > >  in a cleaner way. For this project I have no natural keys only
> generated
> > > long so it would be a cheap and easy way to fix it... This is fully
> > > sufficient for me:
> > >
> > >
> > > @Override
> > > @RequiresTransaction
> > > public E save(E entity)
> > > {
> > > BaseEntity e = (BaseEntity) entity;
> > > if (e.getId == 0)
> > > {
> > > entityManager().persist(entity);
> > > return entity;
> > > }
> > > return entityManager().merge(entity);
> > > }
> > >
> > >
> > >
> > >
> > > If not overridden then what happens if the group has changed in my
> > example,
> > > you are supposed to use entityManager and find it?
> > >
> > > Maybe the API should provide something like the utility method I
> proposed
> > > then... I will explain it a little better. All you need to do is inject
> > the
> > > groupMapper or whatever mapper you need. To get the group if it changed
> > you
> > > simply call fetch with a new Group instance, the DTO with the new
> > > information and the groupMapper. Why send in new group instance? Well
> one
> > > could also send in Group.class and use a reflection to create a new
> group
> > > if needed. But new Group() vs Group.class I actually prefer the first
> > > because it avoids reflection. Because the new Group() argument also
> > allows
> > > for getClass() the entityManager has all the info required except the
> id
> > > but that is no problem since we also send in the mapper with the handy
> > > #getPrimaryKey
> > > method.
> > >
> > > Group g = fetch (new Group(), user.getGroup(), groupMapper);
> > >
> > > public  Entity fetch(Entity entity, Dto dto,
> > > SimpleQueryInOutMapperBase entityMapper){
> > > Object pk = entityMapper.getPrimaryKey(dto);
> > > Entity foundEntity = (Entity)
> > entityManager.find(entity.getClass(),
> > > pk);
> > >
> > > if (foundEntity == null) {
> > > foundEntity = entity;
> > > }
> > > return entityMapper.toEntity(foundEntity, dto);
> > > }
> > >
> > >
> > > I have not tested this method at all, but something like it would work
> > well
> > > together with the default strategy for determine save or merge... But
> my
> > > main wish now is to override the save logic actually.
> > >
> > >
> > >
> > >
> > >
&

Re: [data] dto and isNew

[Karl Kildén]

But then I need to use the entityManager in the mapper or am I missing
something?


On 16 June 2014 11:17, Romain Manni-Bucau  wrote:

> Yes you need to merge it but the responsability is yours (user) IMO.
> Le 16 juin 2014 09:56, "Karl Kildén"  a écrit :
>
> > Hrmm maybe I mixed things up now.
> >
> > If you have a relationship to another pre existing entity can it be
> > detached when you save? All I am really looking for is the groupId to be
> > updated but maybe JPA can't determine this in a good way. And updating
> the
> > entity itself is solved by including it as an argument to the mapper, all
> > though I am a wondering if that solution is optimal.
> >
> > Romain and Thomas, your comments on the best way to handle relationships
> in
> > the Mapper? If the entity has not changed then you can just use
> > user.getGroup() but as I described previously this is wrong when the
> group
> > has changed.
> >
> >
> > On 16 June 2014 10:34, Romain Manni-Bucau  wrote:
> >
> > > Cause mapping can be done through several transactions (think jaxrs) so
> > it
> > > would be wrong. PersistenceUtil has some good things to gey id or null
> if
> > > new but IIRC some impl are broken.
> > > Le 16 juin 2014 09:31, "Thomas Andraschko" <
> andraschko.tho...@gmail.com>
> > a
> > > écrit :
> > >
> > > > Why don't we use entityManager#contains instead of checking the ID?
> > > >
> > > >
> > > > 2014-06-16 10:22 GMT+02:00 Karl Kildén :
> > > >
> > > > > Hi,
> > > > >
> > > > > On could argue that the real problem is that the algorithm that
> > decides
> > > > if
> > > > > it should be a save or persist. It uses some portable way of
> deciding
> > > > this
> > > > > that requires the entity to be managed.
> > > > > That algorithm could be improved in each project.
> > > > >
> > > > >
> > > > > @Override
> > > > > @RequiresTransaction
> > > > > public E save(E entity)
> > > > > {
> > > > > if (context.isNew(entity))
> > > > > {
> > > > > entityManager().persist(entity);
> > > > > return entity;
> > > > > }
> > > > > return entityManager().merge(entity);
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > > I would say that overriding this method would solve
> > > EntityExistsException
> > > > >  in a cleaner way. For this project I have no natural keys only
> > > generated
> > > > > long so it would be a cheap and easy way to fix it... This is fully
> > > > > sufficient for me:
> > > > >
> > > > >
> > > > > @Override
> > > > > @RequiresTransaction
> > > > > public E save(E entity)
> > > > > {
> > > > > BaseEntity e = (BaseEntity) entity;
> > > > > if (e.getId == 0)
> > > > > {
> > > > > entityManager().persist(entity);
> > > > > return entity;
> > > > > }
> > > > > return entityManager().merge(entity);
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > If not overridden then what happens if the group has changed in my
> > > > example,
> > > > > you are supposed to use entityManager and find it?
> > > > >
> > > > > Maybe the API should provide something like the utility method I
> > > proposed
> > > > > then... I will explain it a little better. All you need to do is
> > inject
> > > > the
> > > > > groupMapper or whatever mapper you need. To get the group if it
> > changed
> > > > you
> > > > > simply call fetch with a new Group instance, the DTO with the new
> > > > > information and the groupMapper. Why send in new group instance?
> Well
> > > one
> > > > > could also send in Group.class and use a reflection to create a new
> > > group
> > > > > if needed

Re: [Data] Scope of repositories

[Karl Kildén]

Feels like it should default to @ApplicationScoped? I see no reason why not
at least


On 18 June 2014 13:12, Thomas Andraschko 
wrote:

> or: @Repository(scope = ApplicationScoped.class)
>
>
> 2014-06-18 12:25 GMT+02:00 Thomas Andraschko  >:
>
> > Hi Thomas,
> >
> > my problem is that when i inject it in a ViewScoped bean, it tries to
> > serialize it but it isn't serializable.
> > Could we make it configurable? Maybe we could declerate the scope on the
> > repo:
> >
> > @Repository
> > @ApplicationScoped
> > public abstract class MyRepository extends
> > AbstractEntityRepository
> >
> > Regards,
> > Thomas
> >
> >
> > 2014-06-18 12:20 GMT+02:00 Thomas Hug :
> >
> > Hi Thomas
> >> We made some efforts to get rid of scope-related parts in the impl, but
> I
> >> don't think there's anything speakin' against a @NormalScoped repo -
> >> PartialBeans do support that.
> >> Cheers,
> >> Thomas
> >>
> >>
> >> On Wed, Jun 18, 2014 at 11:37 AM, Thomas Andraschko <
> >> andraschko.tho...@gmail.com> wrote:
> >>
> >> > Hi,
> >> >
> >> > AFAICS repositories are non-scoped, right?
> >> > Isn't it possible to make them appscoped?
> >> >
> >> > Regards,
> >> > Thomas
> >> >
> >>
> >
> >
>

Re: [data] dto and isNew

[Karl Kildén]

So isNew is broken for openjpa and one should live with it? This will
basically make deltaspike data not usable because you kinda need merge to
work properly...


On 17 June 2014 19:11, Thomas Hug  wrote:

> Actually the simple mapper is doing that since the last update, just to
> find the entity based on the PK so you receive an attached entity (also
> valid for chained mappers, when injected)
>
> BTW, if you need something different in save, you can still define your own
> reusable repository methods:
> http://deltaspike.apache.org/data.html#extensions
> (just don't name it save ;-)
>
>
>
> On Tue, Jun 17, 2014 at 4:41 PM, Romain Manni-Bucau  >
> wrote:
>
> > Yes, but that s not an issue since you can get it injected
> >
> > Le lundi 16 juin 2014, Karl Kildén  a écrit :
> > > But then I need to use the entityManager in the mapper or am I missing
> > > something?
> > >
> > >
> > > On 16 June 2014 11:17, Romain Manni-Bucau 
> wrote:
> > >
> > >> Yes you need to merge it but the responsability is yours (user) IMO.
> > >> Le 16 juin 2014 09:56, "Karl Kildén"  a écrit
> :
> > >>
> > >> > Hrmm maybe I mixed things up now.
> > >> >
> > >> > If you have a relationship to another pre existing entity can it be
> > >> > detached when you save? All I am really looking for is the groupId
> to
> > be
> > >> > updated but maybe JPA can't determine this in a good way. And
> updating
> > >> the
> > >> > entity itself is solved by including it as an argument to the
> mapper,
> > all
> > >> > though I am a wondering if that solution is optimal.
> > >> >
> > >> > Romain and Thomas, your comments on the best way to handle
> > relationships
> > >> in
> > >> > the Mapper? If the entity has not changed then you can just use
> > >> > user.getGroup() but as I described previously this is wrong when the
> > >> group
> > >> > has changed.
> > >> >
> > >> >
> > >> > On 16 June 2014 10:34, Romain Manni-Bucau 
> > wrote:
> > >> >
> > >> > > Cause mapping can be done through several transactions (think
> jaxrs)
> > so
> > >> > it
> > >> > > would be wrong. PersistenceUtil has some good things to gey id or
> > null
> > >> if
> > >> > > new but IIRC some impl are broken.
> > >> > > Le 16 juin 2014 09:31, "Thomas Andraschko" <
> > >> andraschko.tho...@gmail.com>
> > >> > a
> > >> > > écrit :
> > >> > >
> > >> > > > Why don't we use entityManager#contains instead of checking the
> > ID?
> > >> > > >
> > >> > > >
> > >> > > > 2014-06-16 10:22 GMT+02:00 Karl Kildén :
> > >> > > >
> > >> > > > > Hi,
> > >> > > > >
> > >> > > > > On could argue that the real problem is that the algorithm
> that
> > >> > decides
> > >> > > > if
> > >> > > > > it should be a save or persist. It uses some portable way of
> > >> deciding
> > >> > > > this
> > >> > > > > that requires the entity to be managed.
> > >> > > > > That algorithm could be improved in each project.
> > >> > > > >
> > >> > > > >
> > >> > > > > @Override
> > >> > > > > @RequiresTransaction
> > >> > > > > public E save(E entity)
> > >> > > > > {
> > >> > > > > if (context.isNew(entity))
> > >> > > > > {
> > >> > > > > entityManager().persist(entity);
> > >> > > > > return entity;
> > >> > > > > }
> > >> > > > > return entityManager().merge(entity);
> > >> > > > > }
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > I would say that overriding this method would solve
> > >> > > EntityExistsException
> > >> > > > >  in a cleaner way. For this project I have no natura

Re: [data] dto and isNew

[Karl Kildén]

Yes please! :-)


On 18 August 2014 20:22, Romain Manni-Bucau  wrote:

> well we have to make it working with openjpa by default. We should
> also introduce an interface the entity can implement to say if it is
> new or not (testing business id typically)
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
> 2014-08-18 18:08 GMT+02:00 Karl Kildén :
> > So isNew is broken for openjpa and one should live with it? This will
> > basically make deltaspike data not usable because you kinda need merge to
> > work properly...
> >
> >
> > On 17 June 2014 19:11, Thomas Hug  wrote:
> >
> >> Actually the simple mapper is doing that since the last update, just to
> >> find the entity based on the PK so you receive an attached entity (also
> >> valid for chained mappers, when injected)
> >>
> >> BTW, if you need something different in save, you can still define your
> own
> >> reusable repository methods:
> >> http://deltaspike.apache.org/data.html#extensions
> >> (just don't name it save ;-)
> >>
> >>
> >>
> >> On Tue, Jun 17, 2014 at 4:41 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> >> >
> >> wrote:
> >>
> >> > Yes, but that s not an issue since you can get it injected
> >> >
> >> > Le lundi 16 juin 2014, Karl Kildén  a écrit :
> >> > > But then I need to use the entityManager in the mapper or am I
> missing
> >> > > something?
> >> > >
> >> > >
> >> > > On 16 June 2014 11:17, Romain Manni-Bucau 
> >> wrote:
> >> > >
> >> > >> Yes you need to merge it but the responsability is yours (user)
> IMO.
> >> > >> Le 16 juin 2014 09:56, "Karl Kildén"  a
> écrit
> >> :
> >> > >>
> >> > >> > Hrmm maybe I mixed things up now.
> >> > >> >
> >> > >> > If you have a relationship to another pre existing entity can it
> be
> >> > >> > detached when you save? All I am really looking for is the
> groupId
> >> to
> >> > be
> >> > >> > updated but maybe JPA can't determine this in a good way. And
> >> updating
> >> > >> the
> >> > >> > entity itself is solved by including it as an argument to the
> >> mapper,
> >> > all
> >> > >> > though I am a wondering if that solution is optimal.
> >> > >> >
> >> > >> > Romain and Thomas, your comments on the best way to handle
> >> > relationships
> >> > >> in
> >> > >> > the Mapper? If the entity has not changed then you can just use
> >> > >> > user.getGroup() but as I described previously this is wrong when
> the
> >> > >> group
> >> > >> > has changed.
> >> > >> >
> >> > >> >
> >> > >> > On 16 June 2014 10:34, Romain Manni-Bucau  >
> >> > wrote:
> >> > >> >
> >> > >> > > Cause mapping can be done through several transactions (think
> >> jaxrs)
> >> > so
> >> > >> > it
> >> > >> > > would be wrong. PersistenceUtil has some good things to gey id
> or
> >> > null
> >> > >> if
> >> > >> > > new but IIRC some impl are broken.
> >> > >> > > Le 16 juin 2014 09:31, "Thomas Andraschko" <
> >> > >> andraschko.tho...@gmail.com>
> >> > >> > a
> >> > >> > > écrit :
> >> > >> > >
> >> > >> > > > Why don't we use entityManager#contains instead of checking
> the
> >> > ID?
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > 2014-06-16 10:22 GMT+02:00 Karl Kildén <
> karl.kil...@gmail.com>:
> >> > >> > > >
> >> > >> > > > > Hi,
> >> > >> > > > >
> >> > >> > > > > On could argue that the real problem is that the algorithm
> >> that
> >> > >> > decides
> >> > >> > > &g

Re: Release Notes pages

[Karl Kildén]

What a great page! I did not know about Double-Submit prevention feature
and I was actually investigating how to solve it just now :-)


On 7 September 2014 17:06, John D. Ament  wrote:

> Hi all
>
> I was looking at other apache projects and noted that many of them include
> dedicated pages for each release, with some summary information about what
> went in.  In DeltaSpike we're currently putting a short blurb, I was
> wondering if it makes sense to include something similar, and perhaps even
> merge with the generated release notes that make it into the SCM.
>
> Here's a prototype page: [1].
>
>
> http://deltaspike.staging.apache.org/documentation/deltaspike_1.0.2.html
>

Re: General purpose start scopes interceptor

[Karl Kildén]

Hrrmm I have not used the scheduler, but it looks like you don't really
start scopes in the docs?
For test-control it feels pretty natural the way it is now imo. No idea
about the Servlet Listener, what module / feature is that?


On 10 September 2014 10:10, Gerhard Petracek 
wrote:

> #1
> the test-module supports execution without scope-handling already and for
> the scheduler module you added it yourself.
> -> i'm not sure about your issue here...
>
> #2
> if you suggest a cdi-interceptor, then i don't agree at all -> -1 because
> it leads to an extra config step (at least for weld-users) and imo there is
> no real benefit which justifies it.
> even encapsulating the logic in helper/util classes won't improve a lot for
> the existing use-cases, because the common parts aren't that huge.
>
> e.g.
> in case of the schedule module you start scopes per scheduler-job.
> in case of the test-module you can start scopes per test-method or a whole
> test-class (more exotic, but sometimes needed e.g. to fill read-only caches
> just once per test-class).
>
> however, if you have an approach which keeps the flexibility without
> introducing an additional config-step (per default), i would be happy to
> see a prototype (based on [1]).
>
> regards,
> gerhard
>
> [1]
>
> http://deltaspike.apache.org/suggested-git-workflows.html#discussion-workflow-optional
>
>
>
> 2014-09-10 2:42 GMT+02:00 John D. Ament :
>
> > Hi all,
> >
> > I was looking through our code base and I noticed one interesting theme -
> > currently we have several different ways to annotate methods to cause
> > scopes to start - namely scheduler and TestControl; as well as a sevlet
> > listener (my fault).  i was wondering if it makes more sense to add a
> > capability to CdiCtrl to start a scope, via annotation, and remove
> > (deprecate) from the other modules?  I was thinking it would also help in
> > case you want to use these features without starting scopes.
> >
> > WDYT?
> >
> > John
> >
>

[suggestion] Test-Control - better support for boot(Properties p)

[Karl Kildén]

Hello,

Test-Control will bootstrap the CdiContainer for me using the #boot()
constructor. However I want it to use #boot(Properties p)

This seems logical since CdiContainer contract has that boot method. My
suggestion is:

public interface PropertiesProvider {

Properties properties();
}

@TestControl(propertiesProvider=PropertiesProviderImpl.class)


Class providerClazz =
this.testControl.propertiesProvider();
if (providerClazz != null) {
  Properties properties = providerClazz.newInstance().properties();
}


All user have to do is implement that interface PropertiesProvider  and
assign it to the test.

This would save me a lot of trouble...

cheers

Re: [suggestion] Test-Control - better support for boot(Properties p)

[Karl Kildén]

All those suggestions use properties so I am not sure what to say ;)

On 20 September 2014 16:07, Gerhard Petracek 
wrote:

> hi karl,
>
> it sounds better than DELTASPIKE-577, however, please provide the
> use-case/s which can't be done with [1].
> (the other implementations we support right now don't support such
> properties anyway).
>
> regards,
> gerhard
>
> [1] http://tomee.apache.org/alternate-descriptors.html
>
>
>
> 2014-09-20 15:28 GMT+02:00 Karl Kildén :
>
> > Hello,
> >
> > Test-Control will bootstrap the CdiContainer for me using the #boot()
> > constructor. However I want it to use #boot(Properties p)
> >
> > This seems logical since CdiContainer contract has that boot method. My
> > suggestion is:
> >
> > public interface PropertiesProvider {
> >
> > Properties properties();
> > }
> >
> > @TestControl(propertiesProvider=PropertiesProviderImpl.class)
> >
> >
> > Class providerClazz =
> > this.testControl.propertiesProvider();
> > if (providerClazz != null) {
> >   Properties properties = providerClazz.newInstance().properties();
> > }
> >
> >
> > All user have to do is implement that interface PropertiesProvider  and
> > assign it to the test.
> >
> > This would save me a lot of trouble...
> >
> > cheers
> >
>

Re: [suggestion] Test-Control - better support for boot(Properties p)

[Karl Kildén]

FYI Gerhard said on the list that the boot(Properties p) in CdiContainer
was a mistake and supporting it in test-control is thus wrong.

I disagree and will branch test-control over n out

On 20 September 2014 16:15, Karl Kildén  wrote:

> All those suggestions use properties so I am not sure what to say ;)
>
> On 20 September 2014 16:07, Gerhard Petracek 
> wrote:
>
>> hi karl,
>>
>> it sounds better than DELTASPIKE-577, however, please provide the
>> use-case/s which can't be done with [1].
>> (the other implementations we support right now don't support such
>> properties anyway).
>>
>> regards,
>> gerhard
>>
>> [1] http://tomee.apache.org/alternate-descriptors.html
>>
>>
>>
>> 2014-09-20 15:28 GMT+02:00 Karl Kildén :
>>
>> > Hello,
>> >
>> > Test-Control will bootstrap the CdiContainer for me using the #boot()
>> > constructor. However I want it to use #boot(Properties p)
>> >
>> > This seems logical since CdiContainer contract has that boot method. My
>> > suggestion is:
>> >
>> > public interface PropertiesProvider {
>> >
>> > Properties properties();
>> > }
>> >
>> > @TestControl(propertiesProvider=PropertiesProviderImpl.class)
>> >
>> >
>> > Class providerClazz =
>> > this.testControl.propertiesProvider();
>> > if (providerClazz != null) {
>> >   Properties properties = providerClazz.newInstance().properties();
>> > }
>> >
>> >
>> > All user have to do is implement that interface PropertiesProvider  and
>> > assign it to the test.
>> >
>> > This would save me a lot of trouble...
>> >
>> > cheers
>> >
>>
>
>

Re: [suggestion] Test-Control - better support for boot(Properties p)

[Karl Kildén]

The contract resides in Deltaspike: CdiContainer. Offering the
implementations a way to receive properties is a general thing. It is
countless times in countless apis - you know  "main (args)" I assume... Any
api that boots something should take args (imo). That some of the
underlying apis does not want properties is not the same is "not portable".
Since that extra boot(Properties p) does not break those who do not care
for properties.

Sounds almost like someone suggested removing boot() and only having
boot(Properties p)

Anyways I am done discussing this and I am fine with using my fork.

I agree that not using test-control is a good idea and I will migrate away
from it.

On 20 September 2014 16:30, Gerhard Petracek 
wrote:

> it's just not portable since only tomee supports it.
> tomee provides something very similar to our test-control, but specific to
> features provided by tomee.
> imo it doesn't make sense to add something only for one container (to the
> api) which is supported by the test-module of that container already.
>
> regards,
> gerhard
>
>
>
> 2014-09-20 16:24 GMT+02:00 Karl Kildén :
>
> > FYI Gerhard said on the list that the boot(Properties p) in CdiContainer
> > was a mistake and supporting it in test-control is thus wrong.
> >
> > I disagree and will branch test-control over n out
> >
> > On 20 September 2014 16:15, Karl Kildén  wrote:
> >
> > > All those suggestions use properties so I am not sure what to say ;)
> > >
> > > On 20 September 2014 16:07, Gerhard Petracek <
> gerhard.petra...@gmail.com
> > >
> > > wrote:
> > >
> > >> hi karl,
> > >>
> > >> it sounds better than DELTASPIKE-577, however, please provide the
> > >> use-case/s which can't be done with [1].
> > >> (the other implementations we support right now don't support such
> > >> properties anyway).
> > >>
> > >> regards,
> > >> gerhard
> > >>
> > >> [1] http://tomee.apache.org/alternate-descriptors.html
> > >>
> > >>
> > >>
> > >> 2014-09-20 15:28 GMT+02:00 Karl Kildén :
> > >>
> > >> > Hello,
> > >> >
> > >> > Test-Control will bootstrap the CdiContainer for me using the
> #boot()
> > >> > constructor. However I want it to use #boot(Properties p)
> > >> >
> > >> > This seems logical since CdiContainer contract has that boot method.
> > My
> > >> > suggestion is:
> > >> >
> > >> > public interface PropertiesProvider {
> > >> >
> > >> > Properties properties();
> > >> > }
> > >> >
> > >> > @TestControl(propertiesProvider=PropertiesProviderImpl.class)
> > >> >
> > >> >
> > >> > Class providerClazz =
> > >> > this.testControl.propertiesProvider();
> > >> > if (providerClazz != null) {
> > >> >   Properties properties = providerClazz.newInstance().properties();
> > >> > }
> > >> >
> > >> >
> > >> > All user have to do is implement that interface PropertiesProvider
> > and
> > >> > assign it to the test.
> > >> >
> > >> > This would save me a lot of trouble...
> > >> >
> > >> > cheers
> > >> >
> > >>
> > >
> > >
> >
>

Re: [suggestion] Test-Control - better support for boot(Properties p)

[Karl Kildén]

If it was TomEEConfig.java rather than Properties I would understand your
objection. However I think boot(Properties) is nice design regardless of 0
or 5 end usages. Deltaspike is built with modules and CdiContainer is just
supposed to be an interface for someone who wan'ts to build an
implementation.

To offer boot(Properties) is hardly outrageous. Any Interface that is
supposed to be a generic boot interface should offer some way to send in
args. I can't really think of a better way than boot(Properties).

I think it's fundamentally wrong to think only in means of what the
majority of the implementations of today use. Reasonable api design in
deltaspike could drive the development in cdi containers forward. When I
googled for other embedded EJBContainers I found evidence supporting
properties there too.

Are you sure someone adding a module for glassfish / wildfly users would
not like that boot(properties)? This was in my first search hit looking at
other containers: [1]

/ Create the container instance, passing it the properties map:
EJBContainer container =
javax.ejb.embeddable.EJBContainer.createEJBContainer(*properties*);


For Java EE users EJB and CDI containers blend together anyways.


[1] https://netbeans.org/kb/docs/javaee/javaee-entapp-junit.html

On 20 September 2014 19:00, Gerhard Petracek 
wrote:

> yes and no - the initial situation for "main (args)" isn't the same.
> once you create the same initial situation as a thought experiment, it is
> an example against your statement.
>
> the following is a >thought experiment<
> to get a comparable case we would need to assume that all jvms
> support proprietary config-files >instead< of parameters (for the
> main-method).
> furthermore, there is just one which supports both (proprietary
> config-files as well as parameters).
> -> you wouldn't use the method which is just provided by one of them, >if<
> you like to provide a >portable< app-starter.
>
> translate it to our discussion:
> CdiContainer#boot(Map) does not work the same way for all containers,
> because all containers (we support) except openejb ignore whatever you pass
> in.
> -> CdiContainer#boot(Map) is controversial, but that doesn't mean that
> other parts of deltaspike should start to ignore portability as well.
>
> we could move ContainerAwareTestContext to the spi which would allow to
> customize different areas.
> then you can decide on your own if you would like to use an implementation
> which isn't portable.
>
> regards,
> gerhard
>
>
>
> 2014-09-20 16:47 GMT+02:00 Karl Kildén :
>
> > The contract resides in Deltaspike: CdiContainer. Offering the
> > implementations a way to receive properties is a general thing. It is
> > countless times in countless apis - you know  "main (args)" I assume...
> Any
> > api that boots something should take args (imo). That some of the
> > underlying apis does not want properties is not the same is "not
> portable".
> > Since that extra boot(Properties p) does not break those who do not care
> > for properties.
> >
> > Sounds almost like someone suggested removing boot() and only having
> > boot(Properties p)
> >
> > Anyways I am done discussing this and I am fine with using my fork.
> >
> > I agree that not using test-control is a good idea and I will migrate
> away
> > from it.
> >
> > On 20 September 2014 16:30, Gerhard Petracek  >
> > wrote:
> >
> > > it's just not portable since only tomee supports it.
> > > tomee provides something very similar to our test-control, but specific
> > to
> > > features provided by tomee.
> > > imo it doesn't make sense to add something only for one container (to
> the
> > > api) which is supported by the test-module of that container already.
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2014-09-20 16:24 GMT+02:00 Karl Kildén :
> > >
> > > > FYI Gerhard said on the list that the boot(Properties p) in
> > CdiContainer
> > > > was a mistake and supporting it in test-control is thus wrong.
> > > >
> > > > I disagree and will branch test-control over n out
> > > >
> > > > On 20 September 2014 16:15, Karl Kildén 
> wrote:
> > > >
> > > > > All those suggestions use properties so I am not sure what to say
> ;)
> > > > >
> > > > > On 20 September 2014 16:07, Gerhard Petracek <
> > > gerhard.petra...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> >

Re: [suggestion] Test-Control - better support for boot(Properties p)

[Karl Kildén]

Also, sorry that I started a new thread not mentioning Deltaspike-557[1] my
suggestion there is worse but the discussion was interesting. I tried some
of the proposed workaround and they were not good for me. i forgot I opened
that jira for some reason... I ended up working around it by not testing a
certain thing but now I must have it.

In there I noticed that Romain agrees at least: "well it is portable but
values are not."

Anyways I probably should have left the subject already as I said I would
and I will do so now. I already replaced Test-Control and it didn't even
take long since the api is so nice and concise. Anyway thanks I had a good
run with it ;)

cheers

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



On 20 September 2014 19:26, Karl Kildén  wrote:

> If it was TomEEConfig.java rather than Properties I would understand your
> objection. However I think boot(Properties) is nice design regardless of 0
> or 5 end usages. Deltaspike is built with modules and CdiContainer is just
> supposed to be an interface for someone who wan'ts to build an
> implementation.
>
> To offer boot(Properties) is hardly outrageous. Any Interface that is
> supposed to be a generic boot interface should offer some way to send in
> args. I can't really think of a better way than boot(Properties).
>
> I think it's fundamentally wrong to think only in means of what the
> majority of the implementations of today use. Reasonable api design in
> deltaspike could drive the development in cdi containers forward. When I
> googled for other embedded EJBContainers I found evidence supporting
> properties there too.
>
> Are you sure someone adding a module for glassfish / wildfly users would
> not like that boot(properties)? This was in my first search hit looking at
> other containers: [1]
>
> / Create the container instance, passing it the properties map:
> EJBContainer container = 
> javax.ejb.embeddable.EJBContainer.createEJBContainer(*properties*);
>
>
> For Java EE users EJB and CDI containers blend together anyways.
>
>
> [1] https://netbeans.org/kb/docs/javaee/javaee-entapp-junit.html
>
> On 20 September 2014 19:00, Gerhard Petracek 
> wrote:
>
>> yes and no - the initial situation for "main (args)" isn't the same.
>> once you create the same initial situation as a thought experiment, it is
>> an example against your statement.
>>
>> the following is a >thought experiment<
>> to get a comparable case we would need to assume that all jvms
>> support proprietary config-files >instead< of parameters (for the
>> main-method).
>> furthermore, there is just one which supports both (proprietary
>> config-files as well as parameters).
>> -> you wouldn't use the method which is just provided by one of them, >if<
>> you like to provide a >portable< app-starter.
>>
>> translate it to our discussion:
>> CdiContainer#boot(Map) does not work the same way for all containers,
>> because all containers (we support) except openejb ignore whatever you
>> pass
>> in.
>> -> CdiContainer#boot(Map) is controversial, but that doesn't mean that
>> other parts of deltaspike should start to ignore portability as well.
>>
>> we could move ContainerAwareTestContext to the spi which would allow to
>> customize different areas.
>> then you can decide on your own if you would like to use an implementation
>> which isn't portable.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2014-09-20 16:47 GMT+02:00 Karl Kildén :
>>
>> > The contract resides in Deltaspike: CdiContainer. Offering the
>> > implementations a way to receive properties is a general thing. It is
>> > countless times in countless apis - you know  "main (args)" I assume...
>> Any
>> > api that boots something should take args (imo). That some of the
>> > underlying apis does not want properties is not the same is "not
>> portable".
>> > Since that extra boot(Properties p) does not break those who do not care
>> > for properties.
>> >
>> > Sounds almost like someone suggested removing boot() and only having
>> > boot(Properties p)
>> >
>> > Anyways I am done discussing this and I am fine with using my fork.
>> >
>> > I agree that not using test-control is a good idea and I will migrate
>> away
>> > from it.
>> >
>> > On 20 September 2014 16:30, Gerhard Petracek <
>> gerhard.petra...@gmail.com>
>> > wrote:
>> >
>> > > it's just not portable since only tomee supports it.
&g

Re: JPA doc related to EM Producer

[Karl Kildén]

Can you try this?

@PersistenceContext(unitName = APP_NAME)
private EntityManager entityManager;

@Produces
@RequestScoped
protected EntityManager createEntityManager() {
return this.entityManager;
}

On 3 October 2014 08:02, hwaastad  wrote:

> Hi,
> maybe a little late on this but I've been testing differet scenarios using
> tomee and deltaspike and using JTA these are the ones I found out working:
>
> @Produces
> @ApplicationScoped
> public EntityManagerFactory createEntityManagerFactory() {
> System.out.println("Producing EMF..");
> return Persistence.createEntityManagerFactory("ValidationPU");
> }
>
> @Produces
> public EntityManager createEntityManager(EntityManagerFactory
> entityManagerFactory) {
> System.out.println("Producing entitymanager.");
> return entityManagerFactory.createEntityManager();
> }
>
> with a little help from @romain i realized that my em's were resource_local
> using the producer shown in the DS docs.
>
> br hw
>
>
>
> --
> View this message in context:
> http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/JPA-doc-related-to-EM-Producer-tp4658999p4659077.html
> Sent from the Apache DeltaSpike Incubator Discussions mailing list archive
> at Nabble.com.
>

Re: ContainerManagedTransactionStrategy

[Karl Kildén]

I use TomEE with Eclipselink and have no issues. I do not recognize nor use
the eclipselink properties you have in persistence.xml. Otherwise we have
very similar configuration.



On 5 October 2014 16:58, hwaastad  wrote:

> Hi TH,
> and thanks for answering.
>
> I'm running JTA datasource and running repository within an EJB
> transaction.
>
> However, what I found out is that I need the entoitymanagerconfig with
> resolver or else this error occurs.
>
> I've made a simple test project
> (https://github.com/hwaastad/TomeeDsValidation.git)
>
> So if you remove the
> @EntityManagerConfig(entityManagerResolver =
> CrmEntityManagerResolver.class,flushMode = FlushModeType.COMMIT)
>
> Then this error will occure.
> Any idea why?
>
>
> br hw
>
>
>
> --
> View this message in context:
> http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/ContainerManagedTransactionStrategy-tp4659084p4659102.html
> Sent from the Apache DeltaSpike Incubator Discussions mailing list archive
> at Nabble.com.
>

Re: Deltaspike, Solder integration question.

[Karl Kildén]

Hello,

You can also use: http://showcase.omnifaces.org/cdi/Param



On 7 January 2015 at 10:47, Gerhard Petracek 
wrote:

> hi damien,
>
> we dropped it, because we consider it as anti-pattern.
> if you >really< need it, you just need to create a std. cdi-producer with
> your own RequestParam annotation as qualifier (or you can use jsf
> view-parameters instead).
>
> regards,
> gerhard
>
>
>
> 2015-01-07 1:41 GMT+01:00 Damien Clement d'Huart <
> damien.clementdhu...@gmail.com>:
>
> > Hello Deltaspike Team,
> >
> > I have got a question about the migration of Seam Solder to Deltaspike.
> >
> > In a JSF context application, to inject an url parameter we used the
> JSF's
> > @ManagedProperty annotation. In a full CDI context, this annotation is no
> > more available. However, Seam Solder introduces the ability to inject
> > request parameter into CDI beans by using the @RequestParam annotation.
> >
> > From the seam framework website, the Seam Solder is going to Deltaspike.
> > After looking into the source code of Deltaspike I notice that this
> feature
> > is not included yet. Can you tell me if it is planned to be added in a
> > future release of Deltaspike ?
> >
> > Thanks by advance.
> >
> > Regards,
> >
> > Damien
> >
>

Re: Deltaspike, Solder integration question.

[Karl Kildén]

The do it yourself:
http://stackoverflow.com/questions/13239975/depedency-inject-request-parameter-with-cdi-and-jsf2

On 7 January 2015 at 10:50, Karl Kildén  wrote:

> Hello,
>
> You can also use: http://showcase.omnifaces.org/cdi/Param
>
>
>
> On 7 January 2015 at 10:47, Gerhard Petracek 
> wrote:
>
>> hi damien,
>>
>> we dropped it, because we consider it as anti-pattern.
>> if you >really< need it, you just need to create a std. cdi-producer with
>> your own RequestParam annotation as qualifier (or you can use jsf
>> view-parameters instead).
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2015-01-07 1:41 GMT+01:00 Damien Clement d'Huart <
>> damien.clementdhu...@gmail.com>:
>>
>> > Hello Deltaspike Team,
>> >
>> > I have got a question about the migration of Seam Solder to Deltaspike.
>> >
>> > In a JSF context application, to inject an url parameter we used the
>> JSF's
>> > @ManagedProperty annotation. In a full CDI context, this annotation is
>> no
>> > more available. However, Seam Solder introduces the ability to inject
>> > request parameter into CDI beans by using the @RequestParam annotation.
>> >
>> > From the seam framework website, the Seam Solder is going to Deltaspike.
>> > After looking into the source code of Deltaspike I notice that this
>> feature
>> > is not included yet. Can you tell me if it is planned to be added in a
>> > future release of Deltaspike ?
>> >
>> > Thanks by advance.
>> >
>> > Regards,
>> >
>> > Damien
>> >
>>
>
>

Re: multithreaded repository issues

[Karl Kildén]

Hello,

I have not really noticed any perf issues with deltaspike data but then
again I did not measure it either. We use it a lot. Would be great to learn
more about it for sure.

I always assumed the method name query syntax and the other static stuff
would be cached etc so I don't really get why it would be any major penalty
all though I understand each abstraction will have some kind of impact...




On 15 March 2015 at 21:40, hwaastad  wrote:

> Hi guys,
> and thanks for answering.
>
> I'll try to get something out on github tomorrow.
>
> Br hw
>
>
>
> --
> View this message in context:
> http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/multithreaded-repository-issues-tp4660132p4660145.html
> Sent from the Apache DeltaSpike Incubator Discussions mailing list archive
> at Nabble.com.
>

Re: Issues with EntityRepository.save()

[Karl Kildén]

Marvin,

What you are suggesting is not required imo. Some strategy configuration
like suggested from Thomas would give the same benefits.

On 14 August 2015 at 13:39, Marvin Toll  wrote:

>  At the moment, I don't see a way to specify and implement save()
> in a way that is logically consistent *and* portable across JPA providers.
>  (I'll be happy to be proved false.)
> 
> Had another idea just before drifting off to sleep last night... perhaps
> this dreamy though is useful for consideration in the light of day?
>
> What if---
>
> DeltaSpike DataH[impl only] (the current DeltaSpike Data) was optimized
> for Hibernate?
>
> And a new DeltaSpike DataE[impl only] was optimized for EclipseLink?
>
>
> Said another way, an objective of trying to abstract both of these
> provides, given the large volume of custom extensions required for a still
> too immature JPA specification, and perhaps more importantly maintain an
> adequate Test Suite(s), may be more challenging/limiting than first
> imagined?
>
>
> _Marvin
>
>
> -Original Message-
> From: Thomas Hug [mailto:thomas@gmail.com]
> Sent: Friday, August 14, 2015 5:00 AM
> To: dev@deltaspike.apache.org; marvint...@gtcgroup.com
> Subject: Re: Issues with EntityRepository.save()
>
> Thanks guys for all the effort in digging into the issue here. From a
> pragmatic point of view I guess #2 would be my preferred option and then
> think about what we should do with that save thing :) Maybe a strategy
> pattern similar to what we have for TX would be the way to go.
>
> The documentation does not put a focus on it, but Data is in no way
> exclusively dependent on EntityRepository resp. AbstractEntityRepository -
> those are just convenience constructs which I have seen in almost any team
> I've worked popping up when it comes to JPA usage. With delegates [1] you
> can actually build your own convenience base repositories the way they
> should be ;) Also other features like criteria support have been moved to
> their own interfaces and can be pulled in on demand.
>
> Hope that helps,
> Thomas
>
> [1] http://deltaspike.apache.org/documentation/data.html#QueryDelegates
>
> On Thu, Aug 13, 2015 at 6:21 PM, Marvin Toll 
> wrote:
>
> > Am in strong agreement with Harald's statement:
> >
> > "I never really liked the fact that save() blurs the distinction
> > between
> > persist() and merge(), and by its very name it encourages users to
> > always call save() after changing an entity state which is usually
> > unnecessary and sometimes even wrong - so far, I've seen each and
> > every new user of DeltaSpike Data doing that."
> >
> > Having used near-native JPA2 for about 3.5 years I'm having an awkward
> > time mentally mapping the "Data" module abstraction to native JPA.
> > Said another way, I become a bit confused trying to remember how
> > native JPA2 works and how the DeltaSpike abstraction works.  However,
> > this potential criticism is made without me having adequate
> > time/experience with DeltaSpike Data... and may simply be my own
> transition discomfort.
> >
> >
> > A wild idea... would you consider a less intrusive abstraction for a
> > Data2 module?  One that does not try to mirror Spring (or the
> > Repository Pattern) but rather seeks to extend the JPA2 API?
> >
> >
> > _Marvin
> >
> > -Original Message-
> > From: Harald Wellmann [mailto:hwellmann...@gmail.com]
> > Sent: Wednesday, August 12, 2015 5:46 PM
> > To: dev@deltaspike.apache.org
> > Subject: Issues with EntityRepository.save()
> >
> > This is a quick summary of the issues around EntityRepository.save()
> > that seem to exist since 1.4.2.
> >
> > I'll create test cases and JIRA issues as time permits, but I think
> > these notes may be helpful at this stage to find out whether or not
> > incompatibilities experienced by other users have the same root cause.
> >
> > According to Javadoc [1], this is what save() does:
> >
> > "Persist (new entity) or merge the given entity. The distinction on
> > calling either method is done based on the primary key field being
> > null or not. If this results in wrong behavior for a specific case,
> > consider using the EntityManagerDelegate which offers both persist and
> merge."
> >
> > As far as I can see, the description accurately describes the
> > behaviour in 1.4.1.
> >
> > The behaviour was changed in 1.4.2 in an incompatible way without
> > adapting the documentation. Since 1.4.2, if the primary key is not
> > null, DeltaSpike also runs a database query to check whether an entity
> > with the given key exists. If so, it calls merge(), otherwise persist().
> >
> > So there are now quite a few cases when save() calls persist() where
> > it would have called merge() in 1.4.1.
> >
> > Some use cases:
> >
> > Use case 1:
> >
> > // assume separate transactions.
> > foo = save(foo);
> > remove(foo);
> > foo = save(foo);
> >
> > Result in 1.4.1:
> > foo is persistent. The second save() is a merge().
> >
> > Result in 1.4.2:
> > Exception. The sec