Re: where to place a Config-Diff algorigthm
>> Some values may have been updated, some might have been deleted and some >> other added. >> Returning a set might not be enough, isn't it? >We really only need the property names which got changed: >* new ones >* deleted ones >* the ones with different values > >So a Set is fine. The thing is that you will get the key of everything that changed which requires to invalidate the cache for all entries (lock?). Or you would need to iterate all the keys, compare again old/new and delete entries from cache, do nothing for add (? they will be lazily added during lookup maybe) and invalidate the updated values. That seems to be heavy to handle for nothing has during compare we have all information already. Le mar. 5 juin 2018 à 09:10, Mark Struberg a écrit : > Hi JL! > > Thanks for the feedback! > And yes, this will also be important for ConfigJSR (and later mp-config as > well). > > > > First it's all about config, so maybe having a method name "diff" is > > enough. No need for "diffConfig". > > Well, diff alone is imo a bit too short as it doesn't have any context > about what to diff. > Thus I'd prefer diffConfig. > > > > Some values may have been updated, some might have been deleted and some > > other added. > > Returning a set might not be enough, isn't it? > > We really only need the property names which got changed: > * new ones > * deleted ones > * the ones with different values > > So a Set is fine. > > LieGrue, > strub > > > > Am 05.06.2018 um 08:59 schrieb Jean-Louis MONTEIRO : > > > > Few thoughts ... > > > > I did not follow really deltaspike to be honest, but I do follow > MP-Config > > for instance. > > > > First it's all about config, so maybe having a method name "diff" is > > enough. No need for "diffConfig". > > > > Some values may have been updated, some might have been deleted and some > > other added. > > Returning a set might not be enough, isn't it? > > > > Jean-Louis > > > > > > > > > > > > > > Le mar. 5 juin 2018 à 08:55, Mark Struberg a > > écrit : > > > >> Hi folks! > >> > >> For the new DS-1.9 feature to 'push' config changes we need an algorithm > >> to detect whether an old and a new config differs. > >> > >> The signature would be something like: > >> > >> /** > >> * > >> * A Set of all the attributes which differ between the old and new > config > >> Map. An empty Set if there is no difference. > >> */ > >> public Set diffConfig(Map oldValues, Map >> String> newValues) > >> > >> This is intended for e.g. background threads which read from a database > >> once per second and compare the old values with the new ones. > >> If there was any difference then the set of attributes get reported back > >> to the Config (which in turn clears the caches, etc). > >> > >> > >> Now where to put this method? > >> > >> My candidate would be > >> org.apache.deltaspike.core.api.config.ConfigResolver.ConfigProvider > >> I do not want to put it into the Config interface itself because it is > not > >> a user contract thingy. > >> And I also do not want to put it into ConfigResolver becasue I'd like to > >> have the impl only available internally and not bloat the ConfigResolver > >> any further. > >> > >> Wdyt? > >> > >> LieGrue, > >> strub > >
Re: where to place a Config-Diff algorigthm
Few thoughts ... I did not follow really deltaspike to be honest, but I do follow MP-Config for instance. First it's all about config, so maybe having a method name "diff" is enough. No need for "diffConfig". Some values may have been updated, some might have been deleted and some other added. Returning a set might not be enough, isn't it? Jean-Louis Le mar. 5 juin 2018 à 08:55, Mark Struberg a écrit : > Hi folks! > > For the new DS-1.9 feature to 'push' config changes we need an algorithm > to detect whether an old and a new config differs. > > The signature would be something like: > > /** > * > * A Set of all the attributes which differ between the old and new config > Map. An empty Set if there is no difference. > */ > public Set diffConfig(Map oldValues, Map String> newValues) > > This is intended for e.g. background threads which read from a database > once per second and compare the old values with the new ones. > If there was any difference then the set of attributes get reported back > to the Config (which in turn clears the caches, etc). > > > Now where to put this method? > > My candidate would be > org.apache.deltaspike.core.api.config.ConfigResolver.ConfigProvider > I do not want to put it into the Config interface itself because it is not > a user contract thingy. > And I also do not want to put it into ConfigResolver becasue I'd like to > have the impl only available internally and not bloat the ConfigResolver > any further. > > Wdyt? > > LieGrue, > strub
Re: [ANNOUNCE] Release of Apache DeltaSpike 1.6.0
Congrats. Le mer 6 avr. 2016 01:52, Gerhard Petracek a écrit : > The Apache DeltaSpike team is pleased to announce the 24th release of > DeltaSpike. > > Apache DeltaSpike is not a CDI-container, but a portable CDI extension. > > Documentation: > http://deltaspike.apache.org/documentation/ > > Download: > http://deltaspike.apache.org/download.html > > Release Notes: > http://s.apache.org/DS_1.6.0 > > Enjoy! > > Gerhard Petracek >
Re: [VOTE] Release of Apache DeltaSpike 1.1.0
Very cool to see the project moving forward. Thank you guys. 2014-11-02 15:58 GMT+01:00 Gerhard Petracek : > @karl: see e.g. [1] > > regards, > gerhard > > [1] http://s.apache.org/iua > > > > 2014-11-02 12:31 GMT+01:00 : > > > Hello, > > > > It runs well for me. I would like to try the new stuff, any release > notes? > > > > Thanks for all the work guys! > > > > Cheers > > > > > 2 nov 2014 kl. 08:05 skrev Romain Manni-Bucau : > > > > > > +1 > > > Le 1 nov. 2014 21:49, "Gerhard Petracek" > a > > > écrit : > > > > > >> +1 > > >> > > >> regards, > > >> gerhard > > >> > > >> > > >> > > >> 2014-11-01 21:46 GMT+01:00 Gerhard Petracek : > > >> > > >>> Hi, > > >>> > > >>> I was running the needed tasks to get the 12th 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.1.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-1015 > > >>> [2] > > >> > > > https://repository.apache.org/content/repositories/orgapachedeltaspike-1015/org/apache/deltaspike/deltaspike-project/1.1.0/deltaspike-project-1.1.0-source-release.zip > > >>> [3] > > >> > https://github.com/os890/deltaspike-vote/tree/deltaspike-project-1.1.0 > > >>> [4] http://www.apache.org/foundation/voting.html#ReleaseVotes > > >> > > > -- Jean-Louis
Re: Result (was: Re: [VOTE] logo-color)
Awesome 2014-06-17 19:11 GMT+00:00 Gerhard Petracek : > thank you for voting! > > most voted for [1] -> we have a new logo! > > regards, > gerhard > > [1] http://s.apache.org/DS_LOGO_BLUE_VOTE2 > > > > 2014-06-14 20:55 GMT+02:00 Gerhard Petracek : > > > hi @ all, > > > > this second vote is about the color and therefore the final logo. > > > > i've uploaded the candidates provided by jim at [1]-[4]. > > please send a +1 for one of them. > > > > regards, > > gerhard > > > > [1] http://s.apache.org/DS_LOGO_BLUE_VOTE2 > > [2] http://s.apache.org/DS_LOGO_ORANGE_VOTE2 > > [3] http://s.apache.org/DS_LOGO_PURPLE_VOTE2 > > [4] http://s.apache.org/DS_LOGO_RED_VOTE2 > > > > > -- Jean-Louis
Re: first steps for the next release
Awesome. Thanks Gerhard 2014-06-07 8:20 GMT+02:00 Romain Manni-Bucau : > +1, thks Gerhard > Le 6 juin 2014 21:21, "Gerhard Petracek" a > écrit : > > > hi @ all, > > > > if there are no objections, i will start with the first steps for the > next > > release (v1.0.0) by the end of next week. > > > > regards, > > gerhard > > > -- Jean-Louis
Re: [DISCUSS] next release as 1.0?
> v0.x limits our growth Indeed 2014-05-24 22:45 GMT+02:00 Gerhard Petracek : > (as we know) we still have to improve the documentation, examples,... > however, one of the first impressions is the version number. > since v0.x limits our growth, i'm ok to release v1. > > regards, > gerhard > > > > 2014-05-19 13:45 GMT+02:00 Pete Muir : > > > Hi all, > > > > (Note Rafael is away on vacation atm, so I am responding partly for him > ;-) > > > > I definitely agree with getting to 1.0 asap. However also agree that we > > need to make sure we are ready. > > > > If there are issues with docs, please open issues, I know Rafael will be > > pleased to pick any that are open up when he is back from vacation. Same > > for any issues like performance. > > > > I’ve also asked for help with the docs from our docs team at Red Hat. > This > > would be more of a general edit to make them read nicely, and put them > in a > > good order for a user to follow, rather than adding new content. > However, I > > haven’t managed to secure any time before July/August. I will follow up > > with the list when I have some details. > > > > On 19 May 2014, at 12:40, Thomas Andraschko > > > wrote: > > > > > +0 > > > - no logo > > > - documentation... there are many TODOs. Also a docu for some for the > > > really core features is not available (like Deactivatable). > > > - we should check the performance of the modules. (i already openend > some > > > improvements for the JSF module) > > > > > > > > > 2014-05-19 12:39 GMT+02:00 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 < > 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 : > > > > > >> 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 > > > > >>> > > >>> > > >> > > > > > -- Jean-Louis
Re: [COMMUNITY] DeltaSpike += Rafael Benevides
Congrats. 2014-05-20 4:26 GMT-07:00 Gerhard Petracek : > The DeltaSpike PMC is proud to announce a new addition to our community. > > Please welcome Rafael Benevides as the newest DeltaSpike committer! > > @Rafael: > Please add yourself to the developers section (in > deltaspike/parent/pom.xml). > > Welcome & regards, > Gerhard > -- Jean-Louis
Re: [VOTE] Release of Apache DeltaSpike 0.7
Looks good guys. +1 JLouis 2014-05-01 23:06 GMT+02:00 Mark Struberg : > +1 > > LieGrue, > strub > > > > > > > On Thursday, 1 May 2014, 17:12, Cody Lerum wrote: > > > +1 > > > > builds and tests weld and owb fine on win 8.1 x64 7u51 > > > > > > On Wed, Apr 30, 2014 at 2:22 PM, Gerhard Petracek > > wrote: > >> Hi, > >> > >> I was running the needed tasks to get the 7th 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 0.7 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-1003/ > >> [2] > >> > > > https://repository.apache.org/content/repositories/orgapachedeltaspike-1003/org/apache/deltaspike/deltaspike-project/0.7/deltaspike-project-0.7-source-release.zip > >> [3] > https://github.com/os890/deltaspike-vote/tree/deltaspike-project-0.7 > >> [4] http://www.apache.org/foundation/voting.html#ReleaseVotes > > > -- Jean-Louis
Re: [DISCUSS] releases
Awesome. Looking forward to give that a try. JLouis 2014-04-04 9:49 GMT+02:00 Mark Struberg : > +1 > > LieGrue, > strub > > > On Thursday, 3 April 2014, 16:55, Thomas Andraschko < > andraschko.tho...@gmail.com> wrote: > > +1 > > > > > > > >2014-04-03 16:14 GMT+02:00 Rafael Benevides : > > > >> +1 > >> > >> I like continuous releases to mitigate risk and it also gives the > feeling > >> to the early adopters and users that the project is being updated > without > >> the need to check the sources ;) > >> > >> Em 03/04/14 09:49, Christian Kaltepoth escreveu: > >> > >> +1 > >>> > >>> > >>> 2014-04-03 14:44 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-04-03 14:42 GMT+02:00 Gerhard Petracek < > gerhard.petra...@gmail.com > >: > > > hi @ all, > > > > initially we agreed on releasing early and often. > > so far the average was ~3 releases per year. imo it should be more > like > > > 1-2 > > > releases every quarter (for sure depending on the resolved tickets). > > > > if there are no objections, we could do the next release in about a > > > month. > > > regards, > > gerhard > > > > >>> > >>> > >> > > > > > > -- Jean-Louis
Re: Deactivation DeltaSpikeContextExtension
Thanks Gerhard 2014-02-27 12:27 GMT+01:00 Gerhard Petracek : > done - thx for the review. > > regards, > gerhard > > http://www.irian.at > > Your JSF/JavaEE powerhouse - > JavaEE Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > > 2014-02-27 11:52 GMT+01:00 Jean-Louis MONTEIRO : > > > Hello guys, > > > > Would be great to make that extension deactivable. > > FYI, http://deltaspike.apache.org/spi.html is wrong. > > > > The key for the property should > > be org.apache.deltaspike.core.spi.activation.ClassDeactivator and not > > org.apache.deltaspike.core.api.activation.ClassDeactivator > > > > Thanks > > > > -- > > Jean-Louis > > > -- Jean-Louis
Deactivation DeltaSpikeContextExtension
Hello guys, Would be great to make that extension deactivable. FYI, http://deltaspike.apache.org/spi.html is wrong. The key for the property should be org.apache.deltaspike.core.spi.activation.ClassDeactivator and not org.apache.deltaspike.core.api.activation.ClassDeactivator Thanks -- Jean-Louis
Re: [DISCUSS] next release version? 0.6 or 1.0?
Mark, Dunno for the one week delay for 0.6 and 3 weeks delay for 1.0, but +1 to go with an intermediate step (ie. 0.6). JLouis 2014-02-17 13:14 GMT+01:00 Thomas Andraschko : > +1 Mark > > > > 2014-02-17 13:08 GMT+01:00 Ove Ranheim : > > > +1 for this :) > > > > > > 2014-02-17 10:10 GMT+01:00 Mark Struberg : > > > > > Oki, I can help a bit with ViewAccessScoped. Romain and Thomas, please > > fix > > > the Tx stuff. > > > > > > In that case I'd say we gonna ship a 0.6 and then in 3 weeks move to > 1.0. > > > > > > wdyt? > > > > > > > > > LieGrue, > > > strub > > > > > > > > > > > > > > > > > > On Monday, 17 February 2014, 10:06, Romain Manni-Bucau < > > > rmannibu...@gmail.com> wrote: > > > > > > Hi > > > > > > > > > > > >can we wait 1 or 2 weeks (no more) to see if we can sort out @Repo/@Tx > > > >stuff? Basically I'm waiting after it for months and this is blocker > > > >to be used ATM. > > > >Romain Manni-Bucau > > > >Twitter: @rmannibucau > > > >Blog: http://rmannibucau.wordpress.com/ > > > >LinkedIn: http://fr.linkedin.com/in/rmannibucau > > > >Github: https://github.com/rmannibucau > > > > > > > > > > > > > > > > > > > >2014-02-17 9:57 GMT+01:00 Mark Struberg : > > > >> back 2 the topic, please! > > > >> > > > >> I'd say we should approach 1.0 NOW. > > > >> > > > >> DeltaSpike core and a few other modules is really rock solid already > > > since a year or so. It is also used heavily in production already. > > > >> There will always be some modules which are not so perfectly mature > at > > > times. E.g. if we will add a new module. > > > >> > > > >> Thus I already did propose a methology which would fix this > > shortcoming: > > > >> We might introduce an 'ample page' which contains the status of each > > > project - stable / ready /in progress > > > >> > > > >> You know, the traffic light thingy where green means the module > (e.g. > > > deltaspike-core) is stable and the API will not change or we will at > > least > > > be backward compatible unless we do a major new version. > > > >> Orange means that the module has been tested and looks good. Whereas > > > red means that the api might change still. > > > >> > > > >> What road blockers do we have before 1.0? > > > >> Please note that there is always something one can do better - but > > this > > > should not hinder us from releasing until something is really broken. > > > >> Also the documentation is *not* a show stopper - it is perfectly > fine > > > to ship this later as our CMS is completely asynchronous. > > > >> > > > >> > > > >> So what BLOCKERS do you see before I go and press the release > button? > > > >> Like to do that on Wednesday... > > > >> > > > >> > > > >> LieGrue, > > > >> strub > > > >> > > > >> > > > >> > > > >> > > > >> On Sunday, 16 February 2014, 23:14, Ove Ranheim > > > > wrote: > > > >> > > > >> That's reasonable enough. > > > >>> > > > >>> > > > >>>On 16. feb. 2014, at 23:02, Jason Porter > > > wrote: > > > >>> > > > Probably because we've become busy with some other projects and > > > priorities :(-- > > > Sent from Mailbox for iPhone > > > > > > On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim > > > wrote: > > > > > > > The commit graph shows too few committers.. and I appreciate your > > > work! > > > > I also notice too few Redhat/JBoss Weld/Seam committers left on > the > > > project. How come? > > > > /ove > > > > On 16. feb. 2014, at 22:10, Gerhard Petracek < > > > gerhard.petra...@gmail.com> wrote: > > > >> hi ove, > > > >> > > > >> i was only talking about the commits. > > > >> > > > >> regards, > > > >> gerhard > > > >> > > > >> http://www.irian.at > > > >> > > > >> Your JSF/JavaEE powerhouse - > > > >> JavaEE Consulting, Development and > > > >> Courses in English and German > > > >> > > > >> Professional Support for Apache MyFaces > > > >> > > > >> > > > >> > > > >> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko < > > > andraschko.tho...@gmail.com>: > > > >> > > > >>> +1 Ove > > > >>> We are really late for an 0.6. I would release 0.6 this/next > > month > > > and > > > >>> after that, lets finish 1.0. > > > >>> We should fix all open issues and finish the documentation! > > > >>> > > > >>> > > > >>> > > > > > > > > > > > > > > > > > > -- Jean-Louis
Re: [Discuss] Data Module - Transactional Repositories
+1 for 2/ as well. That is right from an end user experience point of view. Also right to reuse and put in common some parts of JPA and Data module Closer to Java EE 7 @Transactional approach JLouis 2014-02-12 11:20 GMT+01:00 Thomas Hug : > Not sure where we stopped in the discussion but AFAIR we had two approaches > here: > > 1) An automatic internal tx handling if one is needed by the query, > probably similar to what the JPA module does in the > EnvironmentAwareTransactionStrategy. Could eventually be controlled by an > attribute on @Repository defaulting to active. > > 2) Integration with @Transactional of the JPA module. For this we'd also > have to look at: > - Aligning EntityManager resolution between the two modules. That could > include moving the EntityManagerResolver into the JPA module API and > eventually removing the current qualifier-based resolution. That one would > need some more thoughts to get out something consistent. > - Eventually exposing the resolved EM @TransactionScoped so the repository > can easily access it. > - Deal with PartialBeans not picking up interceptors - AFAIR this was > reported to be an issue on some Weld versions? > > +1 on 2) - makes for me much more sense from a user perspective. > -- Jean-Louis
Fwd: Fail to compile DS under windows
Hello guys, at the office, i'm using Windows to develop. When I try to clone the repo and just fire a build with "mvn clean install" It fails with the following [INFO] --- maven-surefire-plugin:2.11:test (default-test) @ deltaspike-cdictrl-weld --- [INFO] Surefire report directory: D:\cygwin\tmp\deltaspike\deltaspike\cdictrl\impl-weld\target\surefire-reports [INFO] Using configured provider org.apache.maven.surefire.junitcore.JUnitCoreProvider --- T E S T S --- Concurrency config is parallel='none', perCoreThreadCount=true, threadCount=2, useUnlimitedThreads=false Running org.apache.deltaspike.cdise.tck.ContainerCtrlTckTest 40 [main] INFO org.jboss.weld.Version - WELD-000900 1.1.10 (Final) 204 [main] INFO org.jboss.weld.Bootstrap - WELD-000101 Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously. 513 [main] WARN org.jboss.weld.interceptor.util.InterceptionTypeRegistry - Class 'javax.ejb.PostActivate' not found, interception based on it is not enabled 513 [main] WARN org.jboss.weld.interceptor.util.InterceptionTypeRegistry - Class 'javax.ejb.PrePassivate' not found, interception based on it is not enabled 702 [main] INFO org.jboss.weld.Bootstrap - WELD-000101 Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously. 804 [main] INFO org.jboss.weld.Bootstrap - WELD-000101 Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously. 882 [main] INFO org.jboss.weld.Bootstrap - WELD-000101 Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously. Tests run: 4, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 1.052 sec <<< FAILURE! Results : Tests in error: testRestartContexts(org.apache.deltaspike.cdise.tck.ContainerCtrlTckTest) testSimpleContainerBoot(org.apache.deltaspike.cdise.tck.ContainerCtrlTckTest): WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped testContainerBoot(org.apache.deltaspike.cdise.tck.ContainerCtrlTckTest): WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped Tests run: 4, Failures: 0, Errors: 3, Skipped: 0 Any thoughts? -- Jean-Louis -- Jean-Louis
Re: [DISCUSS] DeltaSpike Launch Module
+1 for DS Data. Really required to get it usable in JTA context. JLouis 2014-02-07 10:02 GMT+01:00 Romain Manni-Bucau : > not only, data module for insatnce is not that usable while not linked > to transactions so we need to see how we link modules between themself > (basically that's done for security at least) and get something > working out of the box (a basic JTA integration and another one with > @Transactional would be awesome). > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014-02-07 Jean-Louis MONTEIRO : > > +1 > > The core is very stable. > > Users are afraid by 0.5 or 0.6 in terms of quality. > > From my experience with DS, core module at least is very stable. > > > > JSF and Data work fine as well. > > Currently, we don't have a 1.0 mainly because some other modules are not > > totally merged nor stable maybe, right? > > > > Jean-Louis > > > > > > 2014-02-07 Mark Struberg : > > > >> Agree, it sounds good but I'd rather focus on (finnally!) shipping > DS-1.0 > >> for now. > >> > >> I'll give it a tough test drive in the next weeks to see what we miss > >> before the milestone. > >> > >> John, you could probably do a draft on github? > >> > >> LieGrue, > >> stru > >> > >> > >> > >> > >> On Friday, 7 February 2014, 6:15, Romain Manni-Bucau < > >> rmannibu...@gmail.com> wrote: > >> > >> Hi > >> > > >> >I see the use case but deltaspike needs so much work on existing code > >> (jsf, > >> >security, transactional, data for the one I see) that I think we > shouldnt > >> >add new things while we dont propose something working fine out of the > >> box. > >> > > >> >Wdyt? > >> > > >> >Le 7 févr. 2014 02:31, "John D. Ament" a > écrit : > >> > > >> >> Hi all > >> >> > >> >> I've been working a bit on a POC. The idea is to run a light weight > >> >> Java SE application that does some basic bootstrapping and container > >> >> services. The SE app would be configured with a basic socket listener > >> >> using Netty and delegate requests to a REST provider. The idea > behind > >> >> it is that CDI forms the low level core of the "container", where a > >> >> developer can deploy services they build on their own. The > >> >> application is meant to be an API type server (deploy REST APIs) that > >> >> runs using Netty, starts up a CDI container using DeltaSpike > Container > >> >> Control API. The launch module would handle the basic bootstrap of > >> >> the rest provider, instantiating the CDI container using > >> >> ContainerControl, and handle the necessary bootstrap for lookup up > >> >> resources and registering with the provider. This type of module > >> >> would compete with Spring Boot. > >> >> > >> >> Currently what I have leverages Weld 2.1.1 and RestEasy. The > >> >> equivalent should work for CXF. There's no hard dependency on Weld. > >> >> > >> >> I was thinking the module structure would include an api, spi, > >> >> impl-resteasy and impl-cxf. > >> >> > >> >> Some things I'd like to add: > >> >> > >> >> - Automatic bootstrap of JPA (via JPA module) > >> >> - Transaction intercepting (probably need to pull in the Geronimo > lib) > >> >> - Probably also register some providers automatically as well. > >> >> > >> >> Let me know your thoughts. > >> >> > >> >> John > >> >> > >> > > >> > > >> > > > > > > > > -- > > Jean-Louis > -- Jean-Louis
Re: [DISCUSS] DeltaSpike Launch Module
+1 The core is very stable. Users are afraid by 0.5 or 0.6 in terms of quality. >From my experience with DS, core module at least is very stable. JSF and Data work fine as well. Currently, we don't have a 1.0 mainly because some other modules are not totally merged nor stable maybe, right? Jean-Louis 2014-02-07 Mark Struberg : > Agree, it sounds good but I'd rather focus on (finnally!) shipping DS-1.0 > for now. > > I'll give it a tough test drive in the next weeks to see what we miss > before the milestone. > > John, you could probably do a draft on github? > > LieGrue, > stru > > > > > On Friday, 7 February 2014, 6:15, Romain Manni-Bucau < > rmannibu...@gmail.com> wrote: > > Hi > > > >I see the use case but deltaspike needs so much work on existing code > (jsf, > >security, transactional, data for the one I see) that I think we shouldnt > >add new things while we dont propose something working fine out of the > box. > > > >Wdyt? > > > >Le 7 févr. 2014 02:31, "John D. Ament" a écrit : > > > >> Hi all > >> > >> I've been working a bit on a POC. The idea is to run a light weight > >> Java SE application that does some basic bootstrapping and container > >> services. The SE app would be configured with a basic socket listener > >> using Netty and delegate requests to a REST provider. The idea behind > >> it is that CDI forms the low level core of the "container", where a > >> developer can deploy services they build on their own. The > >> application is meant to be an API type server (deploy REST APIs) that > >> runs using Netty, starts up a CDI container using DeltaSpike Container > >> Control API. The launch module would handle the basic bootstrap of > >> the rest provider, instantiating the CDI container using > >> ContainerControl, and handle the necessary bootstrap for lookup up > >> resources and registering with the provider. This type of module > >> would compete with Spring Boot. > >> > >> Currently what I have leverages Weld 2.1.1 and RestEasy. The > >> equivalent should work for CXF. There's no hard dependency on Weld. > >> > >> I was thinking the module structure would include an api, spi, > >> impl-resteasy and impl-cxf. > >> > >> Some things I'd like to add: > >> > >> - Automatic bootstrap of JPA (via JPA module) > >> - Transaction intercepting (probably need to pull in the Geronimo lib) > >> - Probably also register some providers automatically as well. > >> > >> Let me know your thoughts. > >> > >> John > >> > > > > > -- Jean-Louis
Re: [jira] [Commented] (DELTASPIKE-518) DS Data should support Wrapped JPA APIs
Sure, I cannot commit, so for now, my patch is running fine locally ;-) On Monday I can just refresh my local repo and recompile everything. Thanks anyway. JLouis 2014-02-07 Thomas Hug : > If it can wait 'til the weekend I can pick it up :-) > > > On Fri, Feb 7, 2014 at 9:21 AM, Jean-Louis MONTEIRO >wrote: > > > Thanks Thomas. > > Will you do that yourself, or do you want me to do the arquillian test > and > > submit a new patch? > > > > JLouis > > > > > > 2014-02-07 Thomas Hug (JIRA) : > > > > > > > > [ > > > > > > https://issues.apache.org/jira/browse/DELTASPIKE-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894286#comment-13894286 > > ] > > > > > > Thomas Hug commented on DELTASPIKE-518: > > > --- > > > > > > Looks good. I'd prefer an Arquillian test though so we can also get rid > > of > > > the OpenJPA test dependency. > > > > > > > DS Data should support Wrapped JPA APIs > > > > --- > > > > > > > > Key: DELTASPIKE-518 > > > > URL: > > > https://issues.apache.org/jira/browse/DELTASPIKE-518 > > > > Project: DeltaSpike > > > > Issue Type: Bug > > > > Components: Data-Module > > > >Affects Versions: 0.5 > > > >Reporter: Jean-Louis MONTEIRO > > > >Assignee: Romain Manni-Bucau > > > > Fix For: 0.6 > > > > > > > > Attachments: DELTASPIKE-518.patch > > > > > > > > > > > > In containers like TomEE, you usually don't get the provider > > > implementation directly but a wrapper instead. Currently, DS data fails > > > saying it does not know the provider. > > > > > > > > > > > > -- > > > This message was sent by Atlassian JIRA > > > (v6.1.5#6160) > > > > > > > > > > > -- > > Jean-Louis > > > -- Jean-Louis
Re: [jira] [Commented] (DELTASPIKE-518) DS Data should support Wrapped JPA APIs
Thanks Thomas. Will you do that yourself, or do you want me to do the arquillian test and submit a new patch? JLouis 2014-02-07 Thomas Hug (JIRA) : > > [ > https://issues.apache.org/jira/browse/DELTASPIKE-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894286#comment-13894286] > > Thomas Hug commented on DELTASPIKE-518: > --- > > Looks good. I'd prefer an Arquillian test though so we can also get rid of > the OpenJPA test dependency. > > > DS Data should support Wrapped JPA APIs > > --- > > > > Key: DELTASPIKE-518 > > URL: > https://issues.apache.org/jira/browse/DELTASPIKE-518 > > Project: DeltaSpike > > Issue Type: Bug > > Components: Data-Module > >Affects Versions: 0.5 > >Reporter: Jean-Louis MONTEIRO > >Assignee: Romain Manni-Bucau > > Fix For: 0.6 > > > > Attachments: DELTASPIKE-518.patch > > > > > > In containers like TomEE, you usually don't get the provider > implementation directly but a wrapper instead. Currently, DS data fails > saying it does not know the provider. > > > > -- > This message was sent by Atlassian JIRA > (v6.1.5#6160) > -- Jean-Louis
JSF Security regression
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
[jira] [Updated] (DELTASPIKE-518) DS Data should support Wrapped JPA APIs
[ https://issues.apache.org/jira/browse/DELTASPIKE-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis MONTEIRO updated DELTASPIKE-518: --- Attachment: DELTASPIKE-518.patch Here is a patch. > DS Data should support Wrapped JPA APIs > --- > > Key: DELTASPIKE-518 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-518 > Project: DeltaSpike > Issue Type: Bug > Components: Data-Module >Affects Versions: 0.5 > Reporter: Jean-Louis MONTEIRO > Attachments: DELTASPIKE-518.patch > > > In containers like TomEE, you usually don't get the provider implementation > directly but a wrapper instead. Currently, DS data fails saying it does not > know the provider. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [jira] [Commented] (DELTASPIKE-518) DS Data should support Wrapped JPA APIs
Hello guys, Just submitted a patch for that issue. There is also a test case now. Would be great if someone car have a look and lemme know. In my opinion, the unwrap method should be used in any case and we could simplify all the factory stuff and remove the 3 implementations I guess. Happy to give it a try if you want. Jean-Louis 2014-02-06 Romain Manni-Bucau (JIRA) : > > [ > https://issues.apache.org/jira/browse/DELTASPIKE-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893437#comment-13893437] > > Romain Manni-Bucau commented on DELTASPIKE-518: > --- > > +1 sirona is doing it as well > > > DS Data should support Wrapped JPA APIs > > --- > > > > Key: DELTASPIKE-518 > > URL: > https://issues.apache.org/jira/browse/DELTASPIKE-518 > > Project: DeltaSpike > > Issue Type: Bug > > Components: Data-Module > >Affects Versions: 0.5 > >Reporter: Jean-Louis MONTEIRO > > > > In containers like TomEE, you usually don't get the provider > implementation directly but a wrapper instead. Currently, DS data fails > saying it does not know the provider. > > > > -- > This message was sent by Atlassian JIRA > (v6.1.5#6160) > -- Jean-Louis
[jira] [Created] (DELTASPIKE-518) DS Data should support Wrapped JPA APIs
Jean-Louis MONTEIRO created DELTASPIKE-518: -- Summary: DS Data should support Wrapped JPA APIs Key: DELTASPIKE-518 URL: https://issues.apache.org/jira/browse/DELTASPIKE-518 Project: DeltaSpike Issue Type: Bug Components: Data-Module Affects Versions: 0.5 Reporter: Jean-Louis MONTEIRO In containers like TomEE, you usually don't get the provider implementation directly but a wrapper instead. Currently, DS data fails saying it does not know the provider. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Data Module
> > >>>>>>>
> > >>>>>>>> globally my answer meant "if forEntity is sometimes mandatory,
> > >>>>> sometimes
> > >>>>>>>> not this is maybe not the right place"
> > >>>>>>>>
> > >>>>>>>> i thought to add it to mapper config
> > >>>>>>>>
> > >>>>>>>> *Romain Manni-Bucau*
> > >>>>>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > >>>>>>>> *Blog: **http://rmannibucau.wordpress.com/*<
> > >>>>>>>> http://rmannibucau.wordpress.com/>
> > >>>>>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > >>>>>>>> *Github: https://github.com/rmannibucau*
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> 2013/7/10 Thomas Hug
> > >>>>>>>>
> > >>>>>>>>> Making forEntity non-optional would then be redundant for the
> > >>> regular
> > >>>>>>>> cases
> > >>>>>>>>> using the base interface, so I wouldn't. But I see that it
> should
> > >>> be
> > >>>>>>>>> clearly documented then as things might get confusing...
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau
> > >>>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> do you mean you force forEntity = Person.class?
> > >>>>>>>>>>
> > >>>>>>>>>> looks ok for me since the only constraint is to add the dto
> > >> types
> > >>>>>>>>> somewhere
> > >>>>>>>>>> :)
> > >>>>>>>>>>
> > >>>>>>>>>> *Romain Manni-Bucau*
> > >>>>>>>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > >>>>>>>>>> *Blog: **http://rmannibucau.wordpress.com/*<
> > >>>>>>>>>> http://rmannibucau.wordpress.com/>
> > >>>>>>>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > >>>>>>>>>> *Github: https://github.com/rmannibucau*
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> 2013/7/10 Thomas Hug
> > >>>>>>>>>>
> > >>>>>>>>>>> Hmm and I assumed DTOs are dead and buried :-)
> > >>>>>>>>>>>
> > >>>>>>>>>>> Packing this in the base interface feels kind of clunky to
> me -
> > >>>>>>> also
> > >>>>>>>>>>> considering that there are repositories without the need to
> > >>> extend
> > >>>>>>>> the
> > >>>>>>>>>> base
> > >>>>>>>>>>> interface. What about something like
> > >>>>>>>>>>>
> > >>>>>>>>>>> @Repository(forEntity = Person.class)
> > >>>>>>>>>>> @ResultMapper(entityMapper = MapperX.class, keyMapper =
> > >>>>>>>> MapperY.class)
> > >>>>>>>>>>> public interface PersonRepository extends
> > >>>>>>> EntityRepository > >>>>>>>>>>> DtoPk> { ... }
> > >>>>>>>>>>>
> > >>>>>>>>>>> Having the Entity on @Repository takes precedence and the
> type
> > >>>>>>>>> parameters
> > >>>>>>>>>>> are in this case just for convenience.
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Wed, Jul 10, 2013 at 2:35 PM, Romain Manni-Bucau
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> +1
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> just to complete this thread the main issue is not the
> > >>>>>>>> implementation
> > >>>>>>>>>> but
> > >>>>>>>>>>>> the exposed API:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> public interface EntityRepository Serializable>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> would become
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> public interface EntityDtoRepository > >> Serializable,
> > >>>>>>>> Dto,
> > >>>>>>>>>>>> DtoPk>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> *Romain Manni-Bucau*
> > >>>>>>>>>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > >>>>>>>>>>>> *Blog: **http://rmannibucau.wordpress.com/*<
> > >>>>>>>>>>>> http://rmannibucau.wordpress.com/>
> > >>>>>>>>>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > >>>>>>>>>>>> *Github: https://github.com/rmannibucau*
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 2013/7/10 Jean-Louis MONTEIRO
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Hello guys,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Just used DS Data module yesturday, and I was wondering if
> we
> > >>>>>>>> could
> > >>>>>>>>>>> add a
> > >>>>>>>>>>>>> feature allowing on-the-fly conversion to DTO.
> > >>>>>>>>>>>>> For example, we could use modelmapper (or similar to
> convert
> > >>>>>>> DAO
> > >>>>>>>>>> return
> > >>>>>>>>>>>>> values to DTO objects).
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Adding a mapper interface to delegate to would also allow
> > >>>>>>> people
> > >>>>>>>> to
> > >>>>>>>>>>> plug
> > >>>>>>>>>>>>> their own implementation in.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> WDYT?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> JLouis
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> 2013/7/1 Thomas Hug
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Hi John
> > >>>>>>>>>>>>>> Thnx for the message, missed that one. Looks like there's
> a
> > >>>>>>>>> default
> > >>>>>>>>>>>>> profile
> > >>>>>>>>>>>>>> needed (test-persistence.xml only part of the specific
> > >> server
> > >>>>>>>>>>>> profiles).
> > >>>>>>>>>>>>>> Will check tonight.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Mon, Jul 1, 2013 at 2:42 AM, John D. Ament <
> > >>>>>>>>>>> john.d.am...@gmail.com
> > >>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>> Hi
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Whoever brought in the data module, can you double check
> > >>>>>>> your
> > >>>>>>>>>> tests
> > >>>>>>>>>>>> and
> > >>>>>>>>>>>>>>> license headers?
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> I think it's just your tests, but it's failing during a
> rat
> > >>>>>>>>> check
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> > >>
> >
> https://builds.apache.org/job/DeltaSpike%20RAT-Check/org.apache.deltaspike.modules$deltaspike-data-module-impl/558/testReport/org.apache.deltaspike.data.impl/QueryResultTest/org_apache_deltaspike_data_impl_QueryResultTest/
> > >>>>>>>>>>>>>>> John
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> --
> > >>>>>>>>>>>>> Jean-Louis
> > >>>>>>>>>>>>>
> > >>>>>
> > >>>>>
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Jason Porter
> > >> http://en.gravatar.com/lightguardjp
> > >>
> >
>
--
Jean-Louis
Re: Data Module
Hello guys, Just used DS Data module yesturday, and I was wondering if we could add a feature allowing on-the-fly conversion to DTO. For example, we could use modelmapper (or similar to convert DAO return values to DTO objects). Adding a mapper interface to delegate to would also allow people to plug their own implementation in. WDYT? JLouis 2013/7/1 Thomas Hug > Hi John > Thnx for the message, missed that one. Looks like there's a default profile > needed (test-persistence.xml only part of the specific server profiles). > Will check tonight. > > > On Mon, Jul 1, 2013 at 2:42 AM, John D. Ament >wrote: > > > Hi > > > > Whoever brought in the data module, can you double check your tests and > > license headers? > > > > I think it's just your tests, but it's failing during a rat check > > > > > > > https://builds.apache.org/job/DeltaSpike%20RAT-Check/org.apache.deltaspike.modules$deltaspike-data-module-impl/558/testReport/org.apache.deltaspike.data.impl/QueryResultTest/org_apache_deltaspike_data_impl_QueryResultTest/ > > > > John > > > -- Jean-Louis
Re: [ANNOUNCE] Welcome Thomas Hug as new DeltaSpike committer
Congrats Thomas. JLouis 2013/6/23 Thomas Hug > Yeah, looks like my parents had absolutely no idea about usernames back > then :) > > Thanks for the welcome! Great to see that what began as small CDI exercise > gets a strong community backing now. Thanks also to everybody who helped > making CDI-Query better in the past (namely Jason and Romain from the list > here)! > > On Sat, Jun 22, 2013 at 11:15 PM, Jason Porter >wrote: > > > Glad to finally have a thug in the group. You'll come in handy :) > > — > > Sent from Mailbox for iPhone > > > > On Sat, Jun 22, 2013 at 1:30 PM, Gerhard Petracek > > wrote: > > > > > welcome! > > > regards, > > > gerhard > > > 2013/6/22 Mark Struberg > > >> The Apache DeltaSpike Team is happy to announce the addition of Thomas > > Hug > > >> as new committer. > > >> > > >> Thomas will contribute the CDI-Query module and might also help in > other > > >> areas. > > >> > > >> Welcome on board, Thomas! > > >> > > >> Sincerly, > > >> the Apache DeltaSpike PMC > > >> > > > -- Jean-Louis
Re: missing licenses from recent commits
Would be great to add it on the CI, so that's easier to detect when something is wrong, isn't it? Activating the profile on the client side works fine through. JLouis 2013/6/13 Mark Struberg > Hi! > > I did not yet look from which commit it came, but there are a few files > with missing license headers now. > > Plz run > mvn clean install -Prat > > this will run the 'release audit tool' chain which checks our license > headers and a bit more. > > txs and LieGrue, > strub > -- Jean-Louis
Re: graduation is finished
Congrats guys! Well done. Jean-Louis 2013/5/28 Mark Struberg > Hiho! > > The graduation tasks are done now. This means that our site has moved to > > http://deltaspike.apache.org/deltaspike > > We still need to move the page to the root, but we can do this ourself. > > The other thing which changed is the git repository URL. It's now > available at > > https://git-wip-us.apache.org/repos/asf/deltaspike.git > > > > LieGrue, > strub > > -- Jean-Louis
