Re: [DISCUSS] deltaspike-0.5 features
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 adr_gonza...@yahoo.fr 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 titou10.tito...@gmail.com À : 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 han...@yahoo.com.cn: 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 andraschko.tho...@gmail.com 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 rmannibu...@gmail.com Cdi query stuff would be great too Le 1 juin 2013 13:12, Mark Struberg strub...@yahoo.de a écrit : Yes should mainly be a bugfix release with only a few new features. LieGrue, strub From: John D. Ament john.d.am...@gmail.com To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de Cc: deltaspike deltaspike-...@incubator.apache.org 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 strub...@yahoo.de wrote: Hi! It's time to go for planing ds-0.5. I'd say the release should be pretty small this time. Mostly bug fixes and a few minor enhancements. And max 1 or 2 bigger bullet features. The goal is to release ds-0.5 end of this month. A few things on the list as I remember so far: * Finish graduation and apply latest changes to our Docs. * Servlet
Re: CDI Query import
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 andraschko.tho...@gmail.com 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 karl.kil...@gmail.com 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 thomas@gmail.com 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
John,
meta http-equiv=X-UA-Compatible content=IE=edge 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 john.d.am...@gmail.com
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 m.hiems...@regas.nl
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 strub...@yahoo.de
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 m.hiems...@regas.nl
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 it-media.k...@daimler.com
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 long serialVersionUID =
-3349441047782577598L;
@Override
public ClientWindowRenderMode getClientWindowRenderMode(final
FacesContext facesContext)
{
CMS diff: Documentation
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: properties -deltaspike.version0.4/deltaspike.version +deltaspike.version0.5/deltaspike.version /properties Or if you want to very bleeding edge, point to our current snapshot. properties -deltaspike.version0.5-SNAPSHOT/deltaspike.version +deltaspike.version0.6-SNAPSHOT/deltaspike.version /properties ### Configuration of DeltaSpike Core
Re: git commit: DELTASPIKE-424 taking into account EntityManagerResolver with a normal scope
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? DependentProviderContextControl 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 strub...@yahoo.de 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 DependentProviderEntityManager 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 BeanT and the instance for convenience reasons. LieGrue, strub From: Romain Manni-Bucau rmannibu...@gmail.com To: dev@deltaspike.apache.org dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de Sent: Thursday, 10 October 2013, 9:07 Subject: Re: git commit: DELTASPIKE-424 taking into account EntityManagerResolver with a normal scope If you don't destroy it you'll likely leak. And once again you are in your case where you handle the emf yourself. In other cases @Dependent should work fine. That said nothing again preventing using @Dependent so just do it If it solves the issue. Normal scopes were the important part for me. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/10/10 Mark Struberg strub...@yahoo.de 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 rmannibu...@gmail.com To: dev@deltaspike.apache.org dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de 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 strub...@yahoo.de 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? extends EntityManagerResolver 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 rmannibu...@apache.org To: comm...@deltaspike.apache.org Cc: Sent: Wednesday, 9 October 2013, 16:46 Subject: git commit: DELTASPIKE-424 taking into account EntityManagerResolver with a normal scope Updated Branches: refs/heads/master bdc9cdce6 - e8148110e DELTASPIKE-424 taking into account EntityManagerResolver with a normal scope Project: http://git-wip-us.apache.org/repos/asf/deltaspike/repo Commit: http://git-wip-us.apache.org/repos/asf/deltaspike/commit/e8148110 Tree: http://git-wip-us.apache.org/repos/asf/deltaspike/tree/e8148110 Diff:
Re: [DISCUSS] next release version? 0.6 or 1.0?
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 christ...@kaltepoth.dewrote: +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 rmannibu...@gmail.com 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 strub...@yahoo.de 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 ch0...@gmail.com To: dev@deltaspike.apache.org Cc: Mark Struberg strub...@yahoo.de 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 john.d.am...@gmail.comwrote: 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 strub...@yahoo.de 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: JSF - default ClientWindowRenderMode?
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 andraschko.tho...@gmail.comwrote: 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
/*q
On 6 February 2014 18:08, Jean-Louis MONTEIRO jeano...@gmail.com 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
I apologize for my last email, currently babysitting...
On 6 February 2014 19:30, Karl Kildén karl.kil...@gmail.com wrote:
/*q
On 6 February 2014 18:08, Jean-Louis MONTEIRO jeano...@gmail.com 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
V 1.0 getting close... Logotype?
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?
As far as I understand , it would be more symmetric from the outside / overview but technically asymmetric because the dependencies are different. But the name change feels harmless and would bring balance to the force. On 14 February 2014 09:31, Thomas Andraschko andraschko.tho...@gmail.comwrote: 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 strub...@yahoo.de: 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 strub...@yahoo.de: 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 john.d.am...@gmail.com: -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 rmannibu...@gmail.com wrote: test-control could be renamed cdi-unit or something like it IMHO Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-10 11:28 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com : i wouldn't move test-control, since it's a module based on deltaspike-core. (cdictrl isn't based on deltaspike-core.) regards, gerhard 2014-02-10 11:15 GMT+01:00 Mark Struberg strub...@yahoo.de: Well, cdictrl is released already. Thus I would rather not change it's name. test-control is not yet released. So that would be easier to change. LieGrue, strub On Sunday, 9 February 2014, 20:16, Karl Kildén karl.kil...@gmail.com wrote: Hello, I know it's been discussed before but now with a module called test-control it just feel unnecessary to be inconsistent even though cdiCtrl is not a module it's not so pretty... Cheers / Karl
Fwd: [ANNOUNCE] Release of Apache DeltaSpike 0.6
Big congratulations and thanks! -- Forwarded message -- From: Gerhard Petracek gpetra...@apache.org Date: 20 March 2014 09:38 Subject: [ANNOUNCE] Release of Apache DeltaSpike 0.6 To: dev@deltaspike.apache.org 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
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 rafaelmeire...@gmail.com 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?
CMS diff: Container Control
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
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?
+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 christ...@kaltepoth.de wrote: +1 2014-05-19 11:34 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com: +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 strub...@yahoo.de: 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?
Design help for the logo Saw that mail just now, sounds great :-) On 19 May 2014 12:37, Karl Kildén karl.kil...@gmail.com 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 christ...@kaltepoth.de wrote: +1 2014-05-19 11:34 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com: +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 strub...@yahoo.de: 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?
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 rmannibu...@gmail.com 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 andraschko.tho...@gmail.com : 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: [data] dto and isNew
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 rmannibu...@gmail.com 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 thomas@gmail.com:
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
rmannibu...@gmail.comwrote:
would work while return is E 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 thomas@gmail.com:
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
rmannibu...@gmail.comwrote:
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 thomas@gmail.com:
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.comwrote:
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
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, Dto Entity fetch(Entity entity, Dto dto,
SimpleQueryInOutMapperBaseEntity, Dto 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 thomas@gmail.com 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 karl.kil...@gmail.com
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 rmannibu...@gmail.com 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 thomas@gmail.com:
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
Re: [data] dto and isNew
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 thomas@gmail.com 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 karl.kil...@gmail.com
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, Dto Entity fetch(Entity entity, Dto dto,
SimpleQueryInOutMapperBaseEntity, Dto 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 thomas@gmail.com 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 karl.kil...@gmail.com
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
Re: [VOTE] Release of Apache DeltaSpike 1.0.0
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 gerhard.petra...@gmail.com wrote: +1 regards, gerhard 2014-06-14 18:00 GMT+02:00 Gerhard Petracek gpetra...@apache.org: 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
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, Dto Entity fetch(Entity entity, Dto dto,
SimpleQueryInOutMapperBaseEntity, Dto 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 thomas@gmail.com 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 karl.kil...@gmail.com
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 thomas@gmail.com 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 karl.kil...@gmail.com
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
Re: [data] dto and isNew
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 rmannibu...@gmail.com 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
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, Dto Entity fetch(Entity entity, Dto dto,
SimpleQueryInOutMapperBaseEntity, Dto 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 thomas@gmail.com 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 karl.kil...@gmail.com
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
Re: [data] dto and isNew
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 rmannibu...@gmail.com wrote:
Yes you need to merge it but the responsability is yours (user) IMO.
Le 16 juin 2014 09:56, Karl Kildén karl.kil...@gmail.com 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 rmannibu...@gmail.com 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
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, Dto Entity fetch(Entity entity, Dto dto,
SimpleQueryInOutMapperBaseEntity, Dto 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 thomas@gmail.com 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
Re: [data] dto and isNew
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 thomas@gmail.com 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 karl.kil...@gmail.com 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 rmannibu...@gmail.com
wrote:
Yes you need to merge it but the responsability is yours (user) IMO.
Le 16 juin 2014 09:56, Karl Kildén karl.kil...@gmail.com 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 rmannibu...@gmail.com
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
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, Dto Entity fetch(Entity entity, Dto dto,
SimpleQueryInOutMapperBaseEntity, Dto
Re: General purpose start scopes interceptor
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 gerhard.petra...@gmail.com 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 john.d.am...@gmail.com: 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)
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? extends PropertiesProvider 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)
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 karl.kil...@gmail.com:
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? extends PropertiesProvider 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)
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 karl.kil...@gmail.com 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 karl.kil...@gmail.com:
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? extends PropertiesProvider 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)
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 karl.kil...@gmail.com 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 gerhard.petra...@gmail.com 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 karl.kil...@gmail.com: 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. 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 karl.kil...@gmail.com: 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 karl.kil...@gmail.com wrote: All those suggestions use properties so I am not sure what to say ;) On 20
Re: JPA doc related to EM Producer
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 he...@waastad.org 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
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 he...@waastad.org 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.
Hello, You can also use: http://showcase.omnifaces.org/cdi/Param On 7 January 2015 at 10:47, Gerhard Petracek gerhard.petra...@gmail.com 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.
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 karl.kil...@gmail.com wrote: Hello, You can also use: http://showcase.omnifaces.org/cdi/Param On 7 January 2015 at 10:47, Gerhard Petracek gerhard.petra...@gmail.com 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
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 he...@waastad.org 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()
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 marvint...@gtcgroup.com wrote: Harald 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.) /Harald? 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 marvint...@gtcgroup.com 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 second save() is a persist(), since the key no longer exists. But then Hibernate complains it cannot persist a detached entity. Use
