Re: DISCUSS DeltaSpike-332
Weird if that s true but in such a case app will be constrained too i think Le 2 juin 2013 10:25, Mark Struberg strub...@yahoo.de a écrit : Pretty often you are not even allowed to change those libs for production. Sometimes because of legal constructs (ever looked at the Oracle license for WebLogic?) and sometimes because of company reasons. Thus I'm +1 for adding it as _optional_ feature. LieGrue, strub From: Romain Manni-Bucau rmannibu...@gmail.com To: dev@deltaspike.apache.org Sent: Sunday, 2 June 2013, 8:57 Subject: Re: DISCUSS DeltaSpike-332 As said before, if using the javaee7 lib is easy in javaee6 no need of any glue. That should be the case for bval, jpa... Le 2 juin 2013 03:26, Jason Porter lightguard...@gmail.com a écrit : FWIW I'm +1 for the BeanVal stuff and keeping it disabled by default. Just because Java EE 7 is soon to be released doesn't mean that people will migrate to it over night, as has already been said. I'm sure there are quite a few large corporations still on Java EE 5 and probably will be for a while. If the coding is minimal to bring some Java EE 7 features to Java EE 6 via DeltaSpike, I don't see a reason not to do this. — Sent from Mailbox for iPhone On Sat, Jun 1, 2013 at 1:55 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi thomas, no - we don't have @Advanced. (-1 for adding it and therefore -1 for adding parts which would need such a qualifier.) regards, gerhard 2013/6/1 Thomas Andraschko andraschko.tho...@gmail.com Jep, there will be many EE6 users out there the next 1-3 years. there are also other possible features: - injection in other BV artifacts - e.g. MessageInterpolator - method validation (if possible with 1.0 specs) AFAIK all this features will be available in BV 1.1, so it would be enough to create a BV1.0 module. Is there already something available like @Advanded in DS? I personally don't like it. Do we really save performance? Probably the best solution is to just activate injection if the module is included. Thats the same with JSF 2.2 ViewScoped. How will it be handled in DS? 2013/6/1 Mark Struberg strub...@yahoo.de As others said, in an EE-6 container you cannot just exchange the bean validation provider easily. Yes, it's already possible to use the BeanProvider to achieve this goal. But it's also nice if that would work out of the box. An important criteria is of course that it must also work when bean validation-1.1 is available which will do the injection itself. Imo it's mostly a question about what else we like to add into this module. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Saturday, 1 June 2013, 20:25 Subject: Re: DISCUSS DeltaSpike-332 hi thomas, yes, because we based everything on the jsf 1.2 api. (~nothing from the jsf2+ api was needed to provide what you get with codi.) @ ...in each validator...: projects usually don't have that many constraint-validators which need other services (and if so they might overuse it). we should encourage users to move to bv 1.1 asap. (in case of apache bval we could even provide it for bv 1.0, since we have to do it for 1.1+ anyway). regards, gerhard 2013/6/1 Thomas Andraschko andraschko.tho...@gmail.com i know what you mean gerhard :) but IMO using manual injection or getting the bean via BeanManager etc. is just a stupid workaround in each validator. It would be just user friendly to provide a small module which provides BV injection. Also the effort to create this module is very very low. Sure it's not based on the newest technology versions but there is also a JSF 1.2 module in CODI. 2013/6/1 Gerhard Petracek gerhard.petra...@gmail.com @thomas: if you are allowed to use bv 1.1, it should be possible (via default-provider + the corresponding classloading-config for the server you are using). if you are not allowed to use it, have a look at my initial comments. @hantsy: imo that's exotic anyway and you could still use BeanProvider. regards, gerhard 2013/6/1 hantsy han...@yahoo.com.cn I noticed JSF 2.2 canceled the DI in JSF components in final Specs, only support in JSF backend beans. MyFaces CODI provides @Advanced for DI in non contextual object...it is still useful for JSF 2.2...but I do not want to add this to enable
Re: DISCUSS DeltaSpike-332
Hmm, thinking of it we should consider how hard it is to dev and maintain and if it is the same code as the new version of the lib. If so thats not relevant IMO, if easy and small enough it could be added IMHO Le 2 juin 2013 13:08, John D. Ament john.d.am...@gmail.com a écrit : Definitely. When you're a consultant, you typically don't tell what 3PL's you're using (just dealt with this recently, found some GPL in our product... not fun). Adding in a 3PL that is apache licensed is typically ok. Upgrading a core app server lib without real reason for it is a pain. Right now, I think JBoss ans TomEE do it quite easily but the big boys (WebLogic WebSphere) it's still a bit of a pain. Sometimes your app is running on shared binaries, so then both apps need to be updated and you can't embed the library update for whatever class loading problem comes up. Anyways, thanks Mark Jason for support on this. I agree w/ Gerhard, we need a general strategy for introducing stuff added by later EE specs. It seems like we're inconsistent WRT this topic; e.g. JSF features were added, Servlet features are getting added, but JMS and BeanVal seemed to cause disdain in the group (not sure if it's who proposed it or the lack of use of these specs). John On Sun, Jun 2, 2013 at 5:03 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Weird if that s true but in such a case app will be constrained too i think Le 2 juin 2013 10:25, Mark Struberg strub...@yahoo.de a écrit : Pretty often you are not even allowed to change those libs for production. Sometimes because of legal constructs (ever looked at the Oracle license for WebLogic?) and sometimes because of company reasons. Thus I'm +1 for adding it as _optional_ feature. LieGrue, strub From: Romain Manni-Bucau rmannibu...@gmail.com To: dev@deltaspike.apache.org Sent: Sunday, 2 June 2013, 8:57 Subject: Re: DISCUSS DeltaSpike-332 As said before, if using the javaee7 lib is easy in javaee6 no need of any glue. That should be the case for bval, jpa... Le 2 juin 2013 03:26, Jason Porter lightguard...@gmail.com a écrit : FWIW I'm +1 for the BeanVal stuff and keeping it disabled by default. Just because Java EE 7 is soon to be released doesn't mean that people will migrate to it over night, as has already been said. I'm sure there are quite a few large corporations still on Java EE 5 and probably will be for a while. If the coding is minimal to bring some Java EE 7 features to Java EE 6 via DeltaSpike, I don't see a reason not to do this. — Sent from Mailbox for iPhone On Sat, Jun 1, 2013 at 1:55 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi thomas, no - we don't have @Advanced. (-1 for adding it and therefore -1 for adding parts which would need such a qualifier.) regards, gerhard 2013/6/1 Thomas Andraschko andraschko.tho...@gmail.com Jep, there will be many EE6 users out there the next 1-3 years. there are also other possible features: - injection in other BV artifacts - e.g. MessageInterpolator - method validation (if possible with 1.0 specs) AFAIK all this features will be available in BV 1.1, so it would be enough to create a BV1.0 module. Is there already something available like @Advanded in DS? I personally don't like it. Do we really save performance? Probably the best solution is to just activate injection if the module is included. Thats the same with JSF 2.2 ViewScoped. How will it be handled in DS? 2013/6/1 Mark Struberg strub...@yahoo.de As others said, in an EE-6 container you cannot just exchange the bean validation provider easily. Yes, it's already possible to use the BeanProvider to achieve this goal. But it's also nice if that would work out of the box. An important criteria is of course that it must also work when bean validation-1.1 is available which will do the injection itself. Imo it's mostly a question about what else we like to add into this module. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Saturday, 1 June 2013, 20:25 Subject: Re: DISCUSS DeltaSpike-332 hi thomas, yes, because we based everything on the jsf 1.2 api. (~nothing from the jsf2+ api was needed to provide what you get with codi.) @ ...in each validator...: projects usually don't have that many constraint-validators which need other services (and if so they might overuse
Re: CDI Query import
Jpa-repository sounds fine as a jpa submodule for me Le 14 juin 2013 19:56, John D. Ament john.d.am...@gmail.com a écrit : i thought it was a separate module from JPA at inception. On Fri, Jun 14, 2013 at 1:08 PM, Jason Porter lightguard...@gmail.com wrote: Sounds like we need to create a new module for this, or put it into the JPA module. Any objections for just doing the code dump into the jpa module? On Fri, Jun 14, 2013 at 6:40 AM, Thomas Hug thomas@gmail.com wrote: Valid point, thnx for the feedback! On Fri, Jun 14, 2013 at 2:30 PM, Karl Kildén karl.kil...@gmail.com wrote: Hi, Okay sounds good. I guess I interpreted it to it's worst meaning :-) I would be glad to try to test it with a plain Tomcat during the coming two weeks but sounds like it should work. I think the final docs should be formulated a little different if you want people to try it out and create bug reports with issues etc. At least myself If I was on a plain tomcat and read that I would give up if I had an issue. 2013/6/14 Thomas Hug thomas@gmail.com Hey Karl I don't see a reason this should not work even with e.g. Weld SE - but I basically wanted to say that I have neither tried it nor is it CI tested so far ;-) Something we can put on the todo list to have the Weld and OWB profile running as well. On Fri, Jun 14, 2013 at 1:58 PM, John D. Ament john.d.am...@gmail.com wrote: Karl, Maybe you could give it a try and let us know if it works? You'd need at least JPA, CDI runtime to get it working. On Fri, Jun 14, 2013 at 7:40 AM, Karl Kildén karl.kil...@gmail.com wrote: Hi Thomas! I got that from the third link (temp docs) In order to use the DeltaSpike data module, you have to run your application in a Java EE container supporting at least the Java EE 6 Web Profile. Other configurations like running it inside Tomcat or even a Java SE application are possible but currently not supported. cheers 2013/6/14 Thomas Andraschko 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 -- Jason Porter http://en.gravatar.com/lightguardjp
[jira] [Commented] (DELTASPIKE-382) mask out passwords and other credentials
[ https://issues.apache.org/jira/browse/DELTASPIKE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13684635#comment-13684635 ] Romain Manni-Bucau commented on DELTASPIKE-382: --- An alternative would be to fire an event when container is started and log with an observer at this moment, the observer would be overridable so deactivable mask out passwords and other credentials Key: DELTASPIKE-382 URL: https://issues.apache.org/jira/browse/DELTASPIKE-382 Project: DeltaSpike Issue Type: New Feature Components: Configuration Affects Versions: 0.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.5 Our configuration mechanism currently logs all the configured values. This makes it hard to use it for passwords and stuff. I suggest we introduce some specific prefix property to configure configs which contain sensitive information. For the key 'some.random.password' this could look like: deltaspike_config.mask.some.random.password=true In the log we would in this case just output the information whether and where we did find some value, but not print the details for all configs which start with all of the configured masks. I'm not yet sure though how to configure this best. Suggestions appreciated! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] beanval module name
whatever the list is IMO, the point was already mentionned: how many times did you use bv to say bean validation? You never say Java Persistence API but always jpa, for bval that's the opposite IMO. I commonly see bval or beanvalidation but not others. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/16 John D. Ament john.d.am...@gmail.com Gerhard, They may use [bv-dev] as a prefix, but the mailing list name is beanvalidation-dev. On Sun, Jun 16, 2013 at 10:11 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, please check e.g. the official eg/dev list [1]. the subject of mails starts with [bv-dev] regards, gerhard [1] http://lists.jboss.org/pipermail/beanvalidation-dev/ 2013/6/16 John D. Ament john.d.am...@gmail.com gerhard/thomas The problem I have with bv is that no one refers to BeanValidation as bv (in fact, Bean Validation is the shortened form of JavaBeans Validation). Doing a quick google search on bv shows me some STDs. Since google is typically stalking me and knows I ask lots of programming questions, it would typically return the programming references first. Doing a google search for bv bean validation shows beanvalidation.org, however there are no references to bv on that site. romain Yes, I think using bval ties us closely to the Apache impl. I think I generally prefer longer names. For example, we chose partial-bean rather than pb. If it were bean-val instead of beanval, would anyone mind that? John On Sun, Jun 16, 2013 at 9:45 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, in codi we used bv1 (like jpa1, jsf12, jsf20,...). if we don't plan to support multiple versions with separated modules, i tend to like just bv (since we use jpa and jsf for the modules of the corresponding specs). regards, gerhard 2013/6/16 Romain Manni-Bucau rmannibu...@gmail.com As a short name bval is fine but maybe too close of apache impl. So id use bean-validation. Being explicit is good when naming things Le 16 juin 2013 15:25, John D. Ament john.d.am...@gmail.com a écrit : Hi all One of the comments in the introduction of a Bean Validation module is that the name I gave it isn't descriptive/useful. I chose the name beanval since it was a shortened version of Bean Validation that could easily be read via maven. To me, it's descriptive of being related to JSR303 support. One of the other names proposed is bv. If anyone has any recommended names, or questions about the given names, could you speak up? John
Re: [DISCUSS] beanval module name
even when speaking? Then the point is who should understand the name, the EG or users. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/16 Gerhard Petracek gerhard.petra...@gmail.com we (= bv-eg) ~always used bv. it's even used in the bv-spec. document. regards, gerhard 2013/6/16 Romain Manni-Bucau rmannibu...@gmail.com whatever the list is IMO, the point was already mentionned: how many times did you use bv to say bean validation? You never say Java Persistence API but always jpa, for bval that's the opposite IMO. I commonly see bval or beanvalidation but not others. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/16 John D. Ament john.d.am...@gmail.com Gerhard, They may use [bv-dev] as a prefix, but the mailing list name is beanvalidation-dev. On Sun, Jun 16, 2013 at 10:11 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, please check e.g. the official eg/dev list [1]. the subject of mails starts with [bv-dev] regards, gerhard [1] http://lists.jboss.org/pipermail/beanvalidation-dev/ 2013/6/16 John D. Ament john.d.am...@gmail.com gerhard/thomas The problem I have with bv is that no one refers to BeanValidation as bv (in fact, Bean Validation is the shortened form of JavaBeans Validation). Doing a quick google search on bv shows me some STDs. Since google is typically stalking me and knows I ask lots of programming questions, it would typically return the programming references first. Doing a google search for bv bean validation shows beanvalidation.org, however there are no references to bv on that site. romain Yes, I think using bval ties us closely to the Apache impl. I think I generally prefer longer names. For example, we chose partial-bean rather than pb. If it were bean-val instead of beanval, would anyone mind that? John On Sun, Jun 16, 2013 at 9:45 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, in codi we used bv1 (like jpa1, jsf12, jsf20,...). if we don't plan to support multiple versions with separated modules, i tend to like just bv (since we use jpa and jsf for the modules of the corresponding specs). regards, gerhard 2013/6/16 Romain Manni-Bucau rmannibu...@gmail.com As a short name bval is fine but maybe too close of apache impl. So id use bean-validation. Being explicit is good when naming things Le 16 juin 2013 15:25, John D. Ament john.d.am...@gmail.com a écrit : Hi all One of the comments in the introduction of a Bean Validation module is that the name I gave it isn't descriptive/useful. I chose the name beanval since it was a shortened version of Bean Validation that could easily be read via maven. To me, it's descriptive of being related to JSR303 support. One of the other names proposed is bv. If anyone has any recommended names, or questions about the given names, could you speak up? John
Re: [DISCUSS] beanval module name
codi is not that used, and not sure bv is explicit enough in all languages. hibernate uses validator, other can use jsr330/jsr349. Since this module can be an in between 330 and 349 maybe using jsr330 is good but IMO has the same drawback as bv. If you don't follow specs and/or dev them you don't know what it is. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/16 Gerhard Petracek gerhard.petra...@gmail.com we never had an issue with that in codi where we use bv since 2010. regards, gerhard 2013/6/16 Romain Manni-Bucau rmannibu...@gmail.com even when speaking? Then the point is who should understand the name, the EG or users. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/16 Gerhard Petracek gerhard.petra...@gmail.com we (= bv-eg) ~always used bv. it's even used in the bv-spec. document. regards, gerhard 2013/6/16 Romain Manni-Bucau rmannibu...@gmail.com whatever the list is IMO, the point was already mentionned: how many times did you use bv to say bean validation? You never say Java Persistence API but always jpa, for bval that's the opposite IMO. I commonly see bval or beanvalidation but not others. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/16 John D. Ament john.d.am...@gmail.com Gerhard, They may use [bv-dev] as a prefix, but the mailing list name is beanvalidation-dev. On Sun, Jun 16, 2013 at 10:11 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, please check e.g. the official eg/dev list [1]. the subject of mails starts with [bv-dev] regards, gerhard [1] http://lists.jboss.org/pipermail/beanvalidation-dev/ 2013/6/16 John D. Ament john.d.am...@gmail.com gerhard/thomas The problem I have with bv is that no one refers to BeanValidation as bv (in fact, Bean Validation is the shortened form of JavaBeans Validation). Doing a quick google search on bv shows me some STDs. Since google is typically stalking me and knows I ask lots of programming questions, it would typically return the programming references first. Doing a google search for bv bean validation shows beanvalidation.org, however there are no references to bv on that site. romain Yes, I think using bval ties us closely to the Apache impl. I think I generally prefer longer names. For example, we chose partial-bean rather than pb. If it were bean-val instead of beanval, would anyone mind that? John On Sun, Jun 16, 2013 at 9:45 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, in codi we used bv1 (like jpa1, jsf12, jsf20,...). if we don't plan to support multiple versions with separated modules, i tend to like just bv (since we use jpa and jsf for the modules of the corresponding specs). regards, gerhard 2013/6/16 Romain Manni-Bucau rmannibu...@gmail.com As a short name bval is fine but maybe too close of apache impl. So id use bean-validation. Being explicit is good when naming things Le 16 juin 2013 15:25, John D. Ament john.d.am...@gmail.com a écrit : Hi all One of the comments in the introduction of a Bean Validation module is that the name I gave it isn't descriptive/useful. I chose the name beanval since it was a shortened version of Bean Validation that could easily be read via maven. To me, it's descriptive of being related to JSR303 support. One of the other names proposed is bv. If anyone has any recommended names, or questions about the given names, could you speak up? John
Re: Time to cut 0.5?
+1, data module needs review and we (with Jean-Louis) already saw an issue in its usage: it is not compatible with DTO at all. It would be great to enhance the API to support it (using ModelMapper it would be trivial to implement, the only issue will be to add an interface RepositoryEntity, EntityId, Dto, DtoId) - probably needs another discuss thread but i'll let JL open it *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/7/10 Mark Struberg strub...@yahoo.de yup, I really like to get 0.5 out of the door. We need some reviews first though. Mainly the new query and beanval modules. Sadly, I'm 180% overloaded at $$dayjob right now. Hope I can find some time on the weekend. Or did anyone else take a deep look at it already? Then I'd be happy to run the release tasks. This I would also like to document the release process so everybody is able to run it. LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Sunday, 7 July 2013, 2:20 Subject: Re: Time to cut 0.5? Yep, saw the deluge of emails come in. On Sat, Jul 6, 2013 at 6:18 PM, John D. Ament john.d.am...@gmail.com wrote: 0.5 was intended to be a small release, per [1] Note, I just moved the config module ones per your note in the top level issue. [1]: http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201306.mbox/browser On Sat, Jul 6, 2013 at 8:15 PM, Jason Porter lightguard...@gmail.com wrote: I must have been sleeping or something for 0.5, I didn't think that much work had been done. If that much work had been done, why are there only nine closed issues in 0.5 in JIRA? On Sat, Jul 6, 2013 at 6:09 PM, John D. Ament john.d.am...@gmail.com wrote: Errr, 3 new modules. On Sat, Jul 6, 2013 at 8:03 PM, John D. Ament john.d.am...@gmail.com wrote: We're a couple weeks late, but is anyone else interested in seeing 0.5 cut? Seems like we have a slew of bug fixes and two new modules in the hangar waiting to take off. -- Jason Porter http://en.gravatar.com/lightguardjp -- Jason Porter http://en.gravatar.com/lightguardjp
Re: Data Module
+1 just to complete this thread the main issue is not the implementation but the exposed API: public interface EntityRepositoryE, PK extends Serializable would become public interface EntityDtoRepositoryE, PK extends 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 jeano...@gmail.com 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 thomas@gmail.com Hi John Thnx for the message, missed that one. Looks like there's a default profile needed (test-persistence.xml only part of the specific server profiles). Will check tonight. On Mon, Jul 1, 2013 at 2:42 AM, John D. Ament john.d.am...@gmail.com wrote: Hi Whoever brought in the data module, can you double check your tests and license headers? I think it's just your tests, but it's failing during a rat check https://builds.apache.org/job/DeltaSpike%20RAT-Check/org.apache.deltaspike.modules$deltaspike-data-module-impl/558/testReport/org.apache.deltaspike.data.impl/QueryResultTest/org_apache_deltaspike_data_impl_QueryResultTest/ John -- Jean-Louis
Re: Data Module
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 thomas@gmail.com
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
rmannibu...@gmail.comwrote:
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 thomas@gmail.com
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 EntityRepositoryPersonDto,
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
rmannibu...@gmail.comwrote:
+1
just to complete this thread the main issue is not the implementation
but
the exposed API:
public interface EntityRepositoryE, PK extends Serializable
would become
public interface EntityDtoRepositoryE, PK extends 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 jeano...@gmail.com
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 thomas@gmail.com
Hi John
Thnx for the message, missed that one. Looks like there's a
default
profile
needed (test-persistence.xml only part of the specific server
profiles).
Will check tonight.
On Mon, Jul 1, 2013 at 2:42 AM, John D. Ament
john.d.am...@gmail.com
wrote:
Hi
Whoever brought in the data module, can you double check your
tests
and
license headers?
I think it's just your tests, but it's failing during a rat
check
https://builds.apache.org/job/DeltaSpike%20RAT-Check/org.apache.deltaspike.modules$deltaspike-data-module-impl/558/testReport/org.apache.deltaspike.data.impl/QueryResultTest/org_apache_deltaspike_data_impl_QueryResultTest/
John
--
Jean-Louis
Re: Data Module
Cause in REST you can push your entities to your REST endpoints then simply
convert it to DTO, that's a stateless case which work but not that general.
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/7/10 John D. Ament john.d.am...@gmail.com
Personally, I don't like this idea.
A DAO should do DAO stuff.
A DTO should do DTO stuff.
The transformation of your entities into some other POJO shouldn't be
inside your DAO.
Right now, I use google guava to do DTO work on entities going back and
forth over a REST API. Works well IMHO.
John
On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
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 thomas@gmail.com
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
rmannibu...@gmail.comwrote:
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 thomas@gmail.com
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
EntityRepositoryPersonDto,
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
rmannibu...@gmail.comwrote:
+1
just to complete this thread the main issue is not the
implementation
but
the exposed API:
public interface EntityRepositoryE, PK extends Serializable
would become
public interface EntityDtoRepositoryE, PK extends 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 jeano...@gmail.com
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 thomas@gmail.com
Hi John
Thnx for the message, missed that one. Looks like there's a
default
profile
needed (test-persistence.xml only part of the specific server
profiles).
Will check tonight.
On Mon, Jul 1, 2013 at 2:42 AM, John D. Ament
john.d.am...@gmail.com
wrote:
Hi
Whoever brought in the data module, can you double check
your
tests
and
license headers?
I think it's just your tests, but it's failing during a rat
check
https://builds.apache.org/job/DeltaSpike%20RAT-Check/org.apache.deltaspike.modules$deltaspike-data-module-impl/558/testReport/org.apache.deltaspike.data.impl/QueryResultTest/org_apache_deltaspike_data_impl_QueryResultTest/
John
--
Jean-Louis
Re: Data Module
Ps: you can make a cdi bean an ejb from cdi extension
Le 12 juil. 2013 08:12, Romain Manni-Bucau rmannibu...@gmail.com a
écrit :
Hi
Depending the case DTO are not an option.
I agree in rest app i wouldnt it but if not possible (maybe through
another Bean) it would kill this module for half of the usages i see since
i'd need to add this layer.
Le 12 juil. 2013 06:55, hantsy han...@yahoo.com.cn a écrit :
No DTO please, data module for data access, why we care about DTO.
A question about the data, the difference for EJB and none EJB
environment.
if possible in a EJB envoriment, proxy the Repository and add @Stateless
and transaction declaration to Repository automatically at runtime.
Regards
Hantsy
On 7/10/2013 23:23, Thomas Hug wrote:
I wouldn't label the feature with DTO but rather as some general result
transformation - might also be useful for e.g. native queries. Going
back
to the API suggestion, from that perspective such an annotation should
probably also work on method level, so I'd keep the forEntity out there.
On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament john.d.am...@gmail.com
wrote:
Personally, I don't like this idea.
A DAO should do DAO stuff.
A DTO should do DTO stuff.
The transformation of your entities into some other POJO shouldn't be
inside your DAO.
Right now, I use google guava to do DTO work on entities going back and
forth over a REST API. Works well IMHO.
John
On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
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 thomas@gmail.com
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
rmannibu...@gmail.comwrote:
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 thomas@gmail.com
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
EntityRepositoryPersonDto,
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
rmannibu...@gmail.comwrote:
+1
just to complete this thread the main issue is not the
implementation
but
the exposed API:
public interface EntityRepositoryE, PK extends Serializable
would become
public interface EntityDtoRepositoryE, PK extends 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 jeano...@gmail.com
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 thomas@gmail.com
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
Re: all tests green (almost)
I think so too, this is not a main feature of DS IMO Le 11 août 2013 16:43, John D. Ament john.d.am...@gmail.com a écrit : Well, it looks like Glassfish 4 is shipping with 2.0.0.SP1. Maybe we can just list this as a known limitation? On Sun, Aug 11, 2013 at 9:22 AM, Mark Struberg strub...@yahoo.de wrote: Hi folks! All our CI are now green again. The only Exception being weld-2.0.0 and 2.0.0.SP1. I first guessed it's due to the missing getBean() handling in our InjectionPoints created via BeanBuilder. But it turns our it had no impact. These 2 weld verions fail with an internal proxy failure (NPE deep inside the proxy due to wrong handling of abstract classes). It seems those errors already got fixed with weld-2.0.1 onwards (both works perfectly fine in our CI builds). Are those buggy 2.0.0 versions used in some containers? Or can we just remove them from our CI because they are known to be broken? txs and LieGrue, strub PS: like to finally do 0.5 this week...
[jira] [Created] (DELTASPIKE-404) BeanManagerProvider leaks in case of undeploy/redeploy
Romain Manni-Bucau created DELTASPIKE-404: - Summary: BeanManagerProvider leaks in case of undeploy/redeploy Key: DELTASPIKE-404 URL: https://issues.apache.org/jira/browse/DELTASPIKE-404 Project: DeltaSpike Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
ConfigSource using ThreadLocal
Hi, I have the following use case: a config is dynamic (typically the url of the server using arquillian - @ArquillianResource URL url). I need this url in a config. In prod i use apache-deltaspike.properties or a custom ConfigSource. I see an easy solution being a ThreadLocal (or a global Map) backing a TestConfigSource. The question now: do we provide a default impl answering this need? (maybe an in memory configuration == map/properties updatable through a static method) wdyt? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau*
Re: ConfigSource using ThreadLocal
It would be a contextual config so in the case of arquillian you'd set it in the beginning of your test method. The point is not if it works but if we can/should support it. typically how to configure a webservice client url when the port is random? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/9/25 Jason Porter lightguard...@gmail.com I'm not sure what good a ThreadLocal is going to give you. Unless you're using @InSequence in your tests you're not guaranteed when the tests will run and if that ThreadLocal variable will be set. Simply having Arquillian inject the URL should be fine. Also if depending on the forking parameter with JUnit it may not work anyway. On Wed, Sep 25, 2013 at 5:01 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Hi, I have the following use case: a config is dynamic (typically the url of the server using arquillian - @ArquillianResource URL url). I need this url in a config. In prod i use apache-deltaspike.properties or a custom ConfigSource. I see an easy solution being a ThreadLocal (or a global Map) backing a TestConfigSource. The question now: do we provide a default impl answering this need? (maybe an in memory configuration == map/properties updatable through a static method) wdyt? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* -- Jason Porter http://en.gravatar.com/lightguardjp
Re: ConfigSource using ThreadLocal
The point is my webservice client is part of my app and then need app config. The design cant change cause of tests. I can isolate it and mock ut through cdi but using config source is nicer Le 25 sept. 2013 20:39, John D. Ament john.d.am...@gmail.com a écrit : Yeah... the target path of the deployment isn't available at deployment creation. It's only available after. When I was doing some webservice testing, i simply instantiated using the URL param, not injection of the webservice (I honestly find webservice injection to be a bit difficult since endpoints will be different in environments). On Wed, Sep 25, 2013 at 2:35 PM, Jason Porter lightguard...@gmail.com wrote: Ah, okay. Now I see. On Wed, Sep 25, 2013 at 12:12 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Yep but the app doesnt know it and arquillian doesnt have it in packaging phase (@deployment) Le 25 sept. 2013 19:51, Jason Porter lightguard...@gmail.com a écrit : In that particular example, in the test, Arquillian knows the URL of the server, so the port should already be there, right? Maybe I'm missing something. On Wed, Sep 25, 2013 at 10:51 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: It would be a contextual config so in the case of arquillian you'd set it in the beginning of your test method. The point is not if it works but if we can/should support it. typically how to configure a webservice client url when the port is random? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/9/25 Jason Porter lightguard...@gmail.com I'm not sure what good a ThreadLocal is going to give you. Unless you're using @InSequence in your tests you're not guaranteed when the tests will run and if that ThreadLocal variable will be set. Simply having Arquillian inject the URL should be fine. Also if depending on the forking parameter with JUnit it may not work anyway. On Wed, Sep 25, 2013 at 5:01 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Hi, I have the following use case: a config is dynamic (typically the url of the server using arquillian - @ArquillianResource URL url). I need this url in a config. In prod i use apache-deltaspike.properties or a custom ConfigSource. I see an easy solution being a ThreadLocal (or a global Map) backing a TestConfigSource. The question now: do we provide a default impl answering this need? (maybe an in memory configuration == map/properties updatable through a static method) wdyt? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* -- Jason Porter http://en.gravatar.com/lightguardjp -- Jason Porter http://en.gravatar.com/lightguardjp -- Jason Porter http://en.gravatar.com/lightguardjp
Re: ConfigSource using ThreadLocal
I was looking for something more portable, in tomee my test passes as you can guess ;) But ok, you join my thought: this case shows a limitation of arquillian...that said not sure why url can be passed as @deployment parameter, it should work in the arq lifecycle imo Le 26 sept. 2013 06:58, Mark Struberg strub...@yahoo.de a écrit : I think a ThreadLocal ConfigSource is kind of an anti-pattern. Even in your case it looks like this only would work if you start the container inplace. But it will not work with remote containers. But there is nothing which prevents you from registering an own ThreadLocalTestConfigSource which you add as lib to your tomee, right? LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Wednesday, 25 September 2013, 21:49 Subject: Re: ConfigSource using ThreadLocal T he point is my webservice client is part of my app and then need app config. The design cant change cause of tests. I can isolate it and mock ut through cdi but using config source is nicer Le 25 sept. 2013 20:39, John D. Ament john.d.am...@gmail.com a écrit : Yeah... the target path of the deployment isn't available at deployment creation. It's only available after. When I was doing some webservice testing, i simply instantiated using the URL param, not injection of the webservice (I honestly find webservice injection to be a bit difficult since endpoints will be different in environments). On Wed, Sep 25, 2013 at 2:35 PM, Jason Porter lightguard...@gmail.com wrote: Ah, okay. Now I see. On Wed, Sep 25, 2013 at 12:12 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Yep but the app doesnt know it and arquillian doesnt have it in packaging phase (@deployment) Le 25 sept. 2013 19:51, Jason Porter lightguard...@gmail.com a écrit : In that particular example, in the test, Arquillian knows the URL of the server, so the port should already be there, right? Maybe I'm missing something. On Wed, Sep 25, 2013 at 10:51 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: It would be a contextual config so in the case of arquillian you'd set it in the beginning of your test method. The point is not if it works but if we can/should support it. typically how to configure a webservice client url when the port is random? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/9/25 Jason Porter lightguard...@gmail.com I'm not sure what good a ThreadLocal is going to give you. Unless you're using @InSequence in your tests you're not guaranteed when the tests will run and if that ThreadLocal variable will be set. Simply having Arquillian inject the URL should be fine. Also if depending on the forking parameter with JUnit it may not work anyway. On Wed, Sep 25, 2013 at 5:01 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Hi, I have the following use case: a config is dynamic (typically the url of the server using arquillian - @ArquillianResource URL url). I need this url in a config. In prod i use apache-deltaspike.properties or a custom ConfigSource. I see an easy solution being a ThreadLocal (or a global Map) backing a TestConfigSource. The question now: do we provide a default impl answering this need? (maybe an in memory configuration == map/properties updatable through a static method) wdyt? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* -- Jason Porter http://en.gravatar.com/lightguardjp -- Jason Porter http://en.gravatar.com/lightguardjp -- Jason Porter http://en.gravatar.com/lightguardjp
Re: ConfigSource using ThreadLocal
Yep, I'll ping him today on IRC *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/9/26 Jason Porter lightguard...@gmail.com Bring it up to Aslak. I highly doubt he's watching this list. On Wed, Sep 25, 2013 at 11:02 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: I was looking for something more portable, in tomee my test passes as you can guess ;) But ok, you join my thought: this case shows a limitation of arquillian...that said not sure why url can be passed as @deployment parameter, it should work in the arq lifecycle imo Le 26 sept. 2013 06:58, Mark Struberg strub...@yahoo.de a écrit : I think a ThreadLocal ConfigSource is kind of an anti-pattern. Even in your case it looks like this only would work if you start the container inplace. But it will not work with remote containers. But there is nothing which prevents you from registering an own ThreadLocalTestConfigSource which you add as lib to your tomee, right? LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Wednesday, 25 September 2013, 21:49 Subject: Re: ConfigSource using ThreadLocal T he point is my webservice client is part of my app and then need app config. The design cant change cause of tests. I can isolate it and mock ut through cdi but using config source is nicer Le 25 sept. 2013 20:39, John D. Ament john.d.am...@gmail.com a écrit : Yeah... the target path of the deployment isn't available at deployment creation. It's only available after. When I was doing some webservice testing, i simply instantiated using the URL param, not injection of the webservice (I honestly find webservice injection to be a bit difficult since endpoints will be different in environments). On Wed, Sep 25, 2013 at 2:35 PM, Jason Porter lightguard...@gmail.com wrote: Ah, okay. Now I see. On Wed, Sep 25, 2013 at 12:12 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Yep but the app doesnt know it and arquillian doesnt have it in packaging phase (@deployment) Le 25 sept. 2013 19:51, Jason Porter lightguard...@gmail.com a écrit : In that particular example, in the test, Arquillian knows the URL of the server, so the port should already be there, right? Maybe I'm missing something. On Wed, Sep 25, 2013 at 10:51 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: It would be a contextual config so in the case of arquillian you'd set it in the beginning of your test method. The point is not if it works but if we can/should support it. typically how to configure a webservice client url when the port is random? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/9/25 Jason Porter lightguard...@gmail.com I'm not sure what good a ThreadLocal is going to give you. Unless you're using @InSequence in your tests you're not guaranteed when the tests will run and if that ThreadLocal variable will be set. Simply having Arquillian inject the URL should be fine. Also if depending on the forking parameter with JUnit it may not work anyway. On Wed, Sep 25, 2013 at 5:01 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Hi, I have the following use case: a config is dynamic (typically the url of the server using arquillian - @ArquillianResource URL url). I need this url in a config. In prod i use apache-deltaspike.properties or a custom ConfigSource. I see an easy solution being a ThreadLocal (or a global Map) backing a TestConfigSource. The question now: do we provide a default impl answering this need? (maybe an in memory configuration == map/properties updatable through a static method) wdyt? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http
Re: Data Module
Hi
any news on it?
@ResultMapper was good to me
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/7/12 Jason Porter lightguard...@gmail.com
On Fri, Jul 12, 2013 at 12:13 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
Ps: you can make a cdi bean an ejb from cdi extension
No, the bootstrapping for each container do not communicate to my
knowledge.
Le 12 juil. 2013 08:12, Romain Manni-Bucau rmannibu...@gmail.com a
écrit :
Hi
Depending the case DTO are not an option.
I agree in rest app i wouldnt it but if not possible (maybe through
another Bean) it would kill this module for half of the usages i see
since
i'd need to add this layer.
Le 12 juil. 2013 06:55, hantsy han...@yahoo.com.cn a écrit :
No DTO please, data module for data access, why we care about DTO.
A question about the data, the difference for EJB and none EJB
environment.
if possible in a EJB envoriment, proxy the Repository and add
@Stateless
and transaction declaration to Repository automatically at runtime.
Regards
Hantsy
On 7/10/2013 23:23, Thomas Hug wrote:
I wouldn't label the feature with DTO but rather as some general
result
transformation - might also be useful for e.g. native queries. Going
back
to the API suggestion, from that perspective such an annotation
should
probably also work on method level, so I'd keep the forEntity out
there.
On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament
john.d.am...@gmail.com
wrote:
Personally, I don't like this idea.
A DAO should do DAO stuff.
A DTO should do DTO stuff.
The transformation of your entities into some other POJO shouldn't
be
inside your DAO.
Right now, I use google guava to do DTO work on entities going back
and
forth over a REST API. Works well IMHO.
John
On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
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 thomas@gmail.com
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
rmannibu...@gmail.comwrote:
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 thomas@gmail.com
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
EntityRepositoryPersonDto,
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
rmannibu...@gmail.comwrote:
+1
just to complete this thread the main issue is not the
implementation
but
the exposed API:
public interface EntityRepositoryE, PK extends Serializable
would become
public interface EntityDtoRepositoryE, PK extends
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 jeano...@gmail.com
Hello guys,
Just used DS Data module yesturday, and I was wondering if we
could
add a
feature allowing
Re: Renaming @ViewRef config property?
+1, same for @ConfigProperty btw Le 3 oct. 2013 20:49, Gerhard Petracek gerhard.petra...@gmail.com a écrit : -0.5 for now once we add more, you get the same and it would be not that expressive. that was the reason for changing it (compared to codi). regards, gerhard 2013/10/3 Thomas Andraschko andraschko.tho...@gmail.com Hi, currently @ViewRef has only one property called config. So the current usage is: @ViewRef(config = Views.Logout.class) What about renaming it to value? - @ViewRef(Views.Logout.class) Regards, Thomas
Re: Renaming @ViewRef config property?
If config is the unique mandatory attr it should be value imo Le 3 oct. 2013 22:39, Gerhard Petracek gerhard.petra...@gmail.com a écrit : hi thomas, yes - we had something in codi and we might add something like the payload in bv. regards, gerhard 2013/10/3 Thomas Andraschko andraschko.tho...@gmail.com @Gerhard: Are there any expected properties on @ViewRef in the future? 2013/10/3 Romain Manni-Bucau rmannibu...@gmail.com +1, same for @ConfigProperty btw Le 3 oct. 2013 20:49, Gerhard Petracek gerhard.petra...@gmail.com a écrit : -0.5 for now once we add more, you get the same and it would be not that expressive. that was the reason for changing it (compared to codi). regards, gerhard 2013/10/3 Thomas Andraschko andraschko.tho...@gmail.com Hi, currently @ViewRef has only one property called config. So the current usage is: @ViewRef(config = Views.Logout.class) What about renaming it to value? - @ViewRef(Views.Logout.class) Regards, Thomas
Re: Renaming @ViewRef config property?
I didnt use viewref enough to say but typically it is boring to need to write name in configproperty each time while you know what it is. Moreover for viewref, config doesnt sound really right, metadata or marker sounds as right as config depending where you are coming from. Well this doesnt hold features so i dont want to loose time in it but now you know why i like value ;) Le 3 oct. 2013 23:21, Gerhard Petracek gerhard.petra...@gmail.com a écrit : -0.5 (instead of -1), because i used value in codi back then and there is nothing wrong with it. however, that was one of the lessons learned from using it in projects and explaining it in trainings for almost three years. what we have right now just reflects the feedback. regards, gerhard 2013/10/3 Romain Manni-Bucau rmannibu...@gmail.com If config is the unique mandatory attr it should be value imo Le 3 oct. 2013 22:39, Gerhard Petracek gerhard.petra...@gmail.com a écrit : hi thomas, yes - we had something in codi and we might add something like the payload in bv. regards, gerhard 2013/10/3 Thomas Andraschko andraschko.tho...@gmail.com @Gerhard: Are there any expected properties on @ViewRef in the future? 2013/10/3 Romain Manni-Bucau rmannibu...@gmail.com +1, same for @ConfigProperty btw Le 3 oct. 2013 20:49, Gerhard Petracek gerhard.petra...@gmail.com a écrit : -0.5 for now once we add more, you get the same and it would be not that expressive. that was the reason for changing it (compared to codi). regards, gerhard 2013/10/3 Thomas Andraschko andraschko.tho...@gmail.com Hi, currently @ViewRef has only one property called config. So the current usage is: @ViewRef(config = Views.Logout.class) What about renaming it to value? - @ViewRef(Views.Logout.class) Regards, Thomas
[jira] [Commented] (DELTASPIKE-334) CDI + Blueprint integration
[
https://issues.apache.org/jira/browse/DELTASPIKE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806868#comment-13806868
]
Romain Manni-Bucau commented on DELTASPIKE-334:
---
maybe we should get the DS xml config before dealing with integration with
other framework.
IIRC we agreed to integrate it so that's maybe the first step?
CDI + Blueprint integration
---
Key: DELTASPIKE-334
URL: https://issues.apache.org/jira/browse/DELTASPIKE-334
Project: DeltaSpike
Issue Type: New Feature
Reporter: Charles Moulliard
Assignee: Charles Moulliard
Priority: Minor
Description should be enriched by authors (Jason, ...)
{code}
From:Nodet Guillaume gno...@redhat.com
Such a xml is in the META-INF/beans.xml, right ? So that you can override the
behaviour of annotations ?
I'm not sure how / where we could use it, and that does not seem really
critical to me anyway.
I think we'd better come to an understanding of the use case we'd want to
cover.
I'm thinking about:
* #1 create beans using the CDI container
* #2 inject CDI beans into blueprint beans using the blueprint xml
* #3 inject blueprint beans into CDI beans using @Inject
* #4 support CDI annotations on blueprint beans (@PostConstruct,
@PreDestroy, @Inject)
#1 is obviously needed, it could be done from the blueprint xml using a
simple tag, eventually pointing to the beans.xml config file, or inline it
(though inlining is not really worth the pain now imho)
cdi:container xmlns=…
cdi:beans url=… /
/cdi:container
#2 means being able to use one of the bean created from the CDI container and
inject it using the xml blueprint syntax, something like
bean ….
cdiroperty name=service… /
/bean
Not sure what exactly we'd need in the cdiroperty/ element, but the idea is
to use the bean setters to inject a bean created inside the CDI container
#3 means that we'd need to be able to inject a bean created by the blueprint
container using bean/ into a @Inject annotated property of a CDI bean
created by the CDI container. In blueprint, beans are referred to by name
though, so it may require a custom annotation maybe ?
#4 means mixing CDI annotations with blueprint beans. It's the most
complicated case I think, as it needs an even closer cooperation of both
containers.
This needs to be triggered either globally or an individual bean using a flag
such an xml attribute such as cdirocess=true that could be set on a bean/
element or a default attribute on the cdi:container/ element.
Cheers,
Guillaume Nodet
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
Re: [DISCUSS] next release version? 0.6 or 1.0?
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
Re: [DISCUSS] next release version? 0.6 or 1.0?
+1 for v1. If we don't go back (= we don't make unstable stable modules) it is enough IMO
Re: Data Module
+1 Works for me, thks Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/11/15 Thomas Hug thomas@gmail.com: One question is probably whether it's worth adding something like a MapperResolver instead of referring to the mapper class directly. On Fri, Nov 15, 2013 at 11:10 AM, Thomas Hug thomas@gmail.com wrote: Finally found some spare time to get back to this. You can find an API proposal at [1] and a sample repository at [2]. Suggestions? [1] https://github.com/thomashug/DeltaSpike-Mirror/tree/master/deltaspike/modules/data/api/src/main/java/org/apache/deltaspike/data/api/mapping [2] https://github.com/thomashug/DeltaSpike-Mirror/blob/master/deltaspike/modules/data/impl/src/test/java/org/apache/deltaspike/data/test/service/SimpleMappedRepository.java On Tue, Oct 1, 2013 at 5:44 PM, Thomas Hug thomas@gmail.com wrote: +1 on the feature, just been busy on a project where that would have been handy. And apologies for letting the thread quiet, will I'll try to propose something over the next two weeks based on the initial API suggestion (and get some other JIRA issues finally done...). On Tue, Oct 1, 2013 at 4:31 PM, Jean-Louis MONTEIRO jeano...@gmail.comwrote: Yep, I still think it's useful. JLouis 2013/10/1 Romain Manni-Bucau rmannibu...@gmail.com Not particularly the thread ends while the feature is useful IMO so simply asking what to do next ;) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/10/1 Jason Porter lightguard...@gmail.com Was this my action item? Sent from my iPhone On Oct 1, 2013, at 7:43, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi any news on it? @ResultMapper was good to me *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/7/12 Jason Porter lightguard...@gmail.com On Fri, Jul 12, 2013 at 12:13 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Ps: you can make a cdi bean an ejb from cdi extension No, the bootstrapping for each container do not communicate to my knowledge. Le 12 juil. 2013 08:12, Romain Manni-Bucau rmannibu...@gmail.com a écrit : Hi Depending the case DTO are not an option. I agree in rest app i wouldnt it but if not possible (maybe through another Bean) it would kill this module for half of the usages i see since i'd need to add this layer. Le 12 juil. 2013 06:55, hantsy han...@yahoo.com.cn a écrit : No DTO please, data module for data access, why we care about DTO. A question about the data, the difference for EJB and none EJB environment. if possible in a EJB envoriment, proxy the Repository and add @Stateless and transaction declaration to Repository automatically at runtime. Regards Hantsy On 7/10/2013 23:23, Thomas Hug wrote: I wouldn't label the feature with DTO but rather as some general result transformation - might also be useful for e.g. native queries. Going back to the API suggestion, from that perspective such an annotation should probably also work on method level, so I'd keep the forEntity out there. On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament john.d.am...@gmail.com wrote: Personally, I don't like this idea. A DAO should do DAO stuff. A DTO should do DTO stuff. The transformation of your entities into some other POJO shouldn't be inside your DAO. Right now, I use google guava to do DTO work on entities going back and forth over a REST API. Works well IMHO. John On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: 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 thomas@gmail.com Making forEntity non-optional would then be redundant for the regular cases using the base interface, so I
[jira] [Commented] (DELTASPIKE-453) Provide @Eager for ApplicationScoped beans
[ https://issues.apache.org/jira/browse/DELTASPIKE-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13835472#comment-13835472 ] Romain Manni-Bucau commented on DELTASPIKE-453: --- Guys, we discussed BeanProvider for @Dependent and we implemented it recently. The point is @Eager is needed very often in JSE, OSGi, and potentially web and ears. It shouldn't suppose anything about jsf or web containers. In we don't implement it we should make it clear that we target only web applications. Provide @Eager for ApplicationScoped beans -- Key: DELTASPIKE-453 URL: https://issues.apache.org/jira/browse/DELTASPIKE-453 Project: DeltaSpike Issue Type: New Feature Components: Core Reporter: Thomas Andraschko Attachments: 453.patch -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [DISCUSS] unit-test cdi-control
we have something like it in openejb and it is really nicer than arquillian for real apps and unit tests since you don't need deployment or heavy enrichments processes Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/12/2 John D. Ament john.d.am...@gmail.com: I'd personally prefer to see this as an Arquillian add on, especially since the embedded containers have such little over head. On Mon, Dec 2, 2013 at 6:32 AM, Mark Struberg strub...@yahoo.de wrote: yup +1 TestNG support would also be handy later. LieGrue, strub From: Thomas Andraschko andraschko.tho...@gmail.com To: dev@deltaspike.apache.org Sent: Monday, 2 December 2013, 11:22 Subject: Re: [DISCUSS] unit-test cdi-control +1 simple and nice approach 2013/12/2 Gerhard Petracek gerhard.petra...@gmail.com hi @ all, please have a look at [1]. it's just a first (and quick) draft based on major use-cases. however, it's working already and the api/spi is minimal - we can think about adding it to deltaspike. (it's already prepared for additional use-cases, however, for sure we can simplify/change/improve any part of it easily.) regards, gerhard [1] http://os890.blogspot.com/2013/12/add-on-cdi-tests-with-deltaspike-05.html
Re: [DISCUSS] unit-test cdi-control
well I asked cause I used it and found something to replace in junit for everything (all you speak about) Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/12/2 Mark Struberg strub...@yahoo.de: I use it ;P Nah, testNG is really cool if you have a bit of a mixture of pure unit tests with a slight touch of integration testing. groups, parallel executions, shuffled executions, etc. _really_ useful stuff! LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Monday, 2 December 2013, 19:59 Subject: Re: [DISCUSS] unit-test cdi-control Which gain supporting testng? Testng supports junit iirc Le 2 déc. 2013 18:11, Christian Kaltepoth christ...@kaltepoth.de a écrit : I really like this. So +1 for adding it. Great work Gerhard. :) And I agree with Mark that we should also support TestNG later. So the module name should indicate that it is JUnit specific. Christian 2013/12/2 Gerhard Petracek gerhard.petra...@gmail.com hi @ all, please have a look at [1]. it's just a first (and quick) draft based on major use-cases. however, it's working already and the api/spi is minimal - we can think about adding it to deltaspike. (it's already prepared for additional use-cases, however, for sure we can simplify/change/improve any part of it easily.) regards, gerhard [1] http://os890.blogspot.com/2013/12/add-on-cdi-tests-with-deltaspike-05.html -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
Re: Simple Cron Module
Oh, so something else ;). I'm +0 on this feature since IMO JavaEE 6 offers what is needed but I understand your constraint Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/12/3 Thomas Andraschko andraschko.tho...@gmail.com: My problem is that some customers just have a tomcat, without JavaEE. 2013/12/3 Romain Manni-Bucau rmannibu...@gmail.com Hi what is issing in JavaEE 6 for you (TimerService already allows a lot)? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/12/3 Nathan Dennis nathan.den...@monarchnc.org: Beyond what JEE6 Time Service offers, (and maybe I missed this somewhere in there), the ability to store, recall, pause, edit jobs would be nice using some sort of handle. I was definitely making use of these features in Seam 2. Actually, I'm still running that code in places in production just for the easy integration with Quartz scheduler. That being said, the follow up question would be is Delta Spike the right place for this type of functionality? best regards, Nathan Dennis | Software Developer 732 Greenwood Street | Albemarle, NC | 28001 Main (800) 230-7525 | Direct: 704-986-7211 | Mobile 704.984.0829 www.monarchnc.org | nathan.den...@monarchnc.org -Original Message- From: Thomas Andraschko [mailto:andraschko.tho...@gmail.com] Sent: Tuesday, December 03, 2013 7:43 AM To: dev@deltaspike.apache.org Subject: Simle Cron Module Hi, what do you think about a simple cron module like in Seam? Regards, Thomas [http://monarchnc.org/images/monarch/env.png]Please consider the environment before printing this email. WARNING: This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. Any review, dissemination, copying, printing or other use of the email by persons or entities other than the addressee is prohibited. If you have received this email in error, please contact the sender immediately and delete the material from any computer. If you are unable to determine the sender of this email, please email Monarch at supp...@monarchnc.org or contact us at toll free (800) 230-7525, and advise us of the error.
Re: Simple Cron Module
Hi what is issing in JavaEE 6 for you (TimerService already allows a lot)? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/12/3 Nathan Dennis nathan.den...@monarchnc.org: Beyond what JEE6 Time Service offers, (and maybe I missed this somewhere in there), the ability to store, recall, pause, edit jobs would be nice using some sort of handle. I was definitely making use of these features in Seam 2. Actually, I'm still running that code in places in production just for the easy integration with Quartz scheduler. That being said, the follow up question would be is Delta Spike the right place for this type of functionality? best regards, Nathan Dennis | Software Developer 732 Greenwood Street | Albemarle, NC | 28001 Main (800) 230-7525 | Direct: 704-986-7211 | Mobile 704.984.0829 www.monarchnc.org | nathan.den...@monarchnc.org -Original Message- From: Thomas Andraschko [mailto:andraschko.tho...@gmail.com] Sent: Tuesday, December 03, 2013 7:43 AM To: dev@deltaspike.apache.org Subject: Simle Cron Module Hi, what do you think about a simple cron module like in Seam? Regards, Thomas [http://monarchnc.org/images/monarch/env.png]Please consider the environment before printing this email. WARNING: This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. Any review, dissemination, copying, printing or other use of the email by persons or entities other than the addressee is prohibited. If you have received this email in error, please contact the sender immediately and delete the material from any computer. If you are unable to determine the sender of this email, please email Monarch at supp...@monarchnc.org or contact us at toll free (800) 230-7525, and advise us of the error.
[jira] [Commented] (DELTASPIKE-472) Implement portable extensions that install custom beans when not running inside a WAR file.
[ https://issues.apache.org/jira/browse/DELTASPIKE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13855122#comment-13855122 ] Romain Manni-Bucau commented on DELTASPIKE-472: --- Hi I don't get it too, we agreed to add xml config, is it this? BTW module.xml is a bad name IMO and can conflict with some containers. apache-deltaspike-xxx.xml would be better IMO (xxx=cdi or config surely). Implement portable extensions that install custom beans when not running inside a WAR file. --- Key: DELTASPIKE-472 URL: https://issues.apache.org/jira/browse/DELTASPIKE-472 Project: DeltaSpike Issue Type: Improvement Components: Core Reporter: John D. Ament Assignee: John D. Ament Fix For: 0.6 In many cases, when you deploy with CDI you're using a self contained WAR that has everything in it. However, in certain deployment models you can reference external classpath entries that could be available to you, but not scanned based on CDI scanning rules. To work with these more efficiently, we need to implement some extensions that do very basic things, mostly installing custom beans at runtime to the destination applications. I'll go through the application and identify cases where we need to install a bean, ignoring things that obviously don't belong, e.g. @Typed classes which are understood to not be installed. At a minimum we should create extensions that encompass our primary features, where they don't already exist - for example, Partial Bean is already an extension and needs no other work, Bean Validation doesn't need an extension since it can be configured, Servlet simply needs to be registered. Most of this work seems to be in Core. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-475) auto. registration of jobs with cron-expressions
[ https://issues.apache.org/jira/browse/DELTASPIKE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13855121#comment-13855121 ] Romain Manni-Bucau commented on DELTASPIKE-475: --- Hi guys, I think we can support only quartz ATM. If we need another impl we'll just default to quartz later extracting the specific code...but honestly I doubt it and the API could even rely on quartz to stay simple IMHO auto. registration of jobs with cron-expressions Key: DELTASPIKE-475 URL: https://issues.apache.org/jira/browse/DELTASPIKE-475 Project: DeltaSpike Issue Type: New Feature Components: Scheduler Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.6 includes: - support of any scheduler which allows to register jobs based on cron-expressions - default integration with quartz -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Parent vs BOM
+-0 while deltaspike doesnt use itself the bom (they lead too often to dep issues in practise) Le 23 déc. 2013 02:09, John D. Ament john.d.am...@gmail.com a écrit : Hi all Recently for the binary distribution task, I added a bom. I added this because the parent pom includes our dependencies, as well as our developer list. For someone importing the project to build against, I figured this was a bad idea (we would show as developers in that imported pom). However, this ended up adding some double entry. So I'd like to propose moving this bom up a few directories, and leave this up as the only place to have the modules listed. Importing this one into our parent. WDYT? John
[jira] [Commented] (DELTASPIKE-399) Incorporate Solder's ResourceLoader features into DeltaSpike
[
https://issues.apache.org/jira/browse/DELTASPIKE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13857468#comment-13857468
]
Romain Manni-Bucau commented on DELTASPIKE-399:
---
Guys, why not making the storage an impl of a loader? classpath would use
classloader, file new File() but users can want to extend it. wdyt?
Incorporate Solder's ResourceLoader features into DeltaSpike
Key: DELTASPIKE-399
URL: https://issues.apache.org/jira/browse/DELTASPIKE-399
Project: DeltaSpike
Issue Type: New Feature
Components: Core
Affects Versions: 0.4
Reporter: Aaron Siri
Assignee: John D. Ament
Priority: Minor
Fix For: 0.6
Seam 3's Solder module had some nice resource loading functionality within
the org.jboss.solder.resourceLoader packages. With it you could do the
following:
// Load a properties file
@Inject @Resource(app.properties)
private Properties appProperties;
or:
@Inject
private ResourceProvider resourceProvider
public Properties getHostProperties() {
String hostname = java.net.InetAddress.getLocalHost().getHostName();
return resourceProvider.loadPropertiesBundle(hostname + .properties);
}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-473) Add support for javax.transaction.Transactional annotation added in JTA 1.2 spec
[ https://issues.apache.org/jira/browse/DELTASPIKE-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858091#comment-13858091 ] Romain Manni-Bucau commented on DELTASPIKE-473: --- Hi Some inputs without particular order: 1) in tests arquillian @Transactional helps to test half of use cases 2) ProductServiceTest will not work excepted in standalone so not enough to be portable and handled my DS IMHO 3) one important issue stays: repositories don't handle @Transactional (whatever it is, DS or javax), the best for DS would be to update its annotation to be closer to JavaEE 7 + implement a backend using a DS CDI bean @Transactional (as gateway or wrapper) Add support for javax.transaction.Transactional annotation added in JTA 1.2 spec Key: DELTASPIKE-473 URL: https://issues.apache.org/jira/browse/DELTASPIKE-473 Project: DeltaSpike Issue Type: Improvement Components: Data-Module, JPA-Module, TestControl Affects Versions: 0.6 Reporter: Ivan Vasyliev Attachments: add_jta_1_2_into_deltaspike.patch https://www.youtube.com/watch?v=rChkWy2NFyQ The @Transactional annotation is already part of JavaEE, so there is no need to have custom one. The idea is to reuse code from JTA implementation. The one which already supports 1.2 is Jbosstm(Narayana). I've made an attempt to incorporate it into deltaspike. Please see attached changes and testcase. Few notes on it: - The producers for openwebbeans and weld are different, I've made openwebbeans ones - There is 2 system preferences which needs to be set to make narayana create system folders under proper location (see surefire plugin config) - Latest hibernate can autodetect JTA platform - EntityManager created outside of JTA transaction can't join it automatically, thats why there is proxy which join EM into (http://stackoverflow.com/questions/9182/skipping-jta-sync-registration-due-to-auto-join-checking/11124021#11124021) - Code based on this examples: https://github.com/jbosstm/quickstart/tree/master/ArjunaJTA/standalone-jta-1_2 - I did not make attempt to create generic datasource registration function, this maybe subject for other issue -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Fwd: Support of Instance in OWB
@john: I guess the issue you got with tomee is linked to the
dependencies in DS more than to tomee itself (answered your jira)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/12/29 Gerhard Petracek gerhard.petra...@gmail.com:
@john: please update all arquillian.xml files (not just one).
thx regards,
gerhard
2013/12/29 John D. Ament john.d.am...@gmail.com
Should be fixed now (and fixed the AS7 issue).
On Sun, Dec 29, 2013 at 11:33 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
that means we can't keep it that way (due to this issue).
regards,
gerhard
2013/12/29 John D. Ament john.d.am...@gmail.com
The NPE in TomEE appears to be a TomEE bug, not injecting test method
arguments.
On Sun, Dec 29, 2013 at 10:23 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
@john:
your change also causes a NullPointerException in
ClasspathWebProfileTest#testSuccessfulAmbiguousLookup
(with tomee)
regards,
gerhard
2013/12/29 Gerhard Petracek gerhard.petra...@gmail.com
@john:
you changed it to:
@Test
public void
testAmbiguousFileLookup(@ExternalResource(storage=ClasspathStorage.class,
location=META-INF/beans.xml) InputStream inputStream) {/*...*/}
- the exception still occurs, but junit can't handle it any longer
(because it occurs too early).
regards,
gerhard
2013/12/29 John D. Ament john.d.am...@gmail.com
That's no big deal ( fixed). I had to add a separate SE
WebProfile
test since now we're checking for duplicates and the embedded/SE
containers are picking up the target folders are bean archives (I
hope
TomEE embedded doesn't do this... _ ). Using method injection
delays the injection, however we have a catch that /tmp must be your
tmpdir (I haven't checked on windows yet, but I'm assuming c:/tmp
should be fine..)
@gerhard for some reason now your test doesn't throw a
RuntimeException, but instead the injected instance is null.
On Sun, Dec 29, 2013 at 6:18 AM, Mark Struberg strub...@yahoo.de
wrote:
Well, the explanation is not in the spec but in the JavaDoc.
Compare
http://docs.jboss.org/cdi/api/1.0/javax/enterprise/inject/spi/InjectionPoint.html
with the new wording in CDI-1.1
http://docs.oracle.com/javaee/7/api/javax/enterprise/inject/spi/InjectionPoint.html
I refer to the new sentence
If the injection point is a dynamically selected reference
obtained
then the metadata obtain reflects the injection point of the
Instance,
with
the required type and any additional required qualifers defined by
Instance.select().
This theoretically should work in CDI-1.1 containers. Sadly there
is
no
single implementation which implements this right now.
Weld does provide a synthetic InjectionPoint though, but it only
contains the qualifiers and type of the select but misses all the
information from the Instance injection.
As this is only needed for the test it might be a minor problem
for
us.
Still thinking how we could improve this DeltaSpike test to not
rely on
this method.
Weld-folks, is there already a report on this in Weld, or should I
create one?
I think the wording is clear, do we need to improve it in the CDI
MR?
LieGrue,
strub
- Original Message -
From: John D. Ament john.d.am...@gmail.com
To: u...@openwebbeans.apache.org; Mark Struberg
strub...@yahoo.de
Cc:
Sent: Saturday, 28 December 2013, 15:43
Subject: Re: Fwd: Support of Instance in OWB
Mark,
Thanks for confirming. I don't particularly see anything in 3.2
that
clarifies this, but I'll take your word on it.
On Fri, Dec 27, 2013 at 2:25 PM, Mark Struberg
strub...@yahoo.de
wrote:
Looked at it and did a few tests. And also checked what we
have in
the
spec.
For CDI-1.0 containers a producer bean with an InjectionPoint
should
not be
triggered manually. This is not required in CDI-1.0 (which
OWB-1.2.x
still is)
but only got changed in CDI-1.1.
Please compare the JavaDocs of InjectionPoint for CDI-1.0 and
1.1
to
see
the difference.
I will nonetheless add it to OWB trunk as it is really useful
feature.
thanks for the report!
I've created OWB-921 for it.
LieGrue,
strub
- Original Message -
From: Mark Struberg strub...@yahoo.de
To: u...@openwebbeans.apache.org
u...@openwebbeans.apache.org
Cc:
Sent: Friday, 27 December 2013, 17:45
Subject: Re: Fwd: Support of Instance in OWB
Thanks John, we will investigate!
LieGrue,
strub
[jira] [Comment Edited] (DELTASPIKE-482) Multiple test fixes
[ https://issues.apache.org/jira/browse/DELTASPIKE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858408#comment-13858408 ] Romain Manni-Bucau edited comment on DELTASPIKE-482 at 12/29/13 7:36 PM: - that's half true (don't worry I'll explain ;), it is only true for test method parameters and not class injections so I'd rather say we shouldn't use parameter injections wich are breaking CDI injections (programmatic injections from arq enricher and not the framework + not using CDI semantic) was (Author: romain.manni-bucau): that's half true (don't worry I'll explain ;), it is only true for test method parameters and not class injections so I'd rather say we shouldn't use parameter injections with are broken CDI injections (programmatic injections from arq enricher and not the framework) Multiple test fixes --- Key: DELTASPIKE-482 URL: https://issues.apache.org/jira/browse/DELTASPIKE-482 Project: DeltaSpike Issue Type: Bug Components: Tests Affects Versions: 0.6 Reporter: John D. Ament Assignee: John D. Ament - TomEE container needs to declare dep on CDI enricher from Arq to do CDI enrichment. - Update arquillian.xml globally to handle cdicontainer.version in managed containers. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Servlet Module - Do we really need @Web?
-0 both injections can be different depending on containers using some advanced stuff out of ee but affecting ee lifecycle (at least in tomcat) but your proposal sounds acceptable. Le 3 janv. 2014 17:58, Thomas Andraschko andraschko.tho...@gmail.com a écrit : Hi, IMHO @Web is somehow annoying. HttpServlet e.g. is always web, so @Web is just a overhead and doesn't look nice. Can't we just veto the producers if CDI1.1 is available? The code would be the same with CDI 1.0 + DS, CDI 1.1 without or with DS. Regards, Thomas
Re: Servlet Module - Do we really need @Web?
yes and no, depend what you do of it, the point is if you base your app on CDI (as much as possible I mean) and it starts to be common, you can put logic in these producers, typically wrapping of requests/responses (can be easier than using filters) and in this case this is often not 1-1 replacement. I know it is doable but needs to update the app and can break big apps where you aggregate multiple parts. Having a namespace should be a best practise IMHO. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014/1/4 Gerhard Petracek gerhard.petra...@gmail.com: @romain: i don't see an issue here - if you add the ds-servlet-module, you just drop your own producers (which overlap and should do the same anyway). regards, gerhard 2014/1/4 Romain Manni-Bucau rmannibu...@gmail.com well in fact I saw a lot of cdi 1.0 app producing http* objects without qualifier cause it was missing in cdi so conflicts can occurs and are quite common Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014/1/4 Gerhard Petracek gerhard.petra...@gmail.com: we had no qualifier for FacesContext (in codi, seam3,...). since it used to be a common producer, we saw compatibility issues. however, with a proper documentation (how to veto one of them), no user (i'm aware of) had a real issue with it and for the majority it was easier to use (because there wasn't an issue at all). regards, gerhard 2014/1/4 Mark Struberg strub...@yahoo.de The question for me is: are there already known producers for it or is there any spec which introduces this? In that case a custom qualifier is always a good idea imo. Otherwise we would face different behaviour on different containers. They most times behave different... I just would like to avoid possible incompatibilities. And for this a Qualifier certainly works great - without much additional complexity. Does all the needed detection + veto really pay off? How do you know you are running in an environment which already has such a producer registered? This is not easy to accomplish! Thus I'm for keeping it. LieGrue, strub From: Gerhard Petracek gerhard.petra...@gmail.com To: dev@deltaspike.apache.org Sent: Saturday, 4 January 2014, 12:57 Subject: Re: Servlet Module - Do we really need @Web? +1 for a veto in case of cdi 1.1. @external producers: we can document it (how users can veto e.g. producers, if they see any overlap). however, deltaspike shouldn't add complexity just because there might be a custom producer (for the same). regards, gerhard 2014/1/4 Christian Kaltepoth christ...@kaltepoth.de @John: Actually the Servlet module provides more than what CDI 1.1 adds. For example the event propagation and the recently added WebStorage for the resource loading and so on. So people may want to add the Servlet module even in a CDI 1.1 container. I'm also +0 for that. Of cause it would be nice to get rid of @Web. For the CDI 1.1 case we could actually veto our produces as Thomas suggested. But what about other portable extensions that may have producers for @Default. Say I'm using CDI 1.0 and also have Solder on the classpath. I think Solder is still a common dependency of some libraries, correct? In some regard it is nice to have a custom namespace for the producers. 2014/1/3 Thomas Andraschko andraschko.tho...@gmail.com Because our customers have different servers (tomcat7 and even 6, glassfish, jboss), so it would be a great enhancement for product development. 2014/1/3 John D. Ament john.d.am...@gmail.com If you're in servlet 3.1/CDI 1.1 you don't even need the servlet module (so why include it as a dependency?) On Fri, Jan 3, 2014 at 1:09 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: -0 both injections can be different depending on containers using some advanced stuff out of ee but affecting ee lifecycle (at least in tomcat) but your proposal sounds acceptable. Le 3 janv. 2014 17:58, Thomas Andraschko andraschko.tho...@gmail.com a écrit : Hi, IMHO @Web is somehow annoying. HttpServlet e.g. is always web, so @Web is just a overhead and doesn't look nice. Can't we just veto the producers if CDI1.1 is available? The code would be the same with CDI 1.0 + DS, CDI 1.1 without or with DS. Regards, Thomas -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub
Re: Servlet Module - Do we really need @Web?
@gerhard: @Decorator is broken in 85% of the case and doesn't work with producers IIRC Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014/1/4 Gerhard Petracek gerhard.petra...@gmail.com: @romain: you can use e.g. @Decorator in such special cases or just do the wrapping like you would without cdi. regards, gerhard 2014/1/4 Romain Manni-Bucau rmannibu...@gmail.com yes and no, depend what you do of it, the point is if you base your app on CDI (as much as possible I mean) and it starts to be common, you can put logic in these producers, typically wrapping of requests/responses (can be easier than using filters) and in this case this is often not 1-1 replacement. I know it is doable but needs to update the app and can break big apps where you aggregate multiple parts. Having a namespace should be a best practise IMHO. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014/1/4 Gerhard Petracek gerhard.petra...@gmail.com: @romain: i don't see an issue here - if you add the ds-servlet-module, you just drop your own producers (which overlap and should do the same anyway). regards, gerhard 2014/1/4 Romain Manni-Bucau rmannibu...@gmail.com well in fact I saw a lot of cdi 1.0 app producing http* objects without qualifier cause it was missing in cdi so conflicts can occurs and are quite common Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014/1/4 Gerhard Petracek gerhard.petra...@gmail.com: we had no qualifier for FacesContext (in codi, seam3,...). since it used to be a common producer, we saw compatibility issues. however, with a proper documentation (how to veto one of them), no user (i'm aware of) had a real issue with it and for the majority it was easier to use (because there wasn't an issue at all). regards, gerhard 2014/1/4 Mark Struberg strub...@yahoo.de The question for me is: are there already known producers for it or is there any spec which introduces this? In that case a custom qualifier is always a good idea imo. Otherwise we would face different behaviour on different containers. They most times behave different... I just would like to avoid possible incompatibilities. And for this a Qualifier certainly works great - without much additional complexity. Does all the needed detection + veto really pay off? How do you know you are running in an environment which already has such a producer registered? This is not easy to accomplish! Thus I'm for keeping it. LieGrue, strub From: Gerhard Petracek gerhard.petra...@gmail.com To: dev@deltaspike.apache.org Sent: Saturday, 4 January 2014, 12:57 Subject: Re: Servlet Module - Do we really need @Web? +1 for a veto in case of cdi 1.1. @external producers: we can document it (how users can veto e.g. producers, if they see any overlap). however, deltaspike shouldn't add complexity just because there might be a custom producer (for the same). regards, gerhard 2014/1/4 Christian Kaltepoth christ...@kaltepoth.de @John: Actually the Servlet module provides more than what CDI 1.1 adds. For example the event propagation and the recently added WebStorage for the resource loading and so on. So people may want to add the Servlet module even in a CDI 1.1 container. I'm also +0 for that. Of cause it would be nice to get rid of @Web. For the CDI 1.1 case we could actually veto our produces as Thomas suggested. But what about other portable extensions that may have producers for @Default. Say I'm using CDI 1.0 and also have Solder on the classpath. I think Solder is still a common dependency of some libraries, correct? In some regard it is nice to have a custom namespace for the producers. 2014/1/3 Thomas Andraschko andraschko.tho...@gmail.com Because our customers have different servers (tomcat7 and even 6, glassfish, jboss), so it would be a great enhancement for product development. 2014/1/3 John D. Ament john.d.am...@gmail.com If you're in servlet 3.1/CDI 1.1 you don't even need the servlet module (so why include it as a dependency?) On Fri, Jan 3, 2014 at 1:09 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: -0 both injections can be different depending on containers using some advanced stuff out of ee but affecting ee lifecycle
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
I'd release 0.6 before having it, it will surely create discussion once we'll get something and it is easy to do something totally brokenn in particular when we'll want to get something clever in a web context btw we shouldn't do it without pivotal IMO Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014/1/22 Jason Porter lightguard...@gmail.com: Do we just want to take what we had in Seam 3 and move it over? On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi jason, the bridge doesn't introduce an api and the spi just provides a simple contract for starting the container as well as a bean-filter. - if needed, we could improve the implementation at any time. imo we should add it before the release of v0.6 (since a lot of users requested such a bridge). regards, gerhard 2014/1/22 Jason Porter lightguard...@gmail.com I'd like to engage the Pivotal Team (anyone have contacts?) to see if we can get some of there help as well to create a really good integration. On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi @ all, i would like to continue with this discussion. [1] describes a two-way bridge which is already based on deltaspike. it offers a simple spi which allows more advanced add-ons like it is mentioned in [2]. regards, gerhard [1] http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html 2013/2/19 Matt Benson gudnabr...@gmail.com Okay, I spent some time with Sam on IRC hashing this out. Assuming that Seam-Spring is covered under the SG(s?) Red Hat has filed for deltaspike, his view is that it's not terribly important who does the initial code import, though it would be best for a so-authorized Red Hatter to be the one to change the file headers. I will be out of pocket for the rest of the week beyond today, so if you, Marius, are able to work on the import end of this week/early next then that's in any event as soon as I would have been able to get to it anyway. Otherwise, anyone can do that, with someone still employed by RH finally applying the change that modifies the headers--which, I suppose, could be prepared by anyone else and simply shared among our private git repos. Matt On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici marius.bogoev...@gmail.com wrote: I still am a participant on this thread, but doing more reading than writing as of late :) So, yes, I've been strapped for time with the job and the transition, but I'd be happy to help out with this at the end of the week or early next. With my CLA on file, and the code being granted already, I'm not sure what else needs to be done. I'm happy for the code to live in DeltaSpike, fwiw. On 2013-02-18, at 6:50 PM, Matt Benson gudnabr...@gmail.com wrote: Seems Marius's prior participation on this thread was via a gmail address. With him no longer at Red Hat we definitely want to make sure we take the necessary precautions wrt IP. Matt On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter lightguard...@gmail.com wrote: I'm pretty sure we've granted Seam Spring to Apache. I'll need to check to see if Marius has subscribed to this list on a personal email as he has embarked on a new adventure outside of Red Hat. On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson gudnabr...@gmail.com wrote: Let me refine my plan to say that it would be *best* if Marius does the commit since AIUI this is mostly code he personally authored, but as long as RH intends for Seam-Spring to be donated to Apache deltaspike, probably no irreparable *harm* would be caused by another Red Hatter pulling the trigger. Matt On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson gudnabr...@gmail.com wrote: I think this received enough +1 votes (I'll add mine now) to proceed. If a Red Hatter (Marius?) would do the simplest repackaging possible and commit that then others could join in the quest to modularize the hell out of it. :) Presumably we'd do this on a branch until considered baked enough to merge to master. Let's go! Matt On Mon, Oct 15, 2012 at 10:55 AM, Arne Limburg arne.limb...@openknowledge.de wrote: Hi, Some ideas from my side, too ([1] and [2]). Unfortunately it is in german. But everyone of you can read the code. We used an advanced version of that code to build a Spring-CDI-Bridge in a large project. Unfortunately meanwhile the project is completely migrated to CDI and the code is lost
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
@Charles: ? don't get the point. You would like to use camel to bridge spring and cdi? seems just overengineered and not efficient compared to real integration + why doing a route, setuping camel context just for it + you need then to use camel proxies to get a normal API which is a lot to get nothing fancy and surely slow. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014/1/23 Charles Moulliard ch0...@gmail.com: -1. Why would you like to support Spring Integration while we have Apache Camel which is the most elaborated Spring Java Integration Framework available today, easier to setup, ... proposing also annotations @Produce, @Consume to produce an exchange from and to a Camel Route (= list of processors) On Wed, Jan 22, 2014 at 7:36 PM, Jason Porter lightguard...@gmail.comwrote: +1 for adding the Spring integration On Wed, Jan 22, 2014 at 11:21 AM, John D. Ament john.d.am...@gmail.com wrote: +1 to Romain I'd like to see something like this for a 1.0 release. It would be a real game changer. On Wed, Jan 22, 2014 at 12:03 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: I'd release 0.6 before having it, it will surely create discussion once we'll get something and it is easy to do something totally brokenn in particular when we'll want to get something clever in a web context btw we shouldn't do it without pivotal IMO Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014/1/22 Jason Porter lightguard...@gmail.com: Do we just want to take what we had in Seam 3 and move it over? On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi jason, the bridge doesn't introduce an api and the spi just provides a simple contract for starting the container as well as a bean-filter. - if needed, we could improve the implementation at any time. imo we should add it before the release of v0.6 (since a lot of users requested such a bridge). regards, gerhard 2014/1/22 Jason Porter lightguard...@gmail.com I'd like to engage the Pivotal Team (anyone have contacts?) to see if we can get some of there help as well to create a really good integration. On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi @ all, i would like to continue with this discussion. [1] describes a two-way bridge which is already based on deltaspike. it offers a simple spi which allows more advanced add-ons like it is mentioned in [2]. regards, gerhard [1] http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html 2013/2/19 Matt Benson gudnabr...@gmail.com Okay, I spent some time with Sam on IRC hashing this out. Assuming that Seam-Spring is covered under the SG(s?) Red Hat has filed for deltaspike, his view is that it's not terribly important who does the initial code import, though it would be best for a so-authorized Red Hatter to be the one to change the file headers. I will be out of pocket for the rest of the week beyond today, so if you, Marius, are able to work on the import end of this week/early next then that's in any event as soon as I would have been able to get to it anyway. Otherwise, anyone can do that, with someone still employed by RH finally applying the change that modifies the headers--which, I suppose, could be prepared by anyone else and simply shared among our private git repos. Matt On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici marius.bogoev...@gmail.com wrote: I still am a participant on this thread, but doing more reading than writing as of late :) So, yes, I've been strapped for time with the job and the transition, but I'd be happy to help out with this at the end of the week or early next. With my CLA on file, and the code being granted already, I'm not sure what else needs to be done. I'm happy for the code to live in DeltaSpike, fwiw. On 2013-02-18, at 6:50 PM, Matt Benson gudnabr...@gmail.com wrote: Seems Marius's prior participation on this thread was via a gmail address. With him no longer at Red Hat we definitely want to make sure we take the necessary precautions wrt IP. Matt On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter lightguard...@gmail.com wrote: I'm pretty sure we've granted Seam Spring to Apache
[jira] [Commented] (DELTASPIKE-518) DS Data should support Wrapped JPA APIs
[ https://issues.apache.org/jira/browse/DELTASPIKE-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Closed] (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 ] Romain Manni-Bucau closed DELTASPIKE-518. - Resolution: Fixed Fix Version/s: 0.6 Assignee: Romain Manni-Bucau Reworked a bit the patch to use the unwrapped version in the extractor and not only pass the test if we can extract the query. Thanks JL anyway :) 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)
Re: [DISCUSS] DeltaSpike Launch Module
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 john.d.am...@gmail.com a écrit : Hi all I've been working a bit on a POC. The idea is to run a light weight Java SE application that does some basic bootstrapping and container services. The SE app would be configured with a basic socket listener using Netty and delegate requests to a REST provider. The idea behind it is that CDI forms the low level core of the container, where a developer can deploy services they build on their own. The application is meant to be an API type server (deploy REST APIs) that runs using Netty, starts up a CDI container using DeltaSpike Container Control API. The launch module would handle the basic bootstrap of the rest provider, instantiating the CDI container using ContainerControl, and handle the necessary bootstrap for lookup up resources and registering with the provider. This type of module would compete with Spring Boot. Currently what I have leverages Weld 2.1.1 and RestEasy. The equivalent should work for CXF. There's no hard dependency on Weld. I was thinking the module structure would include an api, spi, impl-resteasy and impl-cxf. Some things I'd like to add: - Automatic bootstrap of JPA (via JPA module) - Transaction intercepting (probably need to pull in the Geronimo lib) - Probably also register some providers automatically as well. Let me know your thoughts. John
Re: Interceptors not being called in JUnit-aware CDI environment
HI
You want to intercept the test? so it means the runner needs to invoke
business methods of the test class which is not the case by default
(ie result shouldn't be built from a newInstance() but from a
beanManager.getXXX()).
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-07 it-media.k...@daimler.com:
Hello,
I've been trying to start the CDI container during Junit-Testing as described
at the following page,
http://struberg.wordpress.com/2012/03/27/unit-testing-strategies-for-cdi-based-projects/
though I'm using Junit 4 and implemented everything using a new Runner (to
annotate tests with @RunWith). I kind of got inspired by he CDIUnit project,
but it works only with Weld and I want to use OpenWebBeans.
The major things like injection work perfectly, however, I realized, that
even though I implemented the following code to provided a CDI aware
Test-Class, an interceptor annotation on a test method is completely ignored,
thus the interceptors AroundInvoke annotated method is not called.
private T T createTest(final ClassT testClass) throws Exception
{
final BeanManager beanManager = cdiContainer.getBeanManager();
final CreationalContextT creationalContext =
beanManager.createCreationalContext(null);
final AnnotatedTypeT annotatedType =
beanManager.createAnnotatedType(testClass);
final InjectionTargetT injectionTarget =
beanManager.createInjectionTarget(annotatedType);
final T result = (T)
getTestClass().getOnlyConstructor().newInstance();
injectionTarget.inject(result, creationalContext);
return result;
}
Is this expected behaviour? I'm not so familiar with how interceptors are
really implemented, but I would have guest that after providing a creational
context and complete injection for the test class, interceptor annotations
should work too. The interceptor itself is registered correctly. It is listed
among all interceptors when calling
WebBeansContext.currentInstance().getInterceptorsManager().getCdiInterceptors()
however, a test annotated with the interceptor does not trigger execution of
the AroundInvoke-method.
Would be great, if somebody has a thought or a hint on this.
Thanks,
Heiko
If you are not the addressee, please inform us immediately that you have
received this e-mail by mistake, and delete it. We thank you for your support.
Re: Interceptors not being called in JUnit-aware CDI environment
is you test class scanned by cdi? I mean did you provide a
META-INF/beans.xml for tests?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-07 it-media.k...@daimler.com:
Hello Romain,
thank you for your fast response. Yes I want to intercept the test itself.
I've checked into various ways on how to actually create a bean, however
nothing worked out. You mention to call beanManager.getXXX() but for my point
that is not enough information.
I tried to retrieve the beans of the test class via beanManager.getBeans()
but regardless of what I try as annotation literals there (non, Any, etc.)
nothing works, the list is always empty. What method exactly did you have in
mind here?
Thanks,
Heiko
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Freitag, 7. Februar 2014 08:26
An: dev@deltaspike.apache.org
Betreff: Re: Interceptors not being called in JUnit-aware CDI environment
=
==
ATTENTION! This message contains suspicious URL(s) possibly redirecting to
malicious content. Our security gateways target known problem URLs like
freeweb or URL Shorteners that are being abused by spammers. Some
examples would be groups.google.com or tinyurl.com. Please check the sender
and hyperlinks in the e-mail accurately before clicking on a link. If this
email
seems obviously bad to you please delete it. More information is available
on
our website Information Security @ Daimler: http://intra.corpintra.net/intra-
is-e/spam
=
==
ACHTUNG! Diese E-Mail enthält verdächtige URLs welche möglicherweise auf
schädlichen Inhalt verweisen. Die Security Gateways prüfen auf bekannte
Problem-URLs wie zum Beispiel URL-Abkürzungen, die bevorzugt von
Spammern mißbraucht werden (tinyurl.com, groups.google.com, ...). Bitte
prüfen Sie den Absender und die URLs in dieser E-Mail gewissenhaft bevor sie
die verknüpften Inhalte aufrufen. Bitte löschen Sie diese E-Mail, wenn Sie
der
Meinung sind, daß sich der Verdacht bestätigt. Weitere Informationen zu
unerwünschter E-Mail / SPAM finden Sie auf den Seiten der
Informationssicherheit bei Daimler unter:
http://intra.corpintra.net/intra-is-
d/spam
=
==
HI
You want to intercept the test? so it means the runner needs to invoke
business methods of the test class which is not the case by default (ie
result
shouldn't be built from a newInstance() but from a beanManager.getXXX()).
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-07 it-media.k...@daimler.com:
Hello,
I've been trying to start the CDI container during Junit-Testing as
described at the following page,
http://struberg.wordpress.com/2012/03/27/unit-testing-strategies-for-c
di-based-projects/
though I'm using Junit 4 and implemented everything using a new Runner (to
annotate tests with @RunWith). I kind of got inspired by he CDIUnit project,
but
it works only with Weld and I want to use OpenWebBeans.
The major things like injection work perfectly, however, I realized, that
even
though I implemented the following code to provided a CDI aware Test-Class,
an interceptor annotation on a test method is completely ignored, thus the
interceptors AroundInvoke annotated method is not called.
private T T createTest(final ClassT testClass) throws Exception
{
final BeanManager beanManager = cdiContainer.getBeanManager();
final CreationalContextT creationalContext =
beanManager.createCreationalContext(null);
final AnnotatedTypeT annotatedType =
beanManager.createAnnotatedType(testClass);
final InjectionTargetT injectionTarget =
beanManager.createInjectionTarget(annotatedType);
final T result = (T)
getTestClass().getOnlyConstructor().newInstance();
injectionTarget.inject(result, creationalContext);
return result;
}
Is this expected behaviour? I'm not so familiar with how interceptors
are really implemented, but I would have guest that after providing a
creational context and complete injection for the test class,
interceptor annotations should work too. The interceptor itself is
registered correctly. It is listed among all interceptors when calling
WebBeansContext.currentInstance().getInterceptorsManager().getCdiInter
ceptors()
however, a test annotated with the interceptor does not trigger execution
of
the AroundInvoke-method.
Would be great, if somebody has a thought or a hint on this.
Thanks,
Heiko
If you are not the addressee
Re: AW: Interceptors not being called in JUnit-aware CDI environment
Side note: you can also use a JUnit @Rule ;)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-07 Gerhard Petracek gerhard.petra...@gmail.com:
hi heiko,
you can use CdiTestRunner + configure true for:
deltaspike.testcontrol.use_test_class_as_cdi_bean
regards,
gerhard
http://www.irian.at
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2014-02-07 it-media.k...@daimler.com:
Hello Mark,
thank you for your input. Your idea would have been much easier than what
I did :-)
When you write a Junit Runner, you have the ability to control the test
class creation by overwriting createTest() and returning your instance. By
default this is simply the newInstance() call for the constructor with no
arguments of the test class. The following code will therefore not only
provide injection but even create a fully creational contexted bean that
even will trigger interceptors. I've made sure though, that after calling
all 'AfterClass'-Annotations, the creational context is released too, so
the bean does not stick around.
I do not really have a clue though how this could be done with TestNg.
I might miss out some clearContexts() here. I thought about cleaning the
contexts before a new test-method is run, however I loose all beans
discovered and created while the container booted, and that lead to failing
tests. I need the container being created BEFORE createTest() is called to
be able to do the bean creation. I have to dive into this more deeply.
Another Idea would be to simply boot the container again before each method
and shut it down afterwards, though this will slow down tests.
public class TestRunner extends BlockJUnit4ClassRunner
{
private Class? clazz;
private CreationalContext? creationalContext;
public TestRunner(final Class? clazz) throws InitializationError
{
super(clazz);
this.clazz = clazz;
cdiContainer = CdiContainerLoader.getCdiContainer();
cdiContainer.boot();
cdiContainer.getContextControl().startContexts();
}
@Override
protected Object createTest()
throws Exception
{
return createTest(clazz);
}
@SuppressWarnings(unchecked)
private T T createTest(final ClassT testClass) throws Exception
{
final BeanManager beanManager = cdiContainer.getBeanManager();
final SetBean? beans = beanManager.getBeans(testClass);
assert !beans.isEmpty();
final Bean? bean = beans.iterator().next();
creationalContext = beanManager.createCreationalContext(bean);
final T result = (T) beanManager.getReference(bean, testClass,
creationalContext);
return result;
}
@Override
protected Statement withAfterClasses(final Statement statement)
{
final Statement defaultStatement =
super.withAfterClasses(statement);
return new Statement()
{
@Override
public void evaluate()
throws Throwable
{
try
{
defaultStatement.evaluate();
}
finally
{
creationalContext.release();
}
}
};
}
Regards,
Heiko
-Ursprüngliche Nachricht-
Von: Mark Struberg [mailto:strub...@yahoo.de]
Gesendet: Freitag, 7. Februar 2014 09:29
An: dev@deltaspike.apache.org
Betreff: Re: AW: Interceptors not being called in JUnit-aware CDI
environment
=
==
ATTENTION! This message contains suspicious URL(s) possibly redirecting
to
malicious content. Our security gateways target known problem URLs like
freeweb or URL Shorteners that are being abused by spammers. Some
examples would be groups.google.com or tinyurl.com. Please check the
sender
and hyperlinks in the e-mail accurately before clicking on a link. If
this email
seems obviously bad to you please delete it. More information is
available on
our website Information Security @ Daimler:
http://intra.corpintra.net/intra-
is-e/spam
=
==
ACHTUNG! Diese E-Mail enthält verdächtige URLs welche möglicherweise auf
schädlichen Inhalt verweisen. Die Security Gateways prüfen auf bekannte
Problem-URLs wie zum Beispiel URL-Abkürzungen, die bevorzugt von
Spammern mißbraucht werden (tinyurl.com, groups.google.com, ...). Bitte
prüfen Sie den Absender und die URLs in dieser E-Mail gewissenhaft bevor
sie
die verknüpften Inhalte aufrufen. Bitte löschen Sie diese E-Mail, wenn
Sie der
Meinung sind, daß sich der Verdacht bestätigt. Weitere
[jira] [Commented] (DELTASPIKE-519) ClassLoader leak in ClassDeactivationUtils
[
https://issues.apache.org/jira/browse/DELTASPIKE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894475#comment-13894475
]
Romain Manni-Bucau commented on DELTASPIKE-519:
---
I think we have it for BeanManagerProvider too. We spoke about having a map
store in the classloader (using Unsafe), it could do the trick and would avoid
the need to track classloaders
ClassLoader leak in ClassDeactivationUtils
--
Key: DELTASPIKE-519
URL: https://issues.apache.org/jira/browse/DELTASPIKE-519
Project: DeltaSpike
Issue Type: Bug
Components: Core
Affects Versions: 0.5
Reporter: Moritz Bechler
Priority: Critical
ClassDeactivationUtils statically holds two maps (classDeactivatorMap,
activationStatusCache) one having a classloader as key and the other a class.
These entries are never removed resulting in leaks of the TCCL or the
classloaders of Deactivatable classes if they do not equal the classloader
loading deltaspike.
Suggested fix:
{code}
/**
* This Map holds the ClassLoader as first level to make it possible to
have different configurations per
* WebApplication in an EAR or other Multi-ClassLoader scenario.
*
* The Map then contains a List of {@link ClassDeactivator}s in order of
their configured ordinal.
*/
private static MapClassLoader, ListClassDeactivator
classDeactivatorMap
= Collections.synchronizedMap(new WeakHashMapClassLoader,
ListClassDeactivator());
/**
* Cache for the result. It won't contain many classes but it might be
accessed frequently.
* Valid entries are only true or false. If an entry isn't available or
null, it gets calculated.
*/
private static MapClass? extends Deactivatable, Boolean
activationStatusCache
= Collections.synchronizedMap(new WeakHashMapClass? extends
Deactivatable, Boolean());
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-519) ClassLoader leak in ClassDeactivationUtils
[
https://issues.apache.org/jira/browse/DELTASPIKE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894508#comment-13894508
]
Romain Manni-Bucau commented on DELTASPIKE-519:
---
excepted startup loader and runtime/shutdown loader can be different
ClassLoader leak in ClassDeactivationUtils
--
Key: DELTASPIKE-519
URL: https://issues.apache.org/jira/browse/DELTASPIKE-519
Project: DeltaSpike
Issue Type: Bug
Components: Core
Affects Versions: 0.5
Reporter: Moritz Bechler
Priority: Critical
ClassDeactivationUtils statically holds two maps (classDeactivatorMap,
activationStatusCache) one having a classloader as key and the other a class.
These entries are never removed resulting in leaks of the TCCL or the
classloaders of Deactivatable classes if they do not equal the classloader
loading deltaspike.
Suggested fix:
{code}
/**
* This Map holds the ClassLoader as first level to make it possible to
have different configurations per
* WebApplication in an EAR or other Multi-ClassLoader scenario.
*
* The Map then contains a List of {@link ClassDeactivator}s in order of
their configured ordinal.
*/
private static MapClassLoader, ListClassDeactivator
classDeactivatorMap
= Collections.synchronizedMap(new WeakHashMapClassLoader,
ListClassDeactivator());
/**
* Cache for the result. It won't contain many classes but it might be
accessed frequently.
* Valid entries are only true or false. If an entry isn't available or
null, it gets calculated.
*/
private static MapClass? extends Deactivatable, Boolean
activationStatusCache
= Collections.synchronizedMap(new WeakHashMapClass? extends
Deactivatable, Boolean());
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
Re: [Discuss] Data Module - Transactional Repositories
While it works with JTA it is ok for me, I think it should be compatible with our @Transactional and EE 7 one. I think reusing @Transactional is important in declaration (on method) so maybe the way to go. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-12 11:40 GMT+01:00 Jean-Louis MONTEIRO jeano...@gmail.com: +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 thomas@gmail.com: 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
[jira] [Commented] (DELTASPIKE-522) Align cdiCtrl to modules and rename to match other modules named control.
[ https://issues.apache.org/jira/browse/DELTASPIKE-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901187#comment-13901187 ] Romain Manni-Bucau commented on DELTASPIKE-522: --- +1 this is already too much used to change it even before 1.0. Align cdiCtrl to modules and rename to match other modules named control. - Key: DELTASPIKE-522 URL: https://issues.apache.org/jira/browse/DELTASPIKE-522 Project: DeltaSpike Issue Type: Improvement Components: CdiControl Reporter: John D. Ament Assignee: John D. Ament Fix For: 0.6 Refactor cdi ctrl to be under modules. Update all relevant docs and realign parent pom to match other modules. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Revisit cdiCtrl module name and how it's inconsistent with test-control?
well I don't agree on modules hierarchy which looks inconsistent but I dont really care while code is here but I agree with Mark names are already used 'in fact it is true for this and for core) so we shouldn't change it anymore. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-14 9:38 GMT+01:00 Karl Kildén karl.kil...@gmail.com: 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
Re: Revisit cdiCtrl module name and how it's inconsistent with test-control?
that's not true at all, depend the virality of the code. CdiCtrl and core are viral now. So either we say users to not use DS before 0.1 or we keep stability on used modules. Honestly I don't think we have the choice if we want to promote what we propose. We are late for a 1.0 so already too much used so we have 1.0 constraints already. Only new modules don't have them. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-14 10:46 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com: imo the definition should be simple: if it depends on deltaspike-core, it's a module @romain: again: there is no issue with api-/name-/... changes before v1. we had a similar change in codi (before v1) and there was no issue with it. (+ we emphasized the possibility of such changes from the very beginning). regards, gerhard 2014-02-14 10:08 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: well I don't agree on modules hierarchy which looks inconsistent but I dont really care while code is here but I agree with Mark names are already used 'in fact it is true for this and for core) so we shouldn't change it anymore. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-14 9:38 GMT+01:00 Karl Kildén karl.kil...@gmail.com: 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
Re: Revisit cdiCtrl module name and how it's inconsistent with test-control?
that's the main point of the discussion I think. We are consistent with what we said but users can't wait for years so we are too used to maintain it. +1 for a vote Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-14 11:33 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com: we would need a vote about your statement, because it changes our official statement. if the majority agrees, we have to postpone such discussions (e.g. until v2). a lot of users are still waiting for v1 before they start with deltaspike. - we are late, but according to our official statement we are still in the pre v1 mode/phase. regards, gerhard 2014-02-14 10:49 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: that's not true at all, depend the virality of the code. CdiCtrl and core are viral now. So either we say users to not use DS before 0.1 or we keep stability on used modules. Honestly I don't think we have the choice if we want to promote what we propose. We are late for a 1.0 so already too much used so we have 1.0 constraints already. Only new modules don't have them. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-14 10:46 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com: imo the definition should be simple: if it depends on deltaspike-core, it's a module @romain: again: there is no issue with api-/name-/... changes before v1. we had a similar change in codi (before v1) and there was no issue with it. (+ we emphasized the possibility of such changes from the very beginning). regards, gerhard 2014-02-14 10:08 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: well I don't agree on modules hierarchy which looks inconsistent but I dont really care while code is here but I agree with Mark names are already used 'in fact it is true for this and for core) so we shouldn't change it anymore. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-14 9:38 GMT+01:00 Karl Kildén karl.kil...@gmail.com: 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
Re: Revisit cdiCtrl module name and how it's inconsistent with test-control?
+0 for position -1 for name or maven coordinates Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-14 13:21 GMT+01:00 it-media.k...@daimler.com: Seems this way. I think this whole dicussion is becoming ridicuolus. Change it to comply with the rest. I personally never understood why this very lonely 'module' cdiCtrl is located elsewhere, regardless on whether it has different dependencies or not. Additionally it does not fit into the naming scheme used otherwise. It's a version 0.6 and regardless of how often it is used, the name change can be reflected on the website and we are dealing with developers here. They are most likely capable of changing an artifact's name, don't you think? So for a vote: +1 for changing it's name. +1 for changing it's position. My two cents, Heiko -Ursprüngliche Nachricht- Von: John D. Ament [mailto:john.d.am...@gmail.com] Gesendet: Freitag, 14. Februar 2014 12:28 An: deltaspike Betreff: Re: Revisit cdiCtrl module name and how it's inconsistent with test- control? So, we're voting on starting a vote at this point as to whether or not we can change a JAR's name pre 1.0? On Fri, Feb 14, 2014 at 5:42 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: that's the main point of the discussion I think. We are consistent with what we said but users can't wait for years so we are too used to maintain it. +1 for a vote Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-14 11:33 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com: we would need a vote about your statement, because it changes our official statement. if the majority agrees, we have to postpone such discussions (e.g. until v2). a lot of users are still waiting for v1 before they start with deltaspike. - we are late, but according to our official statement we are still - in the pre v1 mode/phase. regards, gerhard 2014-02-14 10:49 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: that's not true at all, depend the virality of the code. CdiCtrl and core are viral now. So either we say users to not use DS before 0.1 or we keep stability on used modules. Honestly I don't think we have the choice if we want to promote what we propose. We are late for a 1.0 so already too much used so we have 1.0 constraints already. Only new modules don't have them. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-14 10:46 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com: imo the definition should be simple: if it depends on deltaspike-core, it's a module @romain: again: there is no issue with api-/name-/... changes before v1. we had a similar change in codi (before v1) and there was no issue with it. (+ we emphasized the possibility of such changes from the very beginning). regards, gerhard 2014-02-14 10:08 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: well I don't agree on modules hierarchy which looks inconsistent but I dont really care while code is here but I agree with Mark names are already used 'in fact it is true for this and for core) so we shouldn't change it anymore. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-14 9:38 GMT+01:00 Karl Kildén karl.kil...@gmail.com: 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
Re: [Discuss] Data Module - Transactional Repositories
Hello, 1) a producer + qualifier would be easier on entitymanager side so I'd propagate it to the repository. 2) em in transactionscoped should be useless since if you produce the em you are already in a scope so already cached by CDI itself, no? 3) we don't really need interceptors since we can invoke it ourself in the handler (for me CRUD + transaction need to fit together so not shocking to keep them linked. JPA is linked to JTA BTW ;)), it would even be important to be able to avoid nested transactions by default (I don't recall what does default @Tx impl). Where I'm less confident is with current @Tx impl we can't force a new transaction so we doesn't cover all needed case. But should be enough to start. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-17 7:51 GMT+01:00 Thomas Hug thomas@gmail.com: Yes would be great to get this sorted out soon. Looks like 2) is the preferred way to go, which would also mean some work on the JPA module. - Any thoughts on how the Data EntityManagerResolver fits in the picture there? - Also [1] seems rather nasty in this context. Is there a better way dealing with it than just trying to detect it has not been picked up and then call the TransactionStrategy by ourself? [1] https://issues.apache.org/jira/browse/DELTASPIKE-419 On Sun, Feb 16, 2014 at 10:10 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Hi Thomas, would be great to get it in 0.6, any idea if it would be possible? I should be able to help once decided and if needed. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-12 12:13 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: While it works with JTA it is ok for me, I think it should be compatible with our @Transactional and EE 7 one. I think reusing @Transactional is important in declaration (on method) so maybe the way to go. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-12 11:40 GMT+01:00 Jean-Louis MONTEIRO jeano...@gmail.com: +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 thomas@gmail.com: Not sure where we stopped in the discussion but AFAIR we had two approaches here: 1) An automatic internal tx handling if one is needed by the query, probably similar to what the JPA module does in the EnvironmentAwareTransactionStrategy. Could eventually be controlled by an attribute on @Repository defaulting to active. 2) Integration with @Transactional of the JPA module. For this we'd also have to look at: - Aligning EntityManager resolution between the two modules. That could include moving the EntityManagerResolver into the JPA module API and eventually removing the current qualifier-based resolution. That one would need some more thoughts to get out something consistent. - Eventually exposing the resolved EM @TransactionScoped so the repository can easily access it. - Deal with PartialBeans not picking up interceptors - AFAIR this was reported to be an issue on some Weld versions? +1 on 2) - makes for me much more sense from a user perspective. -- Jean-Louis
Re: [DISCUSS] next release version? 0.6 or 1.0?
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 strub...@yahoo.de: 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 oranh...@gmail.com wrote: That's reasonable enough. On 16. feb. 2014, at 23:02, Jason Porter lightguard...@gmail.com 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 oranh...@gmail.com wrote: The commit graph shows too few committers.. and I appreciate your work! I also notice too few Redhat/JBoss Weld/Seam committers left on the project. How come? /ove On 16. feb. 2014, at 22:10, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi ove, i was only talking about the commits. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2014-02-16 22:07 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: +1 Ove We are really late for an 0.6. I would release 0.6 this/next month and after that, lets finish 1.0. We should fix all open issues and finish the documentation!
Re: Servlet Module - Do we really need @Web?
Project name should be fine now, if not all pakcages will change so
same impact than annotation name
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-18 9:18 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com:
I like @DeltaSpike but as gerhard said, maybe it's better to use one
without the project name in it? On the other side, DeltaSpike is the final
name...
Maybe @ExtensionManaged?
2014-02-18 8:54 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com:
@Gerhard: loos too much to existing JMX APIs + managed doesn't mean
anything anymore today IMO
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-18 8:32 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com:
@thomas:
maybe something like @Managed or @ManagedResource
regards,
gerhard
2014-02-18 7:17 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com:
@DeltaSpike?
Le 18 févr. 2014 06:26, Christian Kaltepoth christ...@kaltepoth.de
a
écrit :
@Thomas: I also like the idea of a global qualifier like this. That's
something I was already looking for when I created @Web back then. But
the
most difficult question is what the name should be. Unfortunately
I've no
really good idea.
2014-02-15 15:26 GMT+01:00 Thomas Andraschko
andraschko.tho...@gmail.com
:
+1
Any ideas about the name gerhard?
Any veto about such a change?
2014-02-15 11:29 GMT+01:00 Gerhard Petracek
gerhard.petra...@gmail.com
:
i'm ok with changing it, if we do it for both.
however, we would need a better name (imo without the
project-name).
regards,
gerhard
2014-02-15 11:24 GMT+01:00 Thomas Andraschko
andraschko.tho...@gmail.com
:
I found another case were something like
@DeltaSpike/@DeltaSpikeManaged/etc. would probably be a better
name:
@JsfPhaseListener public class MyPhaseListener implements
PhaseListener {
... }
It's the same as with @Web.
We already know that it's an PhaseListener. So why name the
annotation
the
same again?
We also already know that a HttpServletRequest is something from
the
Web...
2014-01-07 17:44 GMT+01:00 Thomas Andraschko
andraschko.tho...@gmail.com
:
In the CDI 1.1 specs (3.7), there are only following beans
defined:
HttpServletRequest
HttpSession
ServletContext
So if you are in a CDI 1.1 environment, it might be confusing
because
some
artifacts are available without @Web and some only with @Web.
I will open a vote about it because i can't see a reason to
keep
@Web
2014/1/5 Karl Kildén karl.kil...@gmail.com
This is my summary:
By following the discussion it seems to be seen as
convenient vs
inconvenient and the vote is kinda even. What I would like to
see
is
cohesion in Deltaspike overall. Either you use namespaces or
you
don't.
My
point is basically that it feels more like a project-wide
decision.
To summarize, when a spec or w/e is expected to introduce the
same
producer
different strategies can be used. So either the strategy as a
user
is
to
a)
use the namespace and drop it when someone else provides it
(i.e a
spec)
or
b) Trust Deltaspike to handle any conflicts.
pros:
- No conflicts or conflict management.
- Users can use both variants for example if Deltaspike
offers
extras.
Apparently already true for Servlet Module.
- Abolishes the idea of transparent replacement with the
argument
that
various enhancements might make it incompatible anyways.
cons:
- Must remove namespace when Deltaspike is superfluous. No
namespace
and
automatic veto would make it more seamless.
- More verbose and not as pretty to use.
- Does not see incompatibly as a big problem. Reasoning is:
End
user
must
test application behavior after upgrade anyway and problems
should
be
minor.
Btw i'm +0
On 4 January 2014 17:09, Gerhard Petracek
gerhard.petra...@gmail.com
wrote:
to summarize it:
so far we haven't seen a real blocker for dropping the
qualifier.
regards,
gerhard
2014/1/4 Romain Manni-Bucau rmannibu...@gmail.com
never said it was blocking, just it shouldn't be done
blindly
and
docs
Re: Servlet Module - Do we really need @Web?
well managedresource looks really like a jmx stuff for me and since it
uses cdi managed is quite obvious. That's why i thought the project
name would fit and make the origin obvious.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-18 9:51 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com:
@romain:
maybe not @Managed (it was just @DeltaSpikeManaged without the
project-name), but @ManagedResource is at least more expressive than the
project-name itself.
(that it's managed by ds is clear due to the package-name imo)
regards,
gerhard
2014-02-18 9:30 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com:
@Gerhard: hmm, @Managed neither in fact + the type is expressive,
qualifier is just a namespace IMO
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-18 9:26 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com:
@romain: the point is that it isn't expressive at all...
regards,
gerhard
2014-02-18 9:20 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com:
Project name should be fine now, if not all pakcages will change so
same impact than annotation name
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-18 9:18 GMT+01:00 Thomas Andraschko
andraschko.tho...@gmail.com:
I like @DeltaSpike but as gerhard said, maybe it's better to use one
without the project name in it? On the other side, DeltaSpike is the
final
name...
Maybe @ExtensionManaged?
2014-02-18 8:54 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com:
@Gerhard: loos too much to existing JMX APIs + managed doesn't mean
anything anymore today IMO
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-18 8:32 GMT+01:00 Gerhard Petracek
gerhard.petra...@gmail.com
:
@thomas:
maybe something like @Managed or @ManagedResource
regards,
gerhard
2014-02-18 7:17 GMT+01:00 Romain Manni-Bucau
rmannibu...@gmail.com:
@DeltaSpike?
Le 18 févr. 2014 06:26, Christian Kaltepoth
christ...@kaltepoth.de
a
écrit :
@Thomas: I also like the idea of a global qualifier like this.
That's
something I was already looking for when I created @Web back
then.
But
the
most difficult question is what the name should be.
Unfortunately
I've no
really good idea.
2014-02-15 15:26 GMT+01:00 Thomas Andraschko
andraschko.tho...@gmail.com
:
+1
Any ideas about the name gerhard?
Any veto about such a change?
2014-02-15 11:29 GMT+01:00 Gerhard Petracek
gerhard.petra...@gmail.com
:
i'm ok with changing it, if we do it for both.
however, we would need a better name (imo without the
project-name).
regards,
gerhard
2014-02-15 11:24 GMT+01:00 Thomas Andraschko
andraschko.tho...@gmail.com
:
I found another case were something like
@DeltaSpike/@DeltaSpikeManaged/etc. would probably be a
better
name:
@JsfPhaseListener public class MyPhaseListener implements
PhaseListener {
... }
It's the same as with @Web.
We already know that it's an PhaseListener. So why name
the
annotation
the
same again?
We also already know that a HttpServletRequest is
something
from
the
Web...
2014-01-07 17:44 GMT+01:00 Thomas Andraschko
andraschko.tho...@gmail.com
:
In the CDI 1.1 specs (3.7), there are only following
beans
defined:
HttpServletRequest
HttpSession
ServletContext
So if you are in a CDI 1.1 environment, it might be
confusing
because
some
artifacts are available without @Web and some only with
@Web.
I will open a vote about it because i can't see a
reason to
keep
@Web
2014/1/5 Karl Kildén karl.kil...@gmail.com
This is my summary:
By following the discussion it seems to be seen as
convenient vs
inconvenient and the vote is kinda even. What I would
like to
see
is
cohesion in Deltaspike overall. Either you use
namespaces
or
you
don't.
My
point is basically that it feels more like a
project-wide
Re: Servlet Module - Do we really need @Web?
+1 kind of tradeoff Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-18 10:46 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com: we haven't seen a nice name so far - i would keep what we have right now (it's redundant, but at least a bit more expressive). regards, gerhard 2014-02-18 10:20 GMT+01:00 Mark Struberg strub...@yahoo.de: I do agree on @Managed not being very expressive. Think about the @ManagedBean disaster in JavaEE itself. 'Managed' is in the same ballpark like 'Class' or 'Object'. Managed by whom and what? In that case I'd rather go with @DeltaSpike or keep @Web... But I do not care that much about names... LieGrue, strub On Tuesday, 18 February 2014, 10:15, Romain Manni-Bucau rmannibu...@gmail.com wrote: @Gerhard: yeah but managed is not expressive, doesnt give the origin + is quite standard for jmxso i would avoid it. That said it doesnt bring any feature so i dont want to fight for a name. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-18 10:12 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com: @romain: you will always have same/similar terms in different areas (see e.g. message). regards, gerhard
Re: PartialBeans and concrete methods
I think so too Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-20 13:05 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com: imo we just need to support interceptors. regards, gerhard 2014-02-20 12:20 GMT+01:00 Thomas Hug thomas@gmail.com: While looking at transactional repositories, I realized that PartialBeans invoke concrete methods directly. That doesn't give the invocation handler a chance to hook into the call (and in the data case to control the tx). What about creating an additional handler interface which also allows to pass in the proceeding method? Or is there a better alternative?
Re: PartialBeans and concrete methods
it is since you use the handled (interface for instance) as metadata, no? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-20 16:32 GMT+01:00 Thomas Hug thomas@gmail.com: The more conceptual issue in this concrete case is that @Transactional isn't really independent from the handler class (namely EntityManager resolution). But I guess that's something we can deal with. So given the release time frame - anything we can do here or shall we park this case for now? On Thu, Feb 20, 2014 at 2:17 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: I think so too Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-20 13:05 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com: imo we just need to support interceptors. regards, gerhard 2014-02-20 12:20 GMT+01:00 Thomas Hug thomas@gmail.com: While looking at transactional repositories, I realized that PartialBeans invoke concrete methods directly. That doesn't give the invocation handler a chance to hook into the call (and in the data case to control the tx). What about creating an additional handler interface which also allows to pass in the proceeding method? Or is there a better alternative?
Re: PartialBeans and concrete methods
Ok got, that's because @Tx and@EMC doesn't use same syntax. If both
uses qualifier it would work
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-20 17:15 GMT+01:00 Thomas Hug thomas@gmail.com:
Basically that's the case I'm referring to
@Repository
@EntityManagerConfig( ... )
public abstract class SimpleRepository extends
AbstractEntityRepositorySimple, Long {
@Transactional
public ListSimple findByName(String name) {
String query = select s from Simple s where s.name = :name;
return entityManager().createQuery(query, Simple.class)
.setParameter(name, name)
.setLockMode(READ) // needs a tx
.getResultList();
}
...
currently this triggers neither the InvocationHandler nor the interceptor
(and if it does then the interceptor should deal with @EntityManagerConfig).
Another pragmatic variant could be to add something like that to
AbstractEntityRepository:
public abstract V transactional(CallableV callable)
which would then run again in the InvocationHandler, but seems like a
rather clunky workaround compared to the version above.
On Thu, Feb 20, 2014 at 4:45 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
it is since you use the handled (interface for instance) as metadata, no?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-20 16:32 GMT+01:00 Thomas Hug thomas@gmail.com:
The more conceptual issue in this concrete case is that @Transactional
isn't really independent from the handler class (namely EntityManager
resolution). But I guess that's something we can deal with.
So given the release time frame - anything we can do here or shall we
park
this case for now?
On Thu, Feb 20, 2014 at 2:17 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
I think so too
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-20 13:05 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com
:
imo we just need to support interceptors.
regards,
gerhard
2014-02-20 12:20 GMT+01:00 Thomas Hug thomas@gmail.com:
While looking at transactional repositories, I realized that
PartialBeans
invoke concrete methods directly. That doesn't give the invocation
handler
a chance to hook into the call (and in the data case to control the
tx).
What about creating an additional handler interface which also
allows to
pass in the proceeding method? Or is there a better alternative?
Re: PartialBeans and concrete methods
While you can use @tx in you custome methods whatever solution is used is
fine (even a temp hack). Api just shouldnt change imo
Le 20 févr. 2014 20:39, Gerhard Petracek gerhard.petra...@gmail.com a
écrit :
+1 for #3
regards,
gerhard
2014-02-20 20:35 GMT+01:00 Thomas Hug thomas@gmail.com:
Yeah aligning the resolution mechanism would certainly help. @EMC with
EntityManagerResolver was actually something introduced in the import to
align it with the JSF module (MessageResolver) so we might consider
adapting @Tx.
Anyway:
1) Is making PartialBeans interceptor-ready something feasible for the
release
2) or do we go with the quick workaround on AbstractEntityRepository
(that
will probably not hurt too much once interceptors work)
3) or just leave tx on concrete repository methods for now until we have
1)
in a later release
On Thu, Feb 20, 2014 at 5:39 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
Ok got, that's because @Tx and@EMC doesn't use same syntax. If both
uses qualifier it would work
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-20 17:15 GMT+01:00 Thomas Hug thomas@gmail.com:
Basically that's the case I'm referring to
@Repository
@EntityManagerConfig( ... )
public abstract class SimpleRepository extends
AbstractEntityRepositorySimple, Long {
@Transactional
public ListSimple findByName(String name) {
String query = select s from Simple s where s.name =
:name;
return entityManager().createQuery(query, Simple.class)
.setParameter(name, name)
.setLockMode(READ) // needs a tx
.getResultList();
}
...
currently this triggers neither the InvocationHandler nor the
interceptor
(and if it does then the interceptor should deal with
@EntityManagerConfig).
Another pragmatic variant could be to add something like that to
AbstractEntityRepository:
public abstract V transactional(CallableV callable)
which would then run again in the InvocationHandler, but seems like a
rather clunky workaround compared to the version above.
On Thu, Feb 20, 2014 at 4:45 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
it is since you use the handled (interface for instance) as
metadata,
no?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-20 16:32 GMT+01:00 Thomas Hug thomas@gmail.com:
The more conceptual issue in this concrete case is that
@Transactional
isn't really independent from the handler class (namely
EntityManager
resolution). But I guess that's something we can deal with.
So given the release time frame - anything we can do here or shall
we
park
this case for now?
On Thu, Feb 20, 2014 at 2:17 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
I think so too
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-20 13:05 GMT+01:00 Gerhard Petracek
gerhard.petra...@gmail.com
:
imo we just need to support interceptors.
regards,
gerhard
2014-02-20 12:20 GMT+01:00 Thomas Hug thomas@gmail.com:
While looking at transactional repositories, I realized that
PartialBeans
invoke concrete methods directly. That doesn't give the
invocation
handler
a chance to hook into the call (and in the data case to
control
the
tx).
What about creating an additional handler interface which also
allows to
pass in the proceeding method? Or is there a better
alternative?
Re: Servlet Module - Do we really need @Web?
That's would be ambiguous with JavaEE 6 Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 22:12 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: What about reusing javax.annotation.Priority? 2014-02-23 22:02 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com: it's just a stereotype to get a better tool-support... @Advanced is also a qualifier (at least in codi). however, we need ordinal or we add @InvocationOrder as it was in codi. once we do that, we break the consistency in that area. 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-23 21:41 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : Another problem is that @web is a qualifier and @JsfPhaseListener is a stereotype and not a qualifier. So if we would change it, we must use different annotations. Right? IMO @Inject @DeltaSpike ServletContext context; would be great as it's just like a namespace. For the @JsfPhaseListener, something like @Advanced would be better. 2014-02-18 11:16 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : IMO it's actually more expressive than any other names. Maybe @DeltaSpikeManaged would be more impressive... +1 @DeltaSpike then, before keeping the old redudant/ugly qualifiers. 2014-02-18 10:51 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: +1 kind of tradeoff Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-18 10:46 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com : we haven't seen a nice name so far - i would keep what we have right now (it's redundant, but at least a bit more expressive). regards, gerhard 2014-02-18 10:20 GMT+01:00 Mark Struberg strub...@yahoo.de: I do agree on @Managed not being very expressive. Think about the @ManagedBean disaster in JavaEE itself. 'Managed' is in the same ballpark like 'Class' or 'Object'. Managed by whom and what? In that case I'd rather go with @DeltaSpike or keep @Web... But I do not care that much about names... LieGrue, strub On Tuesday, 18 February 2014, 10:15, Romain Manni-Bucau rmannibu...@gmail.com wrote: @Gerhard: yeah but managed is not expressive, doesnt give the origin + is quite standard for jmxso i would avoid it. That said it doesnt bring any feature so i dont want to fight for a name. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-18 10:12 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com: @romain: you will always have same/similar terms in different areas (see e.g. message). regards, gerhard
Re: Servlet Module - Do we really need @Web?
I'd prefer something more explicit. Just changing the package would be enough for me Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 22:17 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: Hmm... We could clone it for JEE6 support and handle both annotations for backward compatibility. Maybe we could also use it for other features (or later..) 2014-02-23 22:14 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: That's would be ambiguous with JavaEE 6 Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 22:12 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : What about reusing javax.annotation.Priority? 2014-02-23 22:02 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com : it's just a stereotype to get a better tool-support... @Advanced is also a qualifier (at least in codi). however, we need ordinal or we add @InvocationOrder as it was in codi. once we do that, we break the consistency in that area. 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-23 21:41 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : Another problem is that @web is a qualifier and @JsfPhaseListener is a stereotype and not a qualifier. So if we would change it, we must use different annotations. Right? IMO @Inject @DeltaSpike ServletContext context; would be great as it's just like a namespace. For the @JsfPhaseListener, something like @Advanced would be better. 2014-02-18 11:16 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : IMO it's actually more expressive than any other names. Maybe @DeltaSpikeManaged would be more impressive... +1 @DeltaSpike then, before keeping the old redudant/ugly qualifiers. 2014-02-18 10:51 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: +1 kind of tradeoff Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-18 10:46 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com : we haven't seen a nice name so far - i would keep what we have right now (it's redundant, but at least a bit more expressive). regards, gerhard 2014-02-18 10:20 GMT+01:00 Mark Struberg strub...@yahoo.de: I do agree on @Managed not being very expressive. Think about the @ManagedBean disaster in JavaEE itself. 'Managed' is in the same ballpark like 'Class' or 'Object'. Managed by whom and what? In that case I'd rather go with @DeltaSpike or keep @Web... But I do not care that much about names... LieGrue, strub On Tuesday, 18 February 2014, 10:15, Romain Manni-Bucau rmannibu...@gmail.com wrote: @Gerhard: yeah but managed is not expressive, doesnt give the origin + is quite standard for jmxso i would avoid it. That said it doesnt bring any feature so i dont want to fight for a name. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-18 10:12 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com: @romain: you will always have same/similar terms in different areas (see e.g. message). regards, gerhard
Re: Servlet Module - Do we really need @Web?
using javax.* from deltaspike is quite ambiguous: is it a DS behavior or a spec one? I'm no opposed Priority but in org.apache.deltaspile...Priority Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 22:34 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: Could you explain this? I can't follow you. 2014-02-23 22:23 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: I'd prefer something more explicit. Just changing the package would be enough for me Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 22:17 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : Hmm... We could clone it for JEE6 support and handle both annotations for backward compatibility. Maybe we could also use it for other features (or later..) 2014-02-23 22:14 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: That's would be ambiguous with JavaEE 6 Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 22:12 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : What about reusing javax.annotation.Priority? 2014-02-23 22:02 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com : it's just a stereotype to get a better tool-support... @Advanced is also a qualifier (at least in codi). however, we need ordinal or we add @InvocationOrder as it was in codi. once we do that, we break the consistency in that area. 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-23 21:41 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : Another problem is that @web is a qualifier and @JsfPhaseListener is a stereotype and not a qualifier. So if we would change it, we must use different annotations. Right? IMO @Inject @DeltaSpike ServletContext context; would be great as it's just like a namespace. For the @JsfPhaseListener, something like @Advanced would be better. 2014-02-18 11:16 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : IMO it's actually more expressive than any other names. Maybe @DeltaSpikeManaged would be more impressive... +1 @DeltaSpike then, before keeping the old redudant/ugly qualifiers. 2014-02-18 10:51 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: +1 kind of tradeoff Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-18 10:46 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com : we haven't seen a nice name so far - i would keep what we have right now (it's redundant, but at least a bit more expressive). regards, gerhard 2014-02-18 10:20 GMT+01:00 Mark Struberg strub...@yahoo.de: I do agree on @Managed not being very expressive. Think about the @ManagedBean disaster in JavaEE itself. 'Managed' is in the same ballpark like 'Class' or 'Object'. Managed by whom and what? In that case I'd rather go with @DeltaSpike or keep @Web... But I do not care that much about names... LieGrue, strub On Tuesday, 18 February 2014, 10:15, Romain Manni-Bucau rmannibu...@gmail.com wrote: @Gerhard: yeah but managed is not expressive, doesnt give the origin + is quite standard for jmxso i would avoid it. That said it doesnt bring any feature so i dont want to fight for a name. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-18 10:12 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com: @romain: you will always have same/similar terms in different areas (see e.g. message). regards, gerhard
Re: Servlet Module - Do we really need @Web?
wonder if 2 is really a *public* question once 1 is decided Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 23:26 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: Shoudln't we do 2 polls? 1) Should we introduce a global qualifier instead @web? If yes, which name? 2) Alternative for JsfPhaseListener? - keep it as it is - just rename it as it redudant - use the global qualifier + introduce a second annotation for setting the ordinal 2014-02-23 23:21 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: maybe we can do a public poll? 1) Keep it like it 2) @DeltaSpike 3) ordinal() 4) other? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 23:18 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : If it was agreed, we should leave @JsfPhaseListener as it is... Sorry if i'm a bit annoying but... I still like the idea of a global qualifier instead @Web. As Romain said, it would see it as an namespace - @Inject @DeltaSpike ServletContext context looks good. 2014-02-23 23:01 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com : at other parts you specify an artifact with an interface, annotation,... and at the same point (if possible) you are able to specify the ordinal (without an extra annotation). that's easier for users and therefore we agreed on it in the beginning. 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-23 22:48 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : which consistency gerhard? 2014-02-23 22:45 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com : independent of the name, we would break the consistency. 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-23 22:40 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: using javax.* from deltaspike is quite ambiguous: is it a DS behavior or a spec one? I'm no opposed Priority but in org.apache.deltaspile...Priority Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 22:34 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : Could you explain this? I can't follow you. 2014-02-23 22:23 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com : I'd prefer something more explicit. Just changing the package would be enough for me Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 22:17 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : Hmm... We could clone it for JEE6 support and handle both annotations for backward compatibility. Maybe we could also use it for other features (or later..) 2014-02-23 22:14 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com : That's would be ambiguous with JavaEE 6 Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 22:12 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : What about reusing javax.annotation.Priority? 2014-02-23 22:02 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com : it's just a stereotype to get a better tool-support... @Advanced is also a qualifier (at least in codi). however, we need ordinal or we add @InvocationOrder as it was in codi. once we do that, we break the consistency in that area. 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-23 21:41 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : Another problem is that @web
Re: Servlet Module - Do we really need @Web?
maybe we can do a public poll? 1) Keep it like it 2) @DeltaSpike 3) ordinal() 4) other? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 23:18 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: If it was agreed, we should leave @JsfPhaseListener as it is... Sorry if i'm a bit annoying but... I still like the idea of a global qualifier instead @Web. As Romain said, it would see it as an namespace - @Inject @DeltaSpike ServletContext context looks good. 2014-02-23 23:01 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com: at other parts you specify an artifact with an interface, annotation,... and at the same point (if possible) you are able to specify the ordinal (without an extra annotation). that's easier for users and therefore we agreed on it in the beginning. 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-23 22:48 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : which consistency gerhard? 2014-02-23 22:45 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com : independent of the name, we would break the consistency. 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-23 22:40 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: using javax.* from deltaspike is quite ambiguous: is it a DS behavior or a spec one? I'm no opposed Priority but in org.apache.deltaspile...Priority Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 22:34 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : Could you explain this? I can't follow you. 2014-02-23 22:23 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com : I'd prefer something more explicit. Just changing the package would be enough for me Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 22:17 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : Hmm... We could clone it for JEE6 support and handle both annotations for backward compatibility. Maybe we could also use it for other features (or later..) 2014-02-23 22:14 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com : That's would be ambiguous with JavaEE 6 Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 22:12 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : What about reusing javax.annotation.Priority? 2014-02-23 22:02 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com : it's just a stereotype to get a better tool-support... @Advanced is also a qualifier (at least in codi). however, we need ordinal or we add @InvocationOrder as it was in codi. once we do that, we break the consistency in that area. 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-23 21:41 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : Another problem is that @web is a qualifier and @JsfPhaseListener is a stereotype and not a qualifier. So if we would change it, we must use different annotations. Right? IMO @Inject @DeltaSpike ServletContext context; would be great as it's just like a namespace. For the @JsfPhaseListener, something like @Advanced would be better. 2014-02-18 11:16 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : IMO it's actually more expressive than any other names. Maybe @DeltaSpikeManaged would be more impressive... +1 @DeltaSpike then, before keeping the old redudant/ugly qualifiers. 2014-02-18 10:51 GMT+01:00 Romain Manni-Bucau
Re: Servlet Module - Do we really need @Web?
+1 Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 23:31 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: Hmm. So i would just start with 1) and we can continue our discussion after the poll. Ok? 2014-02-23 23:28 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: wonder if 2 is really a *public* question once 1 is decided Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 23:26 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : Shoudln't we do 2 polls? 1) Should we introduce a global qualifier instead @web? If yes, which name? 2) Alternative for JsfPhaseListener? - keep it as it is - just rename it as it redudant - use the global qualifier + introduce a second annotation for setting the ordinal 2014-02-23 23:21 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: maybe we can do a public poll? 1) Keep it like it 2) @DeltaSpike 3) ordinal() 4) other? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 23:18 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : If it was agreed, we should leave @JsfPhaseListener as it is... Sorry if i'm a bit annoying but... I still like the idea of a global qualifier instead @Web. As Romain said, it would see it as an namespace - @Inject @DeltaSpike ServletContext context looks good. 2014-02-23 23:01 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com : at other parts you specify an artifact with an interface, annotation,... and at the same point (if possible) you are able to specify the ordinal (without an extra annotation). that's easier for users and therefore we agreed on it in the beginning. 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-23 22:48 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : which consistency gerhard? 2014-02-23 22:45 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com : independent of the name, we would break the consistency. 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-23 22:40 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com: using javax.* from deltaspike is quite ambiguous: is it a DS behavior or a spec one? I'm no opposed Priority but in org.apache.deltaspile...Priority Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 22:34 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : Could you explain this? I can't follow you. 2014-02-23 22:23 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com : I'd prefer something more explicit. Just changing the package would be enough for me Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 22:17 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : Hmm... We could clone it for JEE6 support and handle both annotations for backward compatibility. Maybe we could also use it for other features (or later..) 2014-02-23 22:14 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com : That's would be ambiguous with JavaEE 6 Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-23 22:12 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com : What about reusing javax.annotation.Priority? 2014-02-23 22:02 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com : it's just a stereotype to get a better tool-support... @Advanced is also a qualifier (at least in codi
Re: [VOTE] Replace @Web with a common DeltaSpike qualifier
seems we agree on DeltaSpike, no? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-24 17:24 GMT+01:00 John D. Ament john.d.am...@gmail.com: I agree with the use of the name (@DeltaSpike) but to me this vote is not useful unless we actually know what the proposed new name is. On Mon, Feb 24, 2014 at 11:03 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: if it is global it should be the name of project 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-24 16:54 GMT+01:00 John D. Ament john.d.am...@gmail.com: I'm inclined to -1 (veto) this as it's not clear from the vote what the new qualifier is. On Mon, Feb 24, 2014 at 10:41 AM, Cody Lerum cody.le...@gmail.com wrote: +1 To be clear it is @DeltaSpike (capital D capital S) -C On Mon, Feb 24, 2014 at 5:16 AM, Mark Struberg strub...@yahoo.de wrote: +1 The Qualifier itself should sit in core-api. LieGrue, strub On Monday, 24 February 2014, 11:03, Antoine Sabot-Durand anto...@sabot-durand.net wrote: +1 for @Deltaspike qualifier : it gives a solution to manage co-existence of DS feature and future CDI standardized DS features. Le 24 févr. 2014 à 10:16, Romain Manni-Bucau rmannibu...@gmail.com a écrit : +1 as well for a global qualifier @DeltaSPike Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-24 9:52 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: +1 for @DeltaSpike - @Inject @DeltaSpike ServletContext 2014-02-24 9:52 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: Hi, based on the discusstion in Servlet Module - Do we really need @Web?, I'd like to call a vote. The idea is to replace @Web with a common qualifier because @Web is redudant: @Inject @Web ServletContext. We could also reuse this qualifier for other features in the future. 1) Should we replace it? 2) What about the name? @DeltaSpike? Regards, Thomas
Re: [VOTE] Replace @Web with a common DeltaSpike qualifier
yes but until now everybody seems ok if we have multiple proposal we can see if we do another vote or if some change their vote, no? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-24 21:00 GMT+01:00 John D. Ament john.d.am...@gmail.com: As per OP email, it's only a proposed value. On Mon, Feb 24, 2014 at 11:29 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: seems we agree on DeltaSpike, no? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-24 17:24 GMT+01:00 John D. Ament john.d.am...@gmail.com: I agree with the use of the name (@DeltaSpike) but to me this vote is not useful unless we actually know what the proposed new name is. On Mon, Feb 24, 2014 at 11:03 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: if it is global it should be the name of project 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-24 16:54 GMT+01:00 John D. Ament john.d.am...@gmail.com: I'm inclined to -1 (veto) this as it's not clear from the vote what the new qualifier is. On Mon, Feb 24, 2014 at 10:41 AM, Cody Lerum cody.le...@gmail.com wrote: +1 To be clear it is @DeltaSpike (capital D capital S) -C On Mon, Feb 24, 2014 at 5:16 AM, Mark Struberg strub...@yahoo.de wrote: +1 The Qualifier itself should sit in core-api. LieGrue, strub On Monday, 24 February 2014, 11:03, Antoine Sabot-Durand anto...@sabot-durand.net wrote: +1 for @Deltaspike qualifier : it gives a solution to manage co-existence of DS feature and future CDI standardized DS features. Le 24 févr. 2014 à 10:16, Romain Manni-Bucau rmannibu...@gmail.com a écrit : +1 as well for a global qualifier @DeltaSPike Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-24 9:52 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: +1 for @DeltaSpike - @Inject @DeltaSpike ServletContext 2014-02-24 9:52 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: Hi, based on the discusstion in Servlet Module - Do we really need @Web?, I'd like to call a vote. The idea is to replace @Web with a common qualifier because @Web is redudant: @Inject @Web ServletContext. We could also reuse this qualifier for other features in the future. 1) Should we replace it? 2) What about the name? @DeltaSpike? Regards, Thomas
[jira] [Commented] (DELTASPIKE-420) Transactional repositories
[ https://issues.apache.org/jira/browse/DELTASPIKE-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13918201#comment-13918201 ] Romain Manni-Bucau commented on DELTASPIKE-420: --- That's a good point actually but in a real container (TomEE, Wildfly) a custom TransactionStrategy relying on transaction manager of the container is surely the best Transactional repositories -- Key: DELTASPIKE-420 URL: https://issues.apache.org/jira/browse/DELTASPIKE-420 Project: DeltaSpike Issue Type: New Feature Components: Data-Module Affects Versions: 0.5 Reporter: Harald Wellmann Assignee: Thomas Hug Attachments: DELTASPIKE-420_spi.patch It's nice to get semi-automatic repositories from DeltaSpike Data, but these repositories would be even more fun if they were transactional, not necessarily by default, but at least by simple configuration. Possible approaches: 1) Add @Transactional to an abstract repository class, i.e. javax.transaction.Transactional in Java EE 7, or org.apache.deltaspike.jpa.api.transaction.Transactional otherwise. Currently, this does not work due to DELTASPIKE-419. 2) Make it easy to override the @Repository binding or the query handler, to add transactional behaviour. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-537) test-utils jar should be added to deployed wars only if the test is a server test
[ https://issues.apache.org/jira/browse/DELTASPIKE-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved DELTASPIKE-537. --- Resolution: Fixed Fix Version/s: (was: 0.7) 0.6 test-utils jar should be added to deployed wars only if the test is a server test - Key: DELTASPIKE-537 URL: https://issues.apache.org/jira/browse/DELTASPIKE-537 Project: DeltaSpike Issue Type: Improvement Components: Tests Affects Versions: 0.5 Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 0.6 Using an archive appender can solve it properly without needing any hack or boolean to know if it is needed or not. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-537) test-utils jar should be added to deployed wars only if the test is a server test
[ https://issues.apache.org/jira/browse/DELTASPIKE-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved DELTASPIKE-537. --- Resolution: Fixed Done, thanks for the review. Side note: i didn't put header in SPI file cause we had several issues in tomee project with some libs not supporting it depending the jvm/java version/parser test-utils jar should be added to deployed wars only if the test is a server test - Key: DELTASPIKE-537 URL: https://issues.apache.org/jira/browse/DELTASPIKE-537 Project: DeltaSpike Issue Type: Improvement Components: Tests Affects Versions: 0.5 Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 0.6 Using an archive appender can solve it properly without needing any hack or boolean to know if it is needed or not. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: first steps for the next release
+1 Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-03-12 11:19 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: +1 thanks gerhard 2014-03-12 11:14 GMT+01:00 Gerhard Petracek gpetra...@apache.org: hi @ all, if there are no objections, i will start with the first steps for the next release (v0.6) by the end of this week. regards, gerhard
[jira] [Commented] (DELTASPIKE-552) Failed to Create Component Instance when using EntityRepository
[ https://issues.apache.org/jira/browse/DELTASPIKE-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13951216#comment-13951216 ] Romain Manni-Bucau commented on DELTASPIKE-552: --- FYI https://issues.jboss.org/browse/WFLY-2960 and https://issues.jboss.org/browse/WFLY-2936 Failed to Create Component Instance when using EntityRepository - Key: DELTASPIKE-552 URL: https://issues.apache.org/jira/browse/DELTASPIKE-552 Project: DeltaSpike Issue Type: Bug Components: Data-Module, JPA-Module Affects Versions: 0.6 Environment: Wildfly 8.0.0 Reporter: Akhbar Falafel Assignee: Thomas Hug I have code being deployed to Wildfly 8.0.0 that makes use of an EntityRepository from the Deltaspike Data Module, injected into a stateless EJB. When I attempt to call a method within the code, I get the following Exception: Caused by: java.lang.IllegalStateException: JBAS011048: Failed to construct component instance at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:162) at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:133) at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89) at org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:53) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final] ... 100 more ... Caused by: java.lang.IllegalStateException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction at org.jboss.as.ejb3.component.allowedmethods.AllowedMethodsInformation.realCheckPermission(AllowedMethodsInformation.java:138) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.ejb3.component.allowedmethods.AllowedMethodsInformation.checkAllowed(AllowedMethodsInformation.java:112) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.ejb3.subsystem.EJB3UserTransactionAccessControlService$1.authorizeAccess(EJB3UserTransactionAccessControlService.java:53) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.txn.service.UserTransactionAccessControlService.authorizeAccess(UserTransactionAccessControlService.java:83) at org.jboss.as.txn.service.UserTransactionBindingService$1.getReference(UserTransactionBindingService.java:71) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140) ... 198 more This code worked flawlessly on JBoss EAP 6.2, so it appears to be something specific to Wildfly. It has not been modified at all. However, if I remove references to my EntityRepository and re-run my code it works without issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-552) Failed to Create Component Instance when using EntityRepository
[
https://issues.apache.org/jira/browse/DELTASPIKE-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13954369#comment-13954369
]
Romain Manni-Bucau commented on DELTASPIKE-552:
---
Did you activate the alternative?
{code}
beans ...
alternatives
classfoo.bar.YourImpl/class
/alternatives
/beans
{code}
Failed to Create Component Instance when using EntityRepository
-
Key: DELTASPIKE-552
URL: https://issues.apache.org/jira/browse/DELTASPIKE-552
Project: DeltaSpike
Issue Type: Bug
Components: Data-Module, JPA-Module
Affects Versions: 0.6
Environment: Wildfly 8.0.0
Reporter: Akhbar Falafel
Assignee: Thomas Hug
I have code being deployed to Wildfly 8.0.0 that makes use of an
EntityRepository from the Deltaspike Data Module, injected into a stateless
EJB. When I attempt to call a method within the code, I get the following
Exception:
Caused by: java.lang.IllegalStateException: JBAS011048: Failed to construct
component instance
at
org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:162)
at
org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:133)
at
org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89)
at
org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:53)
[wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at
org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
[wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
... 100 more
...
Caused by: java.lang.IllegalStateException: JBAS014237: Only session and
message-driven beans with bean-managed transaction demarcation are allowed to
access UserTransaction
at
org.jboss.as.ejb3.component.allowedmethods.AllowedMethodsInformation.realCheckPermission(AllowedMethodsInformation.java:138)
[wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
at
org.jboss.as.ejb3.component.allowedmethods.AllowedMethodsInformation.checkAllowed(AllowedMethodsInformation.java:112)
[wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
at
org.jboss.as.ejb3.subsystem.EJB3UserTransactionAccessControlService$1.authorizeAccess(EJB3UserTransactionAccessControlService.java:53)
[wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
at
org.jboss.as.txn.service.UserTransactionAccessControlService.authorizeAccess(UserTransactionAccessControlService.java:83)
at
org.jboss.as.txn.service.UserTransactionBindingService$1.getReference(UserTransactionBindingService.java:71)
at
org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
... 198 more
This code worked flawlessly on JBoss EAP 6.2, so it appears to be something
specific to Wildfly. It has not been modified at all. However, if I remove
references to my EntityRepository and re-run my code it works without issue.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DELTASPIKE-552) Failed to Create Component Instance when using EntityRepository
[ https://issues.apache.org/jira/browse/DELTASPIKE-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13954380#comment-13954380 ] Romain Manni-Bucau commented on DELTASPIKE-552: --- foo.bar.YourImpl was a sample it needs to be the qualified name of CustomUserTransactionStrategy Failed to Create Component Instance when using EntityRepository - Key: DELTASPIKE-552 URL: https://issues.apache.org/jira/browse/DELTASPIKE-552 Project: DeltaSpike Issue Type: Bug Components: Data-Module, JPA-Module Affects Versions: 0.6 Environment: Wildfly 8.0.0 Reporter: Akhbar Falafel Assignee: Thomas Hug I have code being deployed to Wildfly 8.0.0 that makes use of an EntityRepository from the Deltaspike Data Module, injected into a stateless EJB. When I attempt to call a method within the code, I get the following Exception: Caused by: java.lang.IllegalStateException: JBAS011048: Failed to construct component instance at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:162) at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:133) at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89) at org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:53) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final] ... 100 more ... Caused by: java.lang.IllegalStateException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction at org.jboss.as.ejb3.component.allowedmethods.AllowedMethodsInformation.realCheckPermission(AllowedMethodsInformation.java:138) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.ejb3.component.allowedmethods.AllowedMethodsInformation.checkAllowed(AllowedMethodsInformation.java:112) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.ejb3.subsystem.EJB3UserTransactionAccessControlService$1.authorizeAccess(EJB3UserTransactionAccessControlService.java:53) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.txn.service.UserTransactionAccessControlService.authorizeAccess(UserTransactionAccessControlService.java:83) at org.jboss.as.txn.service.UserTransactionBindingService$1.getReference(UserTransactionBindingService.java:71) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140) ... 198 more This code worked flawlessly on JBoss EAP 6.2, so it appears to be something specific to Wildfly. It has not been modified at all. However, if I remove references to my EntityRepository and re-run my code it works without issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-552) Failed to Create Component Instance when using EntityRepository
[ https://issues.apache.org/jira/browse/DELTASPIKE-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13954388#comment-13954388 ] Romain Manni-Bucau commented on DELTASPIKE-552: --- hmm looks like a wildfly big. You can try @Specializes instead of @Alternative as workaround Failed to Create Component Instance when using EntityRepository - Key: DELTASPIKE-552 URL: https://issues.apache.org/jira/browse/DELTASPIKE-552 Project: DeltaSpike Issue Type: Bug Components: Data-Module, JPA-Module Affects Versions: 0.6 Environment: Wildfly 8.0.0 Reporter: Akhbar Falafel Assignee: Thomas Hug I have code being deployed to Wildfly 8.0.0 that makes use of an EntityRepository from the Deltaspike Data Module, injected into a stateless EJB. When I attempt to call a method within the code, I get the following Exception: Caused by: java.lang.IllegalStateException: JBAS011048: Failed to construct component instance at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:162) at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:133) at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89) at org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:53) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final] ... 100 more ... Caused by: java.lang.IllegalStateException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction at org.jboss.as.ejb3.component.allowedmethods.AllowedMethodsInformation.realCheckPermission(AllowedMethodsInformation.java:138) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.ejb3.component.allowedmethods.AllowedMethodsInformation.checkAllowed(AllowedMethodsInformation.java:112) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.ejb3.subsystem.EJB3UserTransactionAccessControlService$1.authorizeAccess(EJB3UserTransactionAccessControlService.java:53) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.txn.service.UserTransactionAccessControlService.authorizeAccess(UserTransactionAccessControlService.java:83) at org.jboss.as.txn.service.UserTransactionBindingService$1.getReference(UserTransactionBindingService.java:71) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140) ... 198 more This code worked flawlessly on JBoss EAP 6.2, so it appears to be something specific to Wildfly. It has not been modified at all. However, if I remove references to my EntityRepository and re-run my code it works without issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [DISCUSS] releases
+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
[jira] [Commented] (DELTASPIKE-558) OpenEJB-ContainerControl tests randomly lock up on Solaris
[
https://issues.apache.org/jira/browse/DELTASPIKE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958842#comment-13958842
]
Romain Manni-Bucau commented on DELTASPIKE-558:
---
Hi
when you say it hangs does it block completely or just block for a moment?
which kind of machine is it?
OpenEJB-ContainerControl tests randomly lock up on Solaris
--
Key: DELTASPIKE-558
URL: https://issues.apache.org/jira/browse/DELTASPIKE-558
Project: DeltaSpike
Issue Type: Bug
Components: CdiControl
Affects Versions: 0.6
Environment: Solaris 10/11
Java 1.6/1.8
Reporter: Ron Smeral
The tests for OpenEJB-ContainerControl often hang on Solaris.
Noticed on Solaris 10/11 with Java 1.6/1.8.
Output of jstack suggests that this might be an issue of the OpenEJB
container itself.
jstack output:
{noformat}
2014-04-03 08:07:18
Full thread dump Java HotSpot(TM) Server VM (24.51-b03 mixed mode):
Attach Listener daemon prio=3 tid=0x00db3400 nid=0xa8 waiting on condition
[0x]
java.lang.Thread.State: RUNNABLE
RetryTimer daemon prio=3 tid=0x00996000 nid=0x24 in Object.wait()
[0xb2eef000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead92c58 (a java.util.TaskQueue)
at java.lang.Object.wait(Object.java:503)
at java.util.TimerThread.mainLoop(Timer.java:526)
- locked 0xead92c58 (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:505)
Service Thread daemon prio=3 tid=0x00231c00 nid=0x22 runnable [0x]
java.lang.Thread.State: RUNNABLE
C2 CompilerThread1 daemon prio=3 tid=0x0023 nid=0x21 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
C2 CompilerThread0 daemon prio=3 tid=0x0022d800 nid=0x20 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
Signal Dispatcher daemon prio=3 tid=0x0022c000 nid=0x1f runnable
[0x]
java.lang.Thread.State: RUNNABLE
Finalizer daemon prio=3 tid=0x0021a800 nid=0x1e in Object.wait()
[0xb382f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead9ed68 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
- locked 0xead9ed68 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
Reference Handler daemon prio=3 tid=0x00214800 nid=0x1d in Object.wait()
[0xb38bf000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead93db8 (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:503)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
- locked 0xead93db8 (a java.lang.ref.Reference$Lock)
main prio=3 tid=0x00028c00 nid=0x2 waiting on condition [0xfdf4c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xead91ce0 (a
java.util.concurrent.Semaphore$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:472)
at org.apache.openejb.Core.clinit(Core.java:138)
at
org.apache.openejb.core.LocalInitialContext.clinit(LocalInitialContext.java:51)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at
org.apache.openejb.core.LocalInitialContextFactory.getLocalInitialContext(LocalInitialContextFactory.java:81)
at
org.apache.openejb.core.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:41)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
at javax.naming.InitialContext.init(InitialContext.java:242)
at javax.naming.InitialContext.init(InitialContext.java:216)
at
org.apache.deltaspike.cdise.openejb.OpenEjbContainerControl.boot(OpenEjbContainerControl.java:99)
- locked 0xead9f1f0
[jira] [Commented] (DELTASPIKE-558) OpenEJB-ContainerControl tests randomly lock up on Solaris
[
https://issues.apache.org/jira/browse/DELTASPIKE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958904#comment-13958904
]
Romain Manni-Bucau commented on DELTASPIKE-558:
---
can you try with openejb 4.6.0 we changed a bit this part since on som eOS it
was not working that well
OpenEJB-ContainerControl tests randomly lock up on Solaris
--
Key: DELTASPIKE-558
URL: https://issues.apache.org/jira/browse/DELTASPIKE-558
Project: DeltaSpike
Issue Type: Bug
Components: CdiControl
Affects Versions: 0.6
Environment: Solaris 10/11
Java 1.6/1.8
Reporter: Ron Smeral
The tests for OpenEJB-ContainerControl often hang on Solaris.
Noticed on Solaris 10/11 with Java 1.6/1.8.
Output of jstack suggests that this might be an issue of the OpenEJB
container itself.
jstack output:
{noformat}
2014-04-03 08:07:18
Full thread dump Java HotSpot(TM) Server VM (24.51-b03 mixed mode):
Attach Listener daemon prio=3 tid=0x00db3400 nid=0xa8 waiting on condition
[0x]
java.lang.Thread.State: RUNNABLE
RetryTimer daemon prio=3 tid=0x00996000 nid=0x24 in Object.wait()
[0xb2eef000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead92c58 (a java.util.TaskQueue)
at java.lang.Object.wait(Object.java:503)
at java.util.TimerThread.mainLoop(Timer.java:526)
- locked 0xead92c58 (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:505)
Service Thread daemon prio=3 tid=0x00231c00 nid=0x22 runnable [0x]
java.lang.Thread.State: RUNNABLE
C2 CompilerThread1 daemon prio=3 tid=0x0023 nid=0x21 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
C2 CompilerThread0 daemon prio=3 tid=0x0022d800 nid=0x20 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
Signal Dispatcher daemon prio=3 tid=0x0022c000 nid=0x1f runnable
[0x]
java.lang.Thread.State: RUNNABLE
Finalizer daemon prio=3 tid=0x0021a800 nid=0x1e in Object.wait()
[0xb382f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead9ed68 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
- locked 0xead9ed68 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
Reference Handler daemon prio=3 tid=0x00214800 nid=0x1d in Object.wait()
[0xb38bf000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead93db8 (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:503)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
- locked 0xead93db8 (a java.lang.ref.Reference$Lock)
main prio=3 tid=0x00028c00 nid=0x2 waiting on condition [0xfdf4c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xead91ce0 (a
java.util.concurrent.Semaphore$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:472)
at org.apache.openejb.Core.clinit(Core.java:138)
at
org.apache.openejb.core.LocalInitialContext.clinit(LocalInitialContext.java:51)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at
org.apache.openejb.core.LocalInitialContextFactory.getLocalInitialContext(LocalInitialContextFactory.java:81)
at
org.apache.openejb.core.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:41)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
at javax.naming.InitialContext.init(InitialContext.java:242)
at javax.naming.InitialContext.init(InitialContext.java:216)
at
org.apache.deltaspike.cdise.openejb.OpenEjbContainerControl.boot(OpenEjbContainerControl.java:99)
- locked 0xead9f1f0
[jira] [Commented] (DELTASPIKE-558) OpenEJB-ContainerControl tests randomly lock up on Solaris
[
https://issues.apache.org/jira/browse/DELTASPIKE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13959650#comment-13959650
]
Romain Manni-Bucau commented on DELTASPIKE-558:
---
yes sounds consistent we what we did.
wonder if ds shouldnt just make openejb provided since it shouldnt force a
version.
any opinion?
OpenEJB-ContainerControl tests randomly lock up on Solaris
--
Key: DELTASPIKE-558
URL: https://issues.apache.org/jira/browse/DELTASPIKE-558
Project: DeltaSpike
Issue Type: Bug
Components: CdiControl
Affects Versions: 0.6
Environment: Solaris 10/11
Java 1.6/1.8
Reporter: Ron Smeral
The tests for OpenEJB-ContainerControl often hang on Solaris.
Noticed on Solaris 10/11 with Java 1.6/1.8.
Output of jstack suggests that this might be an issue of the OpenEJB
container itself.
jstack output:
{noformat}
2014-04-03 08:07:18
Full thread dump Java HotSpot(TM) Server VM (24.51-b03 mixed mode):
Attach Listener daemon prio=3 tid=0x00db3400 nid=0xa8 waiting on condition
[0x]
java.lang.Thread.State: RUNNABLE
RetryTimer daemon prio=3 tid=0x00996000 nid=0x24 in Object.wait()
[0xb2eef000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead92c58 (a java.util.TaskQueue)
at java.lang.Object.wait(Object.java:503)
at java.util.TimerThread.mainLoop(Timer.java:526)
- locked 0xead92c58 (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:505)
Service Thread daemon prio=3 tid=0x00231c00 nid=0x22 runnable [0x]
java.lang.Thread.State: RUNNABLE
C2 CompilerThread1 daemon prio=3 tid=0x0023 nid=0x21 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
C2 CompilerThread0 daemon prio=3 tid=0x0022d800 nid=0x20 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
Signal Dispatcher daemon prio=3 tid=0x0022c000 nid=0x1f runnable
[0x]
java.lang.Thread.State: RUNNABLE
Finalizer daemon prio=3 tid=0x0021a800 nid=0x1e in Object.wait()
[0xb382f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead9ed68 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
- locked 0xead9ed68 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
Reference Handler daemon prio=3 tid=0x00214800 nid=0x1d in Object.wait()
[0xb38bf000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead93db8 (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:503)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
- locked 0xead93db8 (a java.lang.ref.Reference$Lock)
main prio=3 tid=0x00028c00 nid=0x2 waiting on condition [0xfdf4c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xead91ce0 (a
java.util.concurrent.Semaphore$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:472)
at org.apache.openejb.Core.clinit(Core.java:138)
at
org.apache.openejb.core.LocalInitialContext.clinit(LocalInitialContext.java:51)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at
org.apache.openejb.core.LocalInitialContextFactory.getLocalInitialContext(LocalInitialContextFactory.java:81)
at
org.apache.openejb.core.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:41)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
at javax.naming.InitialContext.init(InitialContext.java:242)
at javax.naming.InitialContext.init(InitialContext.java:216)
at
org.apache.deltaspike.cdise.openejb.OpenEjbContainerControl.boot(OpenEjbContainerControl.java:99)
- locked 0xead9f1f0
[jira] [Commented] (DELTASPIKE-577) Test-control: Add delegation of container boot
[
https://issues.apache.org/jira/browse/DELTASPIKE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974794#comment-13974794
]
Romain Manni-Bucau commented on DELTASPIKE-577:
---
No
-Dopenejb.configuration=/path/to/openejb.xml would work or just create a conf/
folder with openejb.xml inside.
You can also use system properties to declare resources
Test-control: Add delegation of container boot
--
Key: DELTASPIKE-577
URL: https://issues.apache.org/jira/browse/DELTASPIKE-577
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl, TestControl
Affects Versions: 0.7
Reporter: Karl Kildén
Priority: Minor
container.boot(); is used by Test-Control.
This is nice for simple tests with cdictrl-openejb but I think it would be
nice to have the possibility to target the boot(Map?, ? properties) that is
available for the openejb container. I want Test-Control to delegate to me so
I can boot myself.
I am thinking something like:
@TestControl(bootDelegate = PropertyAwareEjbBootDelegate.class)
public interface BootDelegate {
public void boot(CdiContainer cdiContainer);
}
That way tests could be way more dynamic and end users could boot the
container in any way they want.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DELTASPIKE-577) Test-control: Add delegation of container boot
[
https://issues.apache.org/jira/browse/DELTASPIKE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974833#comment-13974833
]
Romain Manni-Bucau commented on DELTASPIKE-577:
---
@Gerhard:
#1 owb should have (owb.properties)
#2 agree
#3 doesn't change the fact you *need* to start/stop by class otherwise you are
broken if you dont use it for all tests which is pretty sure today
#4 ok
The point for me is either we integrate it with boot(Map) or we drop boot(Map)
from the API but we need to stay consistent everywhere IMHO.
Test-control: Add delegation of container boot
--
Key: DELTASPIKE-577
URL: https://issues.apache.org/jira/browse/DELTASPIKE-577
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl, TestControl
Affects Versions: 0.7
Reporter: Karl Kildén
Priority: Minor
container.boot(); is used by Test-Control.
This is nice for simple tests with cdictrl-openejb but I think it would be
nice to have the possibility to target the boot(Map?, ? properties) that is
available for the openejb container. I want Test-Control to delegate to me so
I can boot myself.
I am thinking something like:
@TestControl(bootDelegate = PropertyAwareEjbBootDelegate.class)
public interface BootDelegate {
public void boot(CdiContainer cdiContainer);
}
That way tests could be way more dynamic and end users could boot the
container in any way they want.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (DELTASPIKE-577) Test-control: Add delegation of container boot
[
https://issues.apache.org/jira/browse/DELTASPIKE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau reassigned DELTASPIKE-577:
-
Assignee: Romain Manni-Bucau
Test-control: Add delegation of container boot
--
Key: DELTASPIKE-577
URL: https://issues.apache.org/jira/browse/DELTASPIKE-577
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl, TestControl
Affects Versions: 0.7
Reporter: Karl Kildén
Assignee: Romain Manni-Bucau
Priority: Minor
container.boot(); is used by Test-Control.
This is nice for simple tests with cdictrl-openejb but I think it would be
nice to have the possibility to target the boot(Map?, ? properties) that is
available for the openejb container. I want Test-Control to delegate to me so
I can boot myself.
I am thinking something like:
@TestControl(bootDelegate = PropertyAwareEjbBootDelegate.class)
public interface BootDelegate {
public void boot(CdiContainer cdiContainer);
}
That way tests could be way more dynamic and end users could boot the
container in any way they want.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DELTASPIKE-577) Test-control: Add delegation of container boot
[
https://issues.apache.org/jira/browse/DELTASPIKE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974852#comment-13974852
]
Romain Manni-Bucau commented on DELTASPIKE-577:
---
well it is portable but values are not.
I'm +1 to remove it btw if we don't integrate it with cdi runner. Just make it
highly inconsistent for me.
For me cdi runner should just be a CdiRule to help to handle scopes. Boot is
generally
Test-control: Add delegation of container boot
--
Key: DELTASPIKE-577
URL: https://issues.apache.org/jira/browse/DELTASPIKE-577
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl, TestControl
Affects Versions: 0.7
Reporter: Karl Kildén
Priority: Minor
container.boot(); is used by Test-Control.
This is nice for simple tests with cdictrl-openejb but I think it would be
nice to have the possibility to target the boot(Map?, ? properties) that is
available for the openejb container. I want Test-Control to delegate to me so
I can boot myself.
I am thinking something like:
@TestControl(bootDelegate = PropertyAwareEjbBootDelegate.class)
public interface BootDelegate {
public void boot(CdiContainer cdiContainer);
}
That way tests could be way more dynamic and end users could boot the
container in any way they want.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (DELTASPIKE-577) Test-control: Add delegation of container boot
[
https://issues.apache.org/jira/browse/DELTASPIKE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974852#comment-13974852
]
Romain Manni-Bucau edited comment on DELTASPIKE-577 at 4/19/14 1:11 PM:
well it is portable but values are not.
I'm +1 to remove it btw if we don't integrate it with cdi runner. Just make it
highly inconsistent for me.
For me cdi runner should just be a CdiRule to help to handle scopes. Boot is
generally provided by impl with custom runner/rule
was (Author: romain.manni-bucau):
well it is portable but values are not.
I'm +1 to remove it btw if we don't integrate it with cdi runner. Just make it
highly inconsistent for me.
For me cdi runner should just be a CdiRule to help to handle scopes. Boot is
generally
Test-control: Add delegation of container boot
--
Key: DELTASPIKE-577
URL: https://issues.apache.org/jira/browse/DELTASPIKE-577
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl, TestControl
Affects Versions: 0.7
Reporter: Karl Kildén
Assignee: Romain Manni-Bucau
Priority: Minor
container.boot(); is used by Test-Control.
This is nice for simple tests with cdictrl-openejb but I think it would be
nice to have the possibility to target the boot(Map?, ? properties) that is
available for the openejb container. I want Test-Control to delegate to me so
I can boot myself.
I am thinking something like:
@TestControl(bootDelegate = PropertyAwareEjbBootDelegate.class)
public interface BootDelegate {
public void boot(CdiContainer cdiContainer);
}
That way tests could be way more dynamic and end users could boot the
container in any way they want.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (DELTASPIKE-577) Test-control: Add delegation of container boot
[
https://issues.apache.org/jira/browse/DELTASPIKE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated DELTASPIKE-577:
--
Assignee: (was: Romain Manni-Bucau)
Test-control: Add delegation of container boot
--
Key: DELTASPIKE-577
URL: https://issues.apache.org/jira/browse/DELTASPIKE-577
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl, TestControl
Affects Versions: 0.7
Reporter: Karl Kildén
Priority: Minor
container.boot(); is used by Test-Control.
This is nice for simple tests with cdictrl-openejb but I think it would be
nice to have the possibility to target the boot(Map?, ? properties) that is
available for the openejb container. I want Test-Control to delegate to me so
I can boot myself.
I am thinking something like:
@TestControl(bootDelegate = PropertyAwareEjbBootDelegate.class)
public interface BootDelegate {
public void boot(CdiContainer cdiContainer);
}
That way tests could be way more dynamic and end users could boot the
container in any way they want.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DELTASPIKE-577) Test-control: Add delegation of container boot
[
https://issues.apache.org/jira/browse/DELTASPIKE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975073#comment-13975073
]
Romain Manni-Bucau commented on DELTASPIKE-577:
---
${openejb.home}/conf. Depend surefire config but by default:
${project.basedir}/conf
Note: when ignored you have in logs:
{code}
Cannot find the configuration file [conf/openejb.xml]. Will attempt to create
one for the beans deployed.
{code}
and home is logged too:
{code}
INFO - openejb.home = /xxx/yyy
{code}
Test-control: Add delegation of container boot
--
Key: DELTASPIKE-577
URL: https://issues.apache.org/jira/browse/DELTASPIKE-577
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl, TestControl
Affects Versions: 0.7
Reporter: Karl Kildén
Priority: Minor
container.boot(); is used by Test-Control.
This is nice for simple tests with cdictrl-openejb but I think it would be
nice to have the possibility to target the boot(Map?, ? properties) that is
available for the openejb container. I want Test-Control to delegate to me so
I can boot myself.
I am thinking something like:
@TestControl(bootDelegate = PropertyAwareEjbBootDelegate.class)
public interface BootDelegate {
public void boot(CdiContainer cdiContainer);
}
That way tests could be way more dynamic and end users could boot the
container in any way they want.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (DELTASPIKE-577) Test-control: Add delegation of container boot
[
https://issues.apache.org/jira/browse/DELTASPIKE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975073#comment-13975073
]
Romain Manni-Bucau edited comment on DELTASPIKE-577 at 4/20/14 7:38 AM:
{code}
${openejb.home}/conf
{code}
Depend surefire config but by default:
{code}
${project.basedir}/conf
{code}
Note: when ignored you have in logs:
{code}
Cannot find the configuration file [conf/openejb.xml]. Will attempt to create
one for the beans deployed.
{code}
and home is logged too:
{code}
INFO - openejb.home = /xxx/yyy
{code}
was (Author: romain.manni-bucau):
${openejb.home}/conf. Depend surefire config but by default:
${project.basedir}/conf
Note: when ignored you have in logs:
{code}
Cannot find the configuration file [conf/openejb.xml]. Will attempt to create
one for the beans deployed.
{code}
and home is logged too:
{code}
INFO - openejb.home = /xxx/yyy
{code}
Test-control: Add delegation of container boot
--
Key: DELTASPIKE-577
URL: https://issues.apache.org/jira/browse/DELTASPIKE-577
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl, TestControl
Affects Versions: 0.7
Reporter: Karl Kildén
Priority: Minor
container.boot(); is used by Test-Control.
This is nice for simple tests with cdictrl-openejb but I think it would be
nice to have the possibility to target the boot(Map?, ? properties) that is
available for the openejb container. I want Test-Control to delegate to me so
I can boot myself.
I am thinking something like:
@TestControl(bootDelegate = PropertyAwareEjbBootDelegate.class)
public interface BootDelegate {
public void boot(CdiContainer cdiContainer);
}
That way tests could be way more dynamic and end users could boot the
container in any way they want.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DELTASPIKE-577) Test-control: Add delegation of container boot
[
https://issues.apache.org/jira/browse/DELTASPIKE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975106#comment-13975106
]
Romain Manni-Bucau commented on DELTASPIKE-577:
---
wherever it is, it should be before the container is started
Test-control: Add delegation of container boot
--
Key: DELTASPIKE-577
URL: https://issues.apache.org/jira/browse/DELTASPIKE-577
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl, TestControl
Affects Versions: 0.7
Reporter: Karl Kildén
Priority: Minor
container.boot(); is used by Test-Control.
This is nice for simple tests with cdictrl-openejb but I think it would be
nice to have the possibility to target the boot(Map?, ? properties) that is
available for the openejb container. I want Test-Control to delegate to me so
I can boot myself.
I am thinking something like:
@TestControl(bootDelegate = PropertyAwareEjbBootDelegate.class)
public interface BootDelegate {
public void boot(CdiContainer cdiContainer);
}
That way tests could be way more dynamic and end users could boot the
container in any way they want.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DELTASPIKE-580) @InvocationMonitored
[ https://issues.apache.org/jira/browse/DELTASPIKE-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975171#comment-13975171 ] Romain Manni-Bucau commented on DELTASPIKE-580: --- Just for memories we can investigate later the integration ith sirona which has dynamic interception and advanced monitoring. Event feature is interesting btw. @InvocationMonitored Key: DELTASPIKE-580 URL: https://issues.apache.org/jira/browse/DELTASPIKE-580 Project: DeltaSpike Issue Type: New Feature Components: Core Reporter: Gerhard Petracek use-cases to support: - exception monitoring - performance monitoring (via execution time) - auditing (with or without parameter values) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-404) BeanManagerProvider leaks in case of undeploy/redeploy
[ https://issues.apache.org/jira/browse/DELTASPIKE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975625#comment-13975625 ] Romain Manni-Bucau commented on DELTASPIKE-404: --- the issue is it is broken by default then excepted if we detect the container automatically BeanManagerProvider leaks in case of undeploy/redeploy -- Key: DELTASPIKE-404 URL: https://issues.apache.org/jira/browse/DELTASPIKE-404 Project: DeltaSpike Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Gerhard Petracek Attachments: patch.diff -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (DELTASPIKE-404) BeanManagerProvider leaks in case of undeploy/redeploy
[ https://issues.apache.org/jira/browse/DELTASPIKE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975625#comment-13975625 ] Romain Manni-Bucau edited comment on DELTASPIKE-404 at 4/21/14 3:19 PM: the issue is it is broken by default then excepted if we detect the container automatically edit: not sure about others but tomee doesn't need a particular spi, it has its own event for that was (Author: romain.manni-bucau): the issue is it is broken by default then excepted if we detect the container automatically BeanManagerProvider leaks in case of undeploy/redeploy -- Key: DELTASPIKE-404 URL: https://issues.apache.org/jira/browse/DELTASPIKE-404 Project: DeltaSpike Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Gerhard Petracek Attachments: patch.diff -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE] Release of Apache DeltaSpike 0.7
+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-01 15:20 GMT+02:00 Thomas Andraschko andraschko.tho...@gmail.com: +1 2014-05-01 11:30 GMT+02:00 Gerhard Petracek gerhard.petra...@gmail.com: the dist was only generated locally. @john: i planned to create a ticket for you after the release. @rafael: -Pdistribution was used however, it isn't a blocker. regards, gerhard 2014-04-30 23:27 GMT+02:00 Rafael Benevides benevi...@redhat.com: maybe mvn release:perform also needs to have distribution profile activate also: mvn release:perform -Pdistribution Unfortunately I can't test it because of https://repository.apache.orgrights Em 30/04/14 18:19, Rafael Benevides escreveu: I just realized that too Em 30/04/14 18:04, John D. Ament escreveu: Hmm looks like dist still isn't included.. On Wed, Apr 30, 2014 at 4:22 PM, Gerhard Petracek gpetra...@apache.org 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
