Re: CDI Query import
sorry for this question, i didn't read other posts but why can't this be used on a plain servlet container? 2013/6/14 Karl Kildén karl.kil...@gmail.com Sorry if I missed out on some of the discussions about this but I think the lack of support for a plain servlet container is a big disappointment and a big loss of potential users in my immediate network. I really like the module though, can't wait etc. Thanks for doing it Cheers 2013/6/14 Thomas Hug thomas@gmail.com Hey all Any suggestions on how to proceed with the CDI Query import? So far we have - a proposal on the API [1] - a cleaned out branch depending on DS core and PartialBeans, running on the JBoss, TomEE and Glassfish profiles [2] - a reasonable amount of documentation [3] So what'd be next, anything still to adapt/missing? [1] https://cwiki.apache.org/DeltaSpike/repository-drafts.html [2] https://github.com/ctpconsulting/query/tree/dsimport [3] https://github.com/ctpconsulting/query/tree/dsimport#readme
Re: CDI Query import
Hi Thomas! I got that from the third link (temp docs) In order to use the DeltaSpike data module, you have to run your application in a Java EE container supporting at least the Java EE 6 Web Profile. Other configurations like running it inside Tomcat or even a Java SE application are possible but currently not supported. cheers 2013/6/14 Thomas Andraschko andraschko.tho...@gmail.com sorry for this question, i didn't read other posts but why can't this be used on a plain servlet container? 2013/6/14 Karl Kildén karl.kil...@gmail.com Sorry if I missed out on some of the discussions about this but I think the lack of support for a plain servlet container is a big disappointment and a big loss of potential users in my immediate network. I really like the module though, can't wait etc. Thanks for doing it Cheers 2013/6/14 Thomas Hug thomas@gmail.com Hey all Any suggestions on how to proceed with the CDI Query import? So far we have - a proposal on the API [1] - a cleaned out branch depending on DS core and PartialBeans, running on the JBoss, TomEE and Glassfish profiles [2] - a reasonable amount of documentation [3] So what'd be next, anything still to adapt/missing? [1] https://cwiki.apache.org/DeltaSpike/repository-drafts.html [2] https://github.com/ctpconsulting/query/tree/dsimport [3] https://github.com/ctpconsulting/query/tree/dsimport#readme
Re: CDI Query import
AFAICS it's just based on JPA and CDI, right? 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
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
Re: CDI Query import
+1 for a separated module. regards, gerhard 2013/6/14 Romain Manni-Bucau rmannibu...@gmail.com 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] [Comment Edited] (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=13683651#comment-13683651 ] Gerhard Petracek edited comment on DELTASPIKE-382 at 6/14/13 6:49 PM: -- i agree with romain and that also solves the cases you mentioned. or we don't log the config per default and just log it based on a system property (which is also easy enough to enable). i also know lots of people who agree with me, since we had this topic several times in environments of different security levels. you will never get an approach everybody agrees with, if you enable it per default. storing passwords as plain text and at the same time don't secure your logs and/or check them before exposing them is highly careless since projects usually use x libs as direct dependency or shipped in the server. if only one just logs all values of system-properties/jndi/... and you don't check the content of your logs before you expose them, you have the same issue. was (Author: gpetracek): i agree with romain and that also solves the cases you mentioned. or we don't log the config per default and just log it based on a system property (which is also easy enough to enable). i also know lots of people who agree with me, since we had this topic several times in environments of different security levels. you will never get an approach everybody agrees with, if you enable it per default. 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
