[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=13848739#comment-13848739
]
John D. Ament commented on DELTASPIKE-399:
--
I ended up calling the annotation `@ExternalResource` to avoid the name clash.
I also only added support for properties and `InputStream`s.
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.4#6159)
[jira] [Resolved] (DELTASPIKE-399) Incorporate Solder's ResourceLoader features into DeltaSpike
[
https://issues.apache.org/jira/browse/DELTASPIKE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament resolved DELTASPIKE-399.
--
Resolution: Fixed
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.4#6159)
[jira] [Created] (DELTASPIKE-467) Add default module.xml for jboss modules.
John D. Ament created DELTASPIKE-467: Summary: Add default module.xml for jboss modules. Key: DELTASPIKE-467 URL: https://issues.apache.org/jira/browse/DELTASPIKE-467 Project: DeltaSpike Issue Type: Improvement Affects Versions: 0.5 Reporter: John D. Ament Assignee: John D. Ament Fix For: 0.6 Add module.xml to the binary distribution, to make it easier to import to repackaged JBoss AS7+ distribution that includes DeltaSpike. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (DELTASPIKE-467) Add default module.xml for jboss modules.
[ https://issues.apache.org/jira/browse/DELTASPIKE-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament resolved DELTASPIKE-467. -- Resolution: Fixed Fixed Add default module.xml for jboss modules. - Key: DELTASPIKE-467 URL: https://issues.apache.org/jira/browse/DELTASPIKE-467 Project: DeltaSpike Issue Type: Improvement Affects Versions: 0.5 Reporter: John D. Ament Assignee: John D. Ament Fix For: 0.6 Add module.xml to the binary distribution, to make it easier to import to repackaged JBoss AS7+ distribution that includes DeltaSpike. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (DELTASPIKE-263) Generate binaries of DeltaSpike project
[ https://issues.apache.org/jira/browse/DELTASPIKE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament resolved DELTASPIKE-263. -- Resolution: Fixed Added a 'distribution' profile that when run will generate binaries in zip and tar.gz formats. Generate binaries of DeltaSpike project --- Key: DELTASPIKE-263 URL: https://issues.apache.org/jira/browse/DELTASPIKE-263 Project: DeltaSpike Issue Type: New Feature Affects Versions: 0.3-incubating Reporter: Charles Moulliard Assignee: John D. Ament Fix For: 0.6 -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (DELTASPIKE-193) Setup SecurityManager enabled CI build
[ https://issues.apache.org/jira/browse/DELTASPIKE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament updated DELTASPIKE-193: - Summary: Setup SecurityManager enabled CI build (was: Setup SecurityManagager enabled CI build) Setup SecurityManager enabled CI build -- Key: DELTASPIKE-193 URL: https://issues.apache.org/jira/browse/DELTASPIKE-193 Project: DeltaSpike Issue Type: Task Components: Build Affects Versions: 0.2-incubating Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.6 We currently don't have any CI environment which uses a SecurityManager. We should add such an environment to check whether DeltaSpike properly uses doPrivileged blocks where needed. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (DELTASPIKE-396) ShrinkWrapArchiveUtil creates jar files with random names
[ https://issues.apache.org/jira/browse/DELTASPIKE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13842704#comment-13842704 ] John D. Ament commented on DELTASPIKE-396: -- If you already made a patch for this, why not commit it? Are there other open issues? ShrinkWrapArchiveUtil creates jar files with random names - Key: DELTASPIKE-396 URL: https://issues.apache.org/jira/browse/DELTASPIKE-396 Project: DeltaSpike Issue Type: Improvement Components: Tests Affects Versions: 0.4 Reporter: Gerhard Petracek Assignee: Mark Struberg Fix For: 0.6 Attachments: DELTASPIKE-396.patch jar files which have only random names are more difficult to check (if deploymentExportPath is used) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DELTASPIKE-449) ExceptionHandler not invoked for AccessDeniedException
[ https://issues.apache.org/jira/browse/DELTASPIKE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13830827#comment-13830827 ] John D. Ament commented on DELTASPIKE-449: -- Great idea. Would be a cool feature for the security module had exception handling integration enabled. Interested in sending a pull request? ExceptionHandler not invoked for AccessDeniedException -- Key: DELTASPIKE-449 URL: https://issues.apache.org/jira/browse/DELTASPIKE-449 Project: DeltaSpike Issue Type: New Feature Components: Security-Module Affects Versions: 0.5 Environment: Glassfish 4 / Weld 2.0.4 Reporter: John Schneider When an org.apache.deltaspike.security.api.authorization.AccessDeniedException is thrown, a valid ExceptionHandler method is not invoked. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (DELTASPIKE-445) read ProjectStage also from a few other places
[ https://issues.apache.org/jira/browse/DELTASPIKE-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament reopened DELTASPIKE-445: -- RAT checks are currently failing on this change. Can you double check? read ProjectStage also from a few other places -- Key: DELTASPIKE-445 URL: https://issues.apache.org/jira/browse/DELTASPIKE-445 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 0.5 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.6 We currently only read the ProjectStage setting from org.apache.deltaspike.ProjectStage. We should also try to read the info from the other ususal suspects: - javax.faces.PROJECT_STAGE - faces.PROJECT_STAGE We have 2 options to do so: 1.) introduce a SPI and make it expandable. But I honestly doubt this is worth the hassle. 2.) Just add the other locations and iterate through them directly in the ProjectStageProducer. I honestly prefer 2. Not as perfectly as clean, but way easier and usually this i snothing a user will change anyway. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: repositories
Hibernate does something similar. They have their own internal transaction manager lookup classes for various platforms, and you can specify JNDI locations. We should probably have something like this in the transaction module. On Wed, Nov 20, 2013 at 9:29 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: BTW to make some code on 2): https://gist.github.com/rmannibucau/7564089 Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/11/20 Romain Manni-Bucau rmannibu...@gmail.com: Hi testing new mapping feature (really appreciated once SimpleQueryInOutMapperBase was added) I realized we still don't support @transactional on repos. What's blocking for it? Since we handle the impl we can add the transaction strategy handling. That said it rings 2 questions: 1) why don't we handle nested transactions? 2) why don't we have a TransactionStrategy backed by a transaction manager? 2') if 2) can't we support default locations like http://grepcode.com/file/repo1.maven.org/maven2/org.apache.openjpa/openjpa-all/2.1.0/org/apache/openjpa/ee/AutomaticManagedRuntime.java?av=f . This is great cause make it working with 0 config in a JavaEE server. wdyt? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau
Re: [DISCUSS] next release version? 0.6 or 1.0?
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
[jira] [Commented] (DELTASPIKE-419) Interceptors on partial beans
[ https://issues.apache.org/jira/browse/DELTASPIKE-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806095#comment-13806095 ] John D. Ament commented on DELTASPIKE-419: -- Harald, do you have an example to reproduce this? Interceptors on partial beans - Key: DELTASPIKE-419 URL: https://issues.apache.org/jira/browse/DELTASPIKE-419 Project: DeltaSpike Issue Type: New Feature Components: PartialBean Affects Versions: 0.5 Reporter: Harald Wellmann Partial beans should support interceptors. Currently, an interceptor binding on an abstract partial bean class has no effect at all, since all methods of the Javassist proxy class for the partial bean are final. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [Proposal] messages stored but not tied to JSF system.
We face this issue as well, but more generally how to handle messaging back to REST clients. For example, when we're not returning back a 200 OK we include some messages back for error handling to display to the GUI what happened. These could be complex objects with substitutions as well. To do this, all of our POJOs back to the client extend from a base class which can include these variables. It's then up to the client to figure out how to render these messages. What did you have in mind for consolidating? On Mon, Oct 21, 2013 at 10:05 AM, Rudy De Busscher rdebussc...@gmail.com wrote: All, With the JsfMessage interface, you can add messages to the FacesContext so that they are displayed on screen the next rendering. But what if your CDI beans are used within a JSF context AND a REST context. When processing the REST request, there is no facesContext available and exceptions occur. My proposal is to have, aside the JsfMessage interface, a similar one, something like BusinessMessage, that works exactly the same but which doesn't store the message in FacesContext but in a custom ThreadLocal variable. Then the messages can be picked up by a REST interceptor and added to the, for example, JSON response. But it can also be picked up by a JSF lifecycle interceptor. I can commit the code which I have developped for a demo application that uses it. WDYT? Regards Rudy
[jira] [Updated] (DELTASPIKE-429) Old property that could be removed in parent\pom.xml
[ https://issues.apache.org/jira/browse/DELTASPIKE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament updated DELTASPIKE-429: - Affects Version/s: (was: 0.6) Old property that could be removed in parent\pom.xml Key: DELTASPIKE-429 URL: https://issues.apache.org/jira/browse/DELTASPIKE-429 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 0.5 Reporter: Karl Kildén Priority: Minor arquillian-openwebbeans.version1.0.0.CR2/arquillian-openwebbeans.version This property can be found in the parent pom but it is not used. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (DELTASPIKE-429) Old property that could be removed in parent\pom.xml
[ https://issues.apache.org/jira/browse/DELTASPIKE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament reassigned DELTASPIKE-429: Assignee: John D. Ament Old property that could be removed in parent\pom.xml Key: DELTASPIKE-429 URL: https://issues.apache.org/jira/browse/DELTASPIKE-429 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 0.5 Reporter: Karl Kildén Assignee: John D. Ament Priority: Minor Fix For: 0.6 arquillian-openwebbeans.version1.0.0.CR2/arquillian-openwebbeans.version This property can be found in the parent pom but it is not used. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: CDI ContextControl - only available in SE mode?
Thanks guys. My question is not really in tune with jsr 236, but I was able to get it working. I'll update the docs in the next day or two on how to make it work in EE. On Mon, Oct 14, 2013 at 4:34 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: @AppScope will work for sure but other scopes would need to be initialized/resetted. There isn't enough link between jsr 236 and cdi to suppose it but CDI tend to impose container to start request/session scopes if not already started so I think it can work out of the box, no? *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/14 Mark Struberg strub...@yahoo.de Hmm, I remember talking with Romain about this a few months ago and if I remember correctly we had the conclusion that at least @ApplicationScoped context and @RequestScoped context needs to be set up. But I'd be happy to learn that this is not the case. We could also redirect this question to the EE or EJB EG which seems to have been in charge about the concurrency util integration into EE7. In any case ContextControl should work :) LieGrue, strub - Original Message - From: Martin Kouba mko...@redhat.com To: dev@deltaspike.apache.org Cc: Sent: Monday, 14 October 2013, 10:00 Subject: Re: CDI ContextControl - only available in SE mode? Dne 14.10.2013 09:22, Mark Struberg napsal(a): Hi John! Yes, the ContextControl is also designed for being used in JavaEE. This is very helpful if you need to manually for new threads which need CDI setup properly in JavaEE6 or a pure Servlet container based environment. In JavaEE7 you should be able to utilize JSR-236 concurrency utils for JavaEE to create a 'Managed Thread' which has at least the @RequestScoped and @ApplicationScoped contexts set up properly. Still you can use the ContextControl to start a dummy @RequestScoped context even in this case. Mark, I think JSR-236 only comments on using CDI beans as tasks, it says nothing about CDI context propagation. WRT JSR-236 it seems the container must only support propagation of JNDI naming context, classloader, and security information. So I think request context is not set up properly. The application context should be ok. Maybe I'm missing something... There are of course a few restriction in jsr-236. You can read more about it in section 2.3.2.1 Tasks and Contexts and Dependency Injection (CDI). In that case ContextControl could be an easy way to work around it. hth. LieGrue, strub - Original Message - From: John D. Ament john.d.am...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Monday, 14 October 2013, 0:59 Subject: Re: CDI ContextControl - only available in SE mode? Interesting. I guess my big curiosity is that it was shipped in 0.4 but it's not clear what was shipped. Better handling if you're in EE so that it doesn't crash? Clearly yes, you shouldn't be able to boot weld if you're already in EE, but I'm more interested in starting contexts. On Sun, Oct 13, 2013 at 4:17 PM, Karl Kildén karl.kil...@gmail.com wrote: Hi. It works for OWB. See: https://issues.apache.org/jira/browse/DELTASPIKE-284 On 13 October 2013 21:29, John D. Ament john.d.am...@gmail.com wrote: Hey guys, Just wanted to check with everyone. Looking at the documentation around context control, it seems a little puzzling and wanted to get others opinions. I don't need to be in SE mode to start a context manually, right? The docs seem to imply this, but if I'm already in a CDI container doing work, I should be able to inject ContextControl to my class and start a new context right? I'd need to look up the bean, e.g. through BeanManager but it should work in theory, right? If we agree it should work, I can update the docs to make it clearer, as right now it looks like it should only work in SE mode. Thanks, John
Re: CDI ContextControl - only available in SE mode?
Interesting. I guess my big curiosity is that it was shipped in 0.4 but it's not clear what was shipped. Better handling if you're in EE so that it doesn't crash? Clearly yes, you shouldn't be able to boot weld if you're already in EE, but I'm more interested in starting contexts. On Sun, Oct 13, 2013 at 4:17 PM, Karl Kildén karl.kil...@gmail.com wrote: Hi. It works for OWB. See: https://issues.apache.org/jira/browse/DELTASPIKE-284 On 13 October 2013 21:29, John D. Ament john.d.am...@gmail.com wrote: Hey guys, Just wanted to check with everyone. Looking at the documentation around context control, it seems a little puzzling and wanted to get others opinions. I don't need to be in SE mode to start a context manually, right? The docs seem to imply this, but if I'm already in a CDI container doing work, I should be able to inject ContextControl to my class and start a new context right? I'd need to look up the bean, e.g. through BeanManager but it should work in theory, right? If we agree it should work, I can update the docs to make it clearer, as right now it looks like it should only work in SE mode. Thanks, John
[jira] [Assigned] (DELTASPIKE-427) WeldContainerControl throws a NullPointer before a null check.
[ https://issues.apache.org/jira/browse/DELTASPIKE-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament reassigned DELTASPIKE-427: Assignee: John D. Ament WeldContainerControl throws a NullPointer before a null check. -- Key: DELTASPIKE-427 URL: https://issues.apache.org/jira/browse/DELTASPIKE-427 Project: DeltaSpike Issue Type: Bug Components: CdiControl Affects Versions: 0.5 Reporter: John D. Ament Assignee: John D. Ament Priority: Minor Fix For: 0.6 If not called the right way, the calls for BeanManager are invoked after a null check. We should do the null check first, then continue. Throw the log message still. -- This message was sent by Atlassian JIRA (v6.1#6144)
Arquillian + Servlet Module
Hi all I just published a brief blog post on how you can use DeltaSpike's servlet module with Arquillian to test out your JAAS based applications. Let me know your thoughts! http://john-ament.blogspot.com/2013/09/testing-jaas-based-authentication-using.html - John
Re: ConfigSource using ThreadLocal
Also, couldn't you deploy an application scoped config source, and set the value (assuming you're InSequence). Also, you don't need to use @InSequence if you use JUnit ordering Name Ascending: https://github.com/junit-team/junit/wiki/Test-execution-order John On Wed, Sep 25, 2013 at 12:47 PM, Jason Porter lightguard...@gmail.com wrote: 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
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: DeltaSpike @ JavaOne?
Yeah, I'm on the JMS2 BOF. On Mon, Sep 16, 2013 at 11:21 AM, Jason Porter lightguard...@gmail.com wrote: Good question. You're not presenting anything, are you John? For those in Europe I'll also be at Devoxx this year. On Sun, Sep 15, 2013 at 7:51 AM, John D. Ament john.d.am...@gmail.comwrote: Hi I know Jason's going, and I'll be there. Anyone else going to be at JavaOne this year? John -- Jason Porter http://en.gravatar.com/lightguardjp
Re: [VOTE] Release Apache DeltaSpike-0.5
+1 binding On Wed, Sep 11, 2013 at 10:32 AM, Christian Kaltepoth christ...@kaltepoth.de wrote: +1 2013/9/11 Mark Struberg strub...@yahoo.de and the obvious voting header got lost as well. So please add the standard sentence: The VOTE will be open for 72 hours. [ ] +1 all fine, ship it [ ] +0 meh, don't care [ ] -1 veto (and reason why) LieGrue, strub - Original Message - From: Mark Struberg strub...@yahoo.de To: deltaspike dev@deltaspike.apache.org Cc: Sent: Wednesday, 11 September 2013, 15:18 Subject: [VOTE] Release Apache DeltaSpike-0.5 Hi! I'd like to call a VOTE for the release of DeltasSpike-0.4. The staging repo is: https://repository.apache.org/content/repositories/orgapachedeltaspike-029/ The tag is available here: https://github.com/struberg/deltaspike/tree/deltaspike-project-0.5 This will get pushed to the ASF repo and merged into the upstream master branch once the VOTE succeeded. The source release is available here: https://repository.apache.org/content/repositories/orgapachedeltaspike-029//org/apache/deltaspike/deltaspike-project/0.5/deltaspike-project-0.5-source-release.zip Release Notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312820version=12320947 Guide to testing: Add the following to your ~/.m2/settings.xml: profile idstaging/id repositories repository idapache_staging/id url https://repository.apache.org/content/repositories/orgapachedeltaspike-029/ /url releasesenabledtrue/enabled/releases snapshotsenabledfalse/enabled/snapshots /repository /repositories /profile Then upgrade your project to 0.5 and build with mvn -Pstaging. LieGrue, your Apache DeltaSpike Team -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
Re: DeltaSpike-incubator-jbossas-managed-7 - Build # 247 - Still Unstable!
Shouldn't you disable OWB tests if you're running on AS7? Error Message org.apache.webbeans.corespi.scanner.AnnotationDB$CrossReferenceException: cannot resolve classes [org.jboss.errai.bus.server.annotations.Service] Stacktrace java.lang.RuntimeException: org.apache.webbeans.corespi.scanner.AnnotationDB$CrossReferenceException: cannot resolve classes [org.jboss.errai.bus.server.annotations.Service] at org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.crossReferenceBeans(AbstractMetaDataDiscovery.java:255) at org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.getBeanClasses(AbstractMetaDataDiscovery.java:200) at org.apache.webbeans.config.BeansDeployer.checkStereoTypes(BeansDeployer.java:734) at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:162) at org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:128) at org.apache.deltaspike.cdise.owb.OpenWebBeansContainerControl.boot(OpenWebBeansContainerControl.java:68) at org.apache.deltaspike.cdise.tck.ContainerCtrlTckTest.testContainerBoot(ContainerCtrlTckTest.java:45) On Wed, Aug 28, 2013 at 2:31 AM, Mark Struberg strub...@yahoo.de wrote: Hi SeamQA folks! Could you please verify the build below? From reading the output it seems that the actual DeltaSpike build is really fine and there is only a problem with publishing the junit test results later. Guess it's as simple as a missing file permission or something similar as the build itself seems fine. txs and LieGrue, strub From: ci-bui...@redhat.com ci-bui...@redhat.com To: rsme...@redhat.com; seam-qa-l...@redhat.com; deltaspike-comm...@incubator.apache.org; strub...@apache.org Sent: Tuesday, 27 August 2013, 6:06 Subject: DeltaSpike-incubator-jbossas-managed-7 - Build # 247 - Still Unstable! Public link to build: http://hudson.jboss.org/hudson/job/DeltaSpike-incubator-jbossas-managed-7/247 DeltaSpike-incubator-jbossas-managed-7 - Build # 247 - Still Unstable: Check console output at http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/DeltaSpike-incubator-jbossas-managed-7/247/ to view the results. Changes: [struberg] DELTASPIKE-402 cdicontainer.version for tomee via arquillian -- [...truncated 4329 lines...] [INFO] Using configured provider org.apache.maven.surefire.junitcore.JUnitCoreProvider --- T E S T S --- Concurrency config is parallel='none', perCoreThreadCount=true, threadCount=2, useUnlimitedThreads=false Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ deltaspike-jse-example --- [INFO] Building jar: /mnt/hudson_workspace/workspace/DeltaSpike-incubator-jbossas-managed-7/deltaspike/examples/jse-examples/target/deltaspike-jse-example-0.5-SNAPSHOT.jar [INFO] [INFO] --- maven-site-plugin:3.1:attach-descriptor (attach-descriptor) @ deltaspike-jse-example --- [INFO] [INFO] maven-source-plugin:2.1.2:jar (attach-sources) @ deltaspike-jse-example [INFO] [INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (versions) @ deltaspike-jse-example --- [INFO] [INFO] --- maven-antrun-plugin:1.6:run (javadoc.resources) @ deltaspike-jse-example --- [WARNING] Parameter tasks is deprecated, use target instead [INFO] Executing tasks main: [INFO] Executed tasks [INFO] [INFO] maven-source-plugin:2.1.2:jar (attach-sources) @ deltaspike-jse-example [INFO] [INFO] --- maven-source-plugin:2.1.2:jar (attach-sources) @ deltaspike-jse-example --- [INFO] META-INF already added, skipping [INFO] META-INF/DEPENDENCIES already added, skipping [INFO] META-INF/DISCLAIMER already added, skipping [INFO] META-INF/LICENSE already added, skipping [INFO] META-INF/NOTICE already added, skipping [INFO] META-INF already added, skipping [INFO] META-INF already added, skipping [INFO] META-INF/DEPENDENCIES already added, skipping [INFO] META-INF/DISCLAIMER already added, skipping [INFO] META-INF/LICENSE already added, skipping [INFO] META-INF/NOTICE already added, skipping [INFO] META-INF already added, skipping [INFO] META-INF/DEPENDENCIES already added, skipping [INFO] META-INF/DISCLAIMER already added, skipping [INFO] META-INF/LICENSE already added, skipping [INFO] META-INF/NOTICE already added, skipping [INFO] Building jar: /mnt/hudson_workspace/workspace/DeltaSpike-incubator-jbossas-managed-7/deltaspike/examples/jse-examples/target/deltaspike-jse-example-0.5-SNAPSHOT-sources.jar [INFO] META-INF already added, skipping [INFO] META-INF/DEPENDENCIES already added, skipping [INFO] META-INF/DISCLAIMER already added, skipping [INFO] META-INF/LICENSE already added, skipping [INFO] META-INF/NOTICE already added, skipping [INFO] META-INF already added, skipping [INFO] META-INF already added, skipping [INFO] META-INF/DEPENDENCIES already added, skipping [INFO] META-INF/DISCLAIMER
Fwd: ASF Board Meeting Summary - August 21, 2013
FYI, we missed reporting. -- Forwarded message -- From: Brett Porter chair...@apache.org Date: Wed, Aug 21, 2013 at 3:37 PM Subject: ASF Board Meeting Summary - August 21, 2013 To: committ...@apache.org committ...@apache.org The August board meeting took place on the 21st. The following directors were present: Shane Curcuru Doug Cutting Bertrand Delacretaz Roy T. Fielding Jim Jagielski Chris Mattmann Brett Porter Sam Ruby Greg Stein The following officers were present: Ross Gardler Rich Bowen The following guests were present: Sean Kelly Daniel Gruno Christian Grobmeier Henri Yandell The July minutes were approved. The following reports were not approved and are expected next month: Report from the Apache Click Project [Malcolm Edgar] Report from the Apache DirectMemory Project [Raffaele P. Guidi] The following reports were not received and are expected next month: Report from the Apache Buildr Project [Alex Boisvert] Report from the Apache DeltaSpike Project [Mark Struberg] Report from the Apache Mahout Project [Jake Mannix] Report from the Apache Perl Project [Philippe M. Chiasson] Report from the Apache POI Project [Yegor Kozlov] Report from the Apache Qpid Project [Carl Trieloff] All other received reports to the board were approved. The following resolutions were passed unanimously: A. Change the Apache Maven Project Chair (Stephen Connolly, VP) B. Change the Apache Oozie Chair (Mohammad Islam, VP) C. Change the Apache Axis Project Chair (Deepal Jayasinghe, VP) D. Change the Apache Shindig Project Chair (Ryan Baxter, VP) The next board meeting will be on the 18th of September.
Re: all tests green (almost)
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...
Re: Deltaspike fails to detect Javascript in IE8
Hi Martjin,
Actually, we found a very similar issue in our apps at work. We have some
machines w/ IE8, others with IE9 and IE10. For some reason, IE8 was
downgrading to IE7. Found that there was a browser setting causing it to
render all intranet sites in compatibility mode. Thanks MS! We're not
using a JSF front end, instead bootstrap + backbone + lots of other jquery
goodies. As far as i know, this isn't something the app can fix (in fact,
when I tried putting in headers to fix it, I was able to fix it locally but
not when it was running on our QA machines).
John
On Thu, Jul 18, 2013 at 11:51 AM, Martijn Hiemstra m.hiems...@regas.nlwrote:
Hi everybody, Strub,
You mention the following:
In general I'd say that any inhouse application utilizing JFS-2 should have
JavaScript enabled. The non-javascript days are gone - we must get over it
;)
Without JavaScript your app would not work anyway.
That is the issue. We have Javascript enabled. Primefaces with all it's
Javascript worked perfectly together with Myfaces CODI on all browsers even
the older ones. This issue started once we switched to Deltaspike and now
any browser that doesn't support html5 sees the message. In deltaspike
there is a file called windowhandler.html and it's causing the message to
appear. The message appears if the browser doesn't support html5 even when
you have Javascript enabled.
Our clients want to open our website in different tabs to view different
pages at the same time so that they can compare information on the website
so as I understand setting ClientWindowRenderMode.NONE isn't an option?
Perhaps I don't understand how the window handeling works however if we are
using the default settings won't alot of people get this Javascript error
detection? Clients who visit your website will be forced to use the most
modern version of their browser to view the website and that's not always
possible.
Thanks in advance,
Martijn
2013/7/18 Mark Struberg strub...@yahoo.de
Hi Martin!
Heiko already pointed you in the right direction. You can even disable or
tweak the window handling depending on e.g. the UserAgent (we already
exclude bots for example).
Will there be a permanent solution? Is it solvable in Deltapike? Or is
it
perhaps an Internet explorer issue?
In general I'd say that any inhouse application utilizing JFS-2 should
have JavaScript enabled. The non-javascript days are gone - we must get
over it ;)
Without JavaScript your app would not work anyway.
There are basically 3 modes for the window detection.
* none - all browser tab see the same information
* lazy - rewrite the windowId in JavaScript on the target page. Be aware
that the first page hit might trash the beans from your original browser
tab! It works fine if you take care about this in your app design.
* clientwindow - we render a small and fast intermediate page which does
the browser tab detection and then forwards to the destination page.
I did installations where we use the clientwindow mode for all in-house
clients but switch to lazy mode for all public internet usage (based on
the
request IP). We also only enable clientwindow for UserAgents which are
known to support html5 (due to the localstorage trick for getting rid of
the flickering).
LieGrue,
strub
- Original Message -
From: Martijn Hiemstra m.hiems...@regas.nl
To: dev@deltaspike.apache.org
Cc:
Sent: Wednesday, 17 July 2013, 14:41
Subject: Re: Deltaspike fails to detect Javascript in IE8
Our clients have found a work around by putting our website in the list
of
trusted websites.
Will there be a permanent solution? Is it solvable in Deltapike? Or is it
perhaps an Internet explorer issue?
Martijn Hiemstra
2013/7/17 it-media.k...@daimler.com
Hello Martijn,
we've had the same issue. This is related to the client window
handling,
that targets modern browsers supporting HTML5.
Simply add a class to your application with the following content:
@Specializes
public class OurClientWindowConfig extends DefaultClientWindowConfig
{
private static final long serialVersionUID = -3349441047782577598L;
@Override
public ClientWindowRenderMode getClientWindowRenderMode(final
FacesContext facesContext)
{
return ClientWindowRenderMode.NONE;
}
}
This will remove the client window handling and the messsage should
disappear.
But be aware of the consequences (loss of proper window handling).
Regards,
Heiko
--
-Ursprüngliche Nachricht-
Von: Martijn Hiemstra [mailto:m.hiems...@regas.nl]
Gesendet: Mittwoch, 17. Juli 2013 11:24
An: dev@deltaspike.apache.org
Betreff: Deltaspike fails to detect Javascript in IE8
Hallo Everybody,
We have switched to Deltaspike and ever since when we visit our
website
Re: Data Module
Yep, if you want to do it in the JPA layer you can do something like that.
In my case, my front end data objects aren't exposed to our JPA libraries,
so it's not an option.
@Romain
How do you make a CDI object a remote EJB? Or are you referring to
transactional state? As far as I know, you cannot setup an MDB in a CDI
extension.
On Fri, Jul 12, 2013 at 6:59 AM, hantsy han...@yahoo.com.cn wrote:
Your requirement is based on your experience, i do not think a must in
REST application.
Some case we can wrap the result in query result like this.
select new UserResult(name, email ) from User u
to get a ValueObject directly.
Hantsy
On 7/12/2013 14:12, Romain Manni-Bucau wrote:
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
Re: reminder: use jira numbers in commits
Resending this, just in case anyone missed it. On Mon, Jun 17, 2013 at 2:25 AM, Mark Struberg strub...@yahoo.de wrote: Hi folks! Nothing serious, but if possible, please add the DELTASPIKE-xxx jira numbers to the commit comment in the future. txs and LieGrue, strub
Time to cut 0.5?
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.
Re: Time to cut 0.5?
Errr, 3 new modules. On Sat, Jul 6, 2013 at 8:03 PM, John D. Ament john.d.am...@gmail.comwrote: 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.
[jira] [Updated] (DELTASPIKE-269) Add XML Config from Seam
[ https://issues.apache.org/jira/browse/DELTASPIKE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament updated DELTASPIKE-269: - Fix Version/s: (was: 0.5) 0.6 Add XML Config from Seam Key: DELTASPIKE-269 URL: https://issues.apache.org/jira/browse/DELTASPIKE-269 Project: DeltaSpike Issue Type: Task Components: Configuration Affects Versions: 0.4 Reporter: Jason Porter Assignee: Jason Porter Fix For: 0.6 Umbrella issue for adding in Seam Config -- 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
[jira] [Updated] (DELTASPIKE-272) Copy documentation from Seam Solder for configuration
[ https://issues.apache.org/jira/browse/DELTASPIKE-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament updated DELTASPIKE-272: - Fix Version/s: (was: 0.5) 0.6 Copy documentation from Seam Solder for configuration - Key: DELTASPIKE-272 URL: https://issues.apache.org/jira/browse/DELTASPIKE-272 Project: DeltaSpike Issue Type: Sub-task Components: Configuration Affects Versions: 0.4 Reporter: Jason Porter Fix For: 0.6 -- 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
[jira] [Updated] (DELTASPIKE-270) Create api and impl spaces for the module
[ https://issues.apache.org/jira/browse/DELTASPIKE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament updated DELTASPIKE-270: - Fix Version/s: (was: 0.5) 0.6 Create api and impl spaces for the module - Key: DELTASPIKE-270 URL: https://issues.apache.org/jira/browse/DELTASPIKE-270 Project: DeltaSpike Issue Type: Sub-task Components: Configuration Affects Versions: 0.4 Reporter: Jason Porter Fix For: 0.6 -- 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
[jira] [Resolved] (DELTASPIKE-60) Review and discuss a generic DAO API
[ https://issues.apache.org/jira/browse/DELTASPIKE-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament resolved DELTASPIKE-60. - Resolution: Fixed Data module was imported successfully by Thomas Hug. Review and discuss a generic DAO API Key: DELTASPIKE-60 URL: https://issues.apache.org/jira/browse/DELTASPIKE-60 Project: DeltaSpike Issue Type: Task Components: Core Reporter: Thomas Hug Assignee: Romain Manni-Bucau Fix For: 0.5 A CDI extension based DAO API is intended to help simplifying DAOs. JPA query methods often require repetitive code and clutter DAOs. Getting rid of boilerplate and allowing to create simple queries declaratively will help keeping focus on the more complex query logic. Topics: - Declarative queries - Simplified usage of JPA There is already an existing CDI extension approaching this problem: https://github.com/ctpconsulting/query http://ctpconsulting.github.com/query/latest -- 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: Time to cut 0.5?
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.comwrote: 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
[jira] [Resolved] (DELTASPIKE-388) Add support for a ConstraintValidatorFactory that creates CDI enabled constraint validators
[ https://issues.apache.org/jira/browse/DELTASPIKE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament resolved DELTASPIKE-388. -- Resolution: Fixed Finished creating module and setting up tests. Add support for a ConstraintValidatorFactory that creates CDI enabled constraint validators --- Key: DELTASPIKE-388 URL: https://issues.apache.org/jira/browse/DELTASPIKE-388 Project: DeltaSpike Issue Type: Sub-task Components: BeanValidation-Module Reporter: John D. Ament Assignee: John D. Ament Fix For: 0.5 -- 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
[jira] [Commented] (DELTASPIKE-384) ViewConfigUtils.toNodeList() fails in EAR
[
https://issues.apache.org/jira/browse/DELTASPIKE-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13696421#comment-13696421
]
John D. Ament commented on DELTASPIKE-384:
--
The patch looks reasonable. Did you run it in both a WAR and EAR, seems
working ok?
ViewConfigUtils.toNodeList() fails in EAR
-
Key: DELTASPIKE-384
URL: https://issues.apache.org/jira/browse/DELTASPIKE-384
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 0.4
Environment: JBoss AS 7.2.0.Final (EAP 6.1.0.Alpha1)
Reporter: Richard DiCroce
Attachments: deltaspike-384.patch
ViewConfigUtils.toNodeList() does not work in my EAR.
ClassUtils.tryToLoadClassForName() returns null for every class that
toNodeList() uses it to try to load. This eventually results in a
NullPointerException.
To work around the problem, I have substituted my own version of the
ViewConfigUtils class, containing the below rewrite of toNodeList() which is
equivalent but doesn't require use of any classloaders:
{code}
public static ListClass toNodeList(Class nodeClass) {
ListClass treePath = new ArrayListClass();
do {
treePath.add(0, nodeClass);
nodeClass = nodeClass.getEnclosingClass();
} while (nodeClass != null);
return treePath;
}
{code}
--
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
[jira] [Commented] (DELTASPIKE-384) ViewConfigUtils.toNodeList() fails in EAR
[
https://issues.apache.org/jira/browse/DELTASPIKE-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13696423#comment-13696423
]
John D. Ament commented on DELTASPIKE-384:
--
thanks for the patch. I'll test it out locally this evening and merge it in.
This shouldn't be held up by ear support since there's really nothing CDI
centric about this feature.
ViewConfigUtils.toNodeList() fails in EAR
-
Key: DELTASPIKE-384
URL: https://issues.apache.org/jira/browse/DELTASPIKE-384
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 0.4
Environment: JBoss AS 7.2.0.Final (EAP 6.1.0.Alpha1)
Reporter: Richard DiCroce
Attachments: deltaspike-384.patch
ViewConfigUtils.toNodeList() does not work in my EAR.
ClassUtils.tryToLoadClassForName() returns null for every class that
toNodeList() uses it to try to load. This eventually results in a
NullPointerException.
To work around the problem, I have substituted my own version of the
ViewConfigUtils class, containing the below rewrite of toNodeList() which is
equivalent but doesn't require use of any classloaders:
{code}
public static ListClass toNodeList(Class nodeClass) {
ListClass treePath = new ArrayListClass();
do {
treePath.add(0, nodeClass);
nodeClass = nodeClass.getEnclosingClass();
} while (nodeClass != null);
return treePath;
}
{code}
--
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
[jira] [Updated] (DELTASPIKE-384) ViewConfigUtils.toNodeList() fails in EAR
[
https://issues.apache.org/jira/browse/DELTASPIKE-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament updated DELTASPIKE-384:
-
Fix Version/s: 0.5
ViewConfigUtils.toNodeList() fails in EAR
-
Key: DELTASPIKE-384
URL: https://issues.apache.org/jira/browse/DELTASPIKE-384
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 0.4
Environment: JBoss AS 7.2.0.Final (EAP 6.1.0.Alpha1)
Reporter: Richard DiCroce
Assignee: John D. Ament
Fix For: 0.5
Attachments: deltaspike-384.patch
ViewConfigUtils.toNodeList() does not work in my EAR.
ClassUtils.tryToLoadClassForName() returns null for every class that
toNodeList() uses it to try to load. This eventually results in a
NullPointerException.
To work around the problem, I have substituted my own version of the
ViewConfigUtils class, containing the below rewrite of toNodeList() which is
equivalent but doesn't require use of any classloaders:
{code}
public static ListClass toNodeList(Class nodeClass) {
ListClass treePath = new ArrayListClass();
do {
treePath.add(0, nodeClass);
nodeClass = nodeClass.getEnclosingClass();
} while (nodeClass != null);
return treePath;
}
{code}
--
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
[jira] [Assigned] (DELTASPIKE-384) ViewConfigUtils.toNodeList() fails in EAR
[
https://issues.apache.org/jira/browse/DELTASPIKE-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament reassigned DELTASPIKE-384:
Assignee: John D. Ament
ViewConfigUtils.toNodeList() fails in EAR
-
Key: DELTASPIKE-384
URL: https://issues.apache.org/jira/browse/DELTASPIKE-384
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 0.4
Environment: JBoss AS 7.2.0.Final (EAP 6.1.0.Alpha1)
Reporter: Richard DiCroce
Assignee: John D. Ament
Attachments: deltaspike-384.patch
ViewConfigUtils.toNodeList() does not work in my EAR.
ClassUtils.tryToLoadClassForName() returns null for every class that
toNodeList() uses it to try to load. This eventually results in a
NullPointerException.
To work around the problem, I have substituted my own version of the
ViewConfigUtils class, containing the below rewrite of toNodeList() which is
equivalent but doesn't require use of any classloaders:
{code}
public static ListClass toNodeList(Class nodeClass) {
ListClass treePath = new ArrayListClass();
do {
treePath.add(0, nodeClass);
nodeClass = nodeClass.getEnclosingClass();
} while (nodeClass != null);
return treePath;
}
{code}
--
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
Data Module
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
Re: Build failed in Jenkins: DeltaSpike RAT-Check #550
Hi Does anyone know if this job isn't configured for pruning/clean up? When I run this locally at first it failed because I had remanants of the old beanval directory. Now they're gone and it's fine. When I check github it's not there. But I think Jenkins may have the old files still? John On Mon, Jun 24, 2013 at 8:14 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: See https://builds.apache.org/job/DeltaSpike%20RAT-Check/550/changes Changes: [john.d.ament] DELTASPIKE-387 Created new name for the module. [john.d.ament] DELTASPIKE-387 Renamed package. [john.d.ament] DELTASPIKE-387 Changed test package name. [christian] Minor javadoc cleanup in servlet module -- [...truncated 2105 lines...] INFO - Enterprise application https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/classpath.ear; loaded. INFO - Creating TransactionManager(id=Default Transaction Manager) INFO - Creating SecurityService(id=Default Security Service) INFO - Using 'java.security.auth.login.config=jar:file:/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/openejb/openejb-core/4.5.1/openejb-core-4.5.1.jar!/login.config' INFO - Creating Container(id=Default Managed Container) INFO - Using directory /tmp for stateful session passivation INFO - Assembling app: https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/classpath.ear INFO - Existing thread singleton service in SystemInstance() org.apache.openejb.cdi.ThreadSingletonServiceImpl@d6a05e INFO - OpenWebBeans Container is starting... INFO - Adding OpenWebBeansPlugin : [CdiPlugin] INFO - All injection points are validated successfully. INFO - OpenWebBeans Container has started, it took 11 ms. INFO - Deployed Application(path= https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/classpath.ear ) INFO - Destroying container system INFO - Undeploying app: https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/classpath.ear Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.82 sec Results : Tests run: 6, Failures: 0, Errors: 0, Skipped: 0 [JENKINS] Recording test results [INFO] [INFO] Building jar: https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/target/deltaspike-cdictrl-openejb-0.5-SNAPSHOT.jar [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ deltaspike-cdictrl-openejb --- [INFO] [INFO] --- maven-site-plugin:3.1:attach-descriptor (attach-descriptor) @ deltaspike-cdictrl-openejb --- [INFO] [INFO] Exclude: .idea/**/* [INFO] Exclude: readme/**/* [INFO] Exclude: **/*.log [INFO] --- apache-rat-plugin:0.8:check (default) @ deltaspike-cdictrl-openejb --- [INFO] [INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (versions) @ deltaspike-cdictrl-openejb --- [INFO] [WARNING] Parameter tasks is deprecated, use target instead [INFO] Executing tasks main: [INFO] Executed tasks [INFO] --- maven-antrun-plugin:1.6:run (javadoc.resources) @ deltaspike-cdictrl-openejb --- [INFO] [INFO] Configured Artifact: org.apache.deltaspike.cdictrl:deltaspike-cdictrl-owb:0.5-SNAPSHOT:jar [INFO] Unpacking https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-owb/target/deltaspike-cdictrl-owb-0.5-SNAPSHOT.jar to https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/target/classes with includes and excludes **\/META-INF\/**,**\/OpenWebBeansContainerControl.class [INFO] --- maven-dependency-plugin:2.4:unpack (unpack-context) @ deltaspike-cdictrl-openejb --- Jun 25, 2013 12:12:21 AM hudson.maven.ExecutedMojo init WARNING: Failed to getClass for org.apache.maven.plugin.source.SourceJarMojo [INFO] [INFO] META-INF already added, skipping [INFO] META-INF/NOTICE already added, skipping [INFO] META-INF/LICENSE already added, skipping [INFO] META-INF/DISCLAIMER already added, skipping [INFO] META-INF/DEPENDENCIES already added, skipping [INFO] META-INF already added, skipping [INFO] META-INF already added, skipping [INFO] META-INF/NOTICE already added, skipping [INFO] META-INF/LICENSE already added, skipping [INFO] META-INF/DISCLAIMER already added, skipping [INFO] META-INF/DEPENDENCIES already added, skipping [INFO] META-INF already added, skipping [INFO] META-INF/NOTICE already added, skipping [INFO] META-INF/LICENSE already added, skipping [INFO] META-INF/DISCLAIMER already added, skipping [INFO] META-INF/DEPENDENCIES already added, skipping [INFO] Building jar: https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/target/deltaspike-cdictrl-openejb-0.5-SNAPSHOT-sources.jar [INFO] --- maven-source-plugin:2.1.2:jar (attach-sources) @ deltaspike-cdictrl-openejb --- [INFO] META-INF already added, skipping [INFO] META-INF/NOTICE already added, skipping [INFO]
Re: Build failed in Jenkins: DeltaSpike RAT-Check #550
except... * Summary --- Generated at: 2013-06-24T21:29:46-04:00 Notes: 0 Binaries: 0 Archives: 0 Standards: 1 Apache Licensed: 1 Generated Documents: 0 JavaDocs are generated and so license header is optional Generated files do not required license headers 0 Unknown Licenses *** Unapproved licenses: *** Archives: * Files with Apache License headers will be marked AL Binary files (which do not require AL headers) will be marked B Compressed archives will be marked A Notices, licenses etc will be marked N AL C:/Users/john.ament/Documents/GitHub/deltaspike/deltaspike/modules/pom.xml * Printing headers for files without AL header... On Mon, Jun 24, 2013 at 9:43 PM, Jason Porter lightguard...@gmail.comwrote: The problem at the very end says Too many unapproved licenses: 16 not sure what we've added, but we have some license fixes to make it seems. — Sent from Mailbox for iPhone On Mon, Jun 24, 2013 at 6:14 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: See https://builds.apache.org/job/DeltaSpike%20RAT-Check/550/changes Changes: [john.d.ament] DELTASPIKE-387 Created new name for the module. [john.d.ament] DELTASPIKE-387 Renamed package. [john.d.ament] DELTASPIKE-387 Changed test package name. [christian] Minor javadoc cleanup in servlet module -- [...truncated 2105 lines...] INFO - Enterprise application https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/classpath.ear; loaded. INFO - Creating TransactionManager(id=Default Transaction Manager) INFO - Creating SecurityService(id=Default Security Service) INFO - Using 'java.security.auth.login.config=jar:file:/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/openejb/openejb-core/4.5.1/openejb-core-4.5.1.jar!/login.config' INFO - Creating Container(id=Default Managed Container) INFO - Using directory /tmp for stateful session passivation INFO - Assembling app: https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/classpath.ear INFO - Existing thread singleton service in SystemInstance() org.apache.openejb.cdi.ThreadSingletonServiceImpl@d6a05e INFO - OpenWebBeans Container is starting... INFO - Adding OpenWebBeansPlugin : [CdiPlugin] INFO - All injection points are validated successfully. INFO - OpenWebBeans Container has started, it took 11 ms. INFO - Deployed Application(path= https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/classpath.ear ) INFO - Destroying container system INFO - Undeploying app: https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/classpath.ear Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.82 sec Results : Tests run: 6, Failures: 0, Errors: 0, Skipped: 0 [JENKINS] Recording test results [INFO] [INFO] Building jar: https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/target/deltaspike-cdictrl-openejb-0.5-SNAPSHOT.jar [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ deltaspike-cdictrl-openejb --- [INFO] [INFO] --- maven-site-plugin:3.1:attach-descriptor (attach-descriptor) @ deltaspike-cdictrl-openejb --- [INFO] [INFO] Exclude: .idea/**/* [INFO] Exclude: readme/**/* [INFO] Exclude: **/*.log [INFO] --- apache-rat-plugin:0.8:check (default) @ deltaspike-cdictrl-openejb --- [INFO] [INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (versions) @ deltaspike-cdictrl-openejb --- [INFO] [WARNING] Parameter tasks is deprecated, use target instead [INFO] Executing tasks main: [INFO] Executed tasks [INFO] --- maven-antrun-plugin:1.6:run (javadoc.resources) @ deltaspike-cdictrl-openejb --- [INFO] [INFO] Configured Artifact: org.apache.deltaspike.cdictrl:deltaspike-cdictrl-owb:0.5-SNAPSHOT:jar [INFO] Unpacking https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-owb/target/deltaspike-cdictrl-owb-0.5-SNAPSHOT.jar to https://builds.apache.org/job/DeltaSpike%20RAT-Check/ws/deltaspike/cdictrl/impl-openejb/target/classes with includes and excludes **\/META-INF\/**,**\/OpenWebBeansContainerControl.class [INFO] --- maven-dependency-plugin:2.4:unpack (unpack-context) @ deltaspike-cdictrl-openejb --- Jun 25, 2013 12:12:21 AM hudson.maven.ExecutedMojo init WARNING: Failed to getClass for org.apache.maven.plugin.source.SourceJarMojo [INFO] [INFO] META-INF already added, skipping [INFO] META-INF/NOTICE already added, skipping [INFO] META-INF/LICENSE already added, skipping [INFO] META-INF/DISCLAIMER already added, skipping [INFO] META-INF/DEPENDENCIES already added, skipping [INFO] META-INF
Re: [VOTE] Bean Validation Module Name
Ok, so bean-validation is the winner. I'll create JIRAs and complete the move a bit later. John On Sun, Jun 16, 2013 at 8:42 PM, John D. Ament john.d.am...@gmail.comwrote: All Based on the thread thus far, I'd like to call a vote. These are the two names the seem to have the least angst: beanval bean-validation So, to vote please respond with a +1 or a -1. +1 is for beanval but -1 is for bean-validation I'm not including bv due to the US English connotations. I'm not including bval due to the existing apache project plus references to other names I saw in a quick google search. - John
Re: package in core: view.config
Maybe it could be a separate module, and both security and ?? compile against that. On Wed, Jun 19, 2013 at 3:19 PM, Mark Struberg strub...@yahoo.de wrote: Hi! All the ViewConfig stuff has not much to do with 'Configuration', right? It's more related to 'View'. Kind of the configuration for the View, but still only related to the View stuff. As I've understood we only need it in core at all because some Security stuff references it as well, right? But it's actually more view.config but config.view, isn't? Fear people who look at our 'config' API/SPI will get confused by all those unrelated classes. Should we move it? Or does it fit well enough and I just don't get it? LieGrue, strub
[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=13684601#comment-13684601
]
John D. Ament commented on DELTASPIKE-382:
--
What if it were even simpler?
public interface ConfigPrintChecker { //or some other name
public boolean displayKey(String key);
public boolean displayMasked(String key);
}
Then let whoever create an implementation that matches their needs
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
[DISCUSS] beanval module name
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
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: [VOTE] Bean Validation Module Name
[+1] beanval BTW, I'll leave this open for about 72 hours. John On Sun, Jun 16, 2013 at 8:42 PM, John D. Ament john.d.am...@gmail.comwrote: All Based on the thread thus far, I'd like to call a vote. These are the two names the seem to have the least angst: beanval bean-validation So, to vote please respond with a +1 or a -1. +1 is for beanval but -1 is for bean-validation I'm not including bv due to the US English connotations. I'm not including bval due to the existing apache project plus references to other names I saw in a quick google search. - John
Re: Servlet module prototype
+1 as well, looks good to me. On Tue, Jun 11, 2013 at 12:12 PM, Mark Struberg strub...@yahoo.de wrote: +1 let's move forward! Otherwise we will spend way too much time with discussions and too less with productive hacking ;) LieGrue, strub - Original Message - From: Christian Kaltepoth christ...@kaltepoth.de To: dev@deltaspike.apache.org Cc: Sent: Tuesday, 11 June 2013, 17:29 Subject: Re: Servlet module prototype Hey all, I finished the modifications I proposed in my last mail. The code is now split up into different filters and listeners for each job. I think this makes the code much cleaner an maintainable. You can have a look at the branch here: https://github.com/chkal/deltaspike/tree/servlet Especially this package: https://github.com/chkal/deltaspike/tree/servlet/deltaspike/modules/servlet/impl/src/main/java/org/apache/deltaspike/servlet/impl For now I registered all the listeners in web-fragment.xml: https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/main/resources/META-INF/web-fragment.xml If you all agree, I could rebase and merge the current state into the Apache repository. After I merged it, we could discuss how to implement ways to disable parts of the functionality. Either by implementing a dynamic registration using ServletInitializers or by using Deactivatable. What do you think? Christian 2013/6/8 Christian Kaltepoth christ...@kaltepoth.de Hey John, thank you very much for sharing your thoughts on this. It is very interesting for me to hear about the feedback your got from Solder users. And I think we should definitely address the issues you pointed out. So my idea would be the following. I could start separating the filter and the listeners into distinct classes with explicit functions. For example one filter for managing everything that is required for the injection of servlet objects and one filter for sending the events. After I'm done with this and if everybody agrees on the new structure, I could merge the current state into the main repository. After that we could think about and work on an approach to partially disable functionality which should be easy to implement with this new structure. What do you think? 2013/6/7 John D. Ament john.d.am...@gmail.com Hi Christian, Actually I was going to respond this morning but got side tracked. Anyways, I agree that the servlet module needs to provide all of this functionality, however I think we need to make sure that it's more scalable than the way this worked in solder/seam3. The biggest gripe I hear from people about seam3 was that it was all or nothing. It was difficult to activate only portions of the functionality. I think we started to do that in DS with the deactivateable function but there are certain places where it makes sense to deactivate in other ways. What I'm suggesting is that we: 1. Separate the listeners out - can we have two listeners, one for the context listener and one for the session listener. 2. Come up with some way that the filters can be more manageable. For example, maybe I'm only interested in request, not response. Maybe I only want Initialized and not Destroyed. This way we don't have to fire the event every single request. This is probably a good case for deactivatable, but more at the class feature level. 3. Come up with a way to make this not automatically installed, even if you include the servlet module in your archive. if metadata complete is the best option, we should just document the use of metadata complete to disable the installation. John On Fri, Jun 7, 2013 at 11:23 AM, Christian Kaltepoth christ...@kaltepoth.de wrote: Sorry, I think my mail wasn't very clear. Sorry for the confusion. :) The servlet module provides two features: the injection of servlet objects and the propagation of servlet events. It makes sense that the request events can be disabled. But IMHO the producers that allow injection of servlet objects is a fundamental feature of the servlet module without any performance overhead and should therefore not be deactivateable. The filter implemented in the servlet modules does two things: - It stores the request and the response in a ThreadLocal. The producer methods use this ThreadLocal to access the request/response. So the request/response injection requires this filter to work correctly. - The filter also propagates the servlet events to the CDI event bus. This is something that should be deactivatable. The same applies to things like the ServletContextListener. This one stores the ServletContext in a map for each context class loader and it sends
Re: Updating site docs
We appear to to verify Type in http://incubator.apache.org/deltaspike/news.html Expected result: get redirected to http://deltaspike.apache.org/news.html Outcome: success. On Sun, Jun 9, 2013 at 6:59 PM, Jason Porter lightguard...@gmail.comwrote: I was also wondering if we have some rewrite rules in place to redirect users going to the old URLS. — Sent from Mailbox for iPhone On Sun, Jun 9, 2013 at 4:54 PM, John D. Ament john.d.am...@gmail.com wrote: Well, I'm assuming the SVN url is: http://svn.apache.org/repos/asf/deltaspike/site/trunk/ which gives me an access denied. Should all committers have access? I was going to commit the following change Index: documentation.mdtext === --- documentation.mdtext (revision 1491309) +++ documentation.mdtext (working copy) @@ -56,9 +56,15 @@ In the listings below replace the placeholders for the version with the version of your choice or use: properties -deltaspike.version0.4-incubating-SNAPSHOT/deltaspike.version +deltaspike.version0.4/deltaspike.version /properties +Or if you want to very bleeding edge, point to our current snapshot. + +properties +deltaspike.version0.5-SNAPSHOT/deltaspike.version +/properties + ### Configuration of DeltaSpike Core dependency Index: news.mdtext === --- news.mdtext (revision 1491309) +++ news.mdtext (working copy) @@ -16,6 +16,16 @@ specific language governing permissions and limitations under the License. +## 4th Release (0.4) (31.05.2013) + +The Apache DeltaSpike team is pleased to announce the fourth release (v0.4). This is our first release as a top level project! + +The [release notes][14] contains a large list of bug fixes and new features. + +## Graduation (28.05.2013) + +The Apache DeltaSpike team is pleased to announce that we have complete graduation as a top level project. + ## 3rd Release (0.3 incubating) (22.08.2012) The Apache DeltaSpike team is pleased to announce the second release (v0.3-incubating). @@ -164,4 +174,5 @@ [10]: http://s.apache.org/cTt [11]: http://s.apache.org/DeltaSpike_01incubating [12]: http://s.apache.org/DeltaSpike_02incubating - [13]: http://s.apache.org/DeltaSpike_03incubating \ No newline at end of file + [13]: http://s.apache.org/DeltaSpike_03incubating + [14]: http://s.apache.org/DS-0.4-RNotes On Sun, Jun 9, 2013 at 6:36 PM, John D. Ament john.d.am...@gmail.com wrote: Hi Mark Yay tons of builds today. Anyways, I was wondering if there were any docs out there on how to update the site's documentation? Is there an SVN repo we check out to do this (I'm assuming infra doesn't support git for the sites). Do we do anything after committing? John
Re: Servlet module prototype
I'd prefer if we simply didn't include the web-fragment.xml and instead provided instructions on the wiki on how to enable them. On Thu, Jun 6, 2013 at 4:37 AM, Nicklas Karlsson nicka...@gmail.com wrote: I would also drop the @Web-annotation, I think. BTW, can the request/reponse lifecycle events be disabled? I would assume that there is a lot of firing going off for an ajax-application and they observers will have to be resolved even if there are no observers(?) On Thu, Jun 6, 2013 at 11:25 AM, Mark Struberg strub...@yahoo.de wrote: Nice work! The @Web Qualifier looks a bit odd, but will turn out into the broader discussion about how to implement features which might get 'added' in future specs. LieGrue, strub - Original Message - From: Christian Kaltepoth christ...@kaltepoth.de To: deltaspike-...@incubator.apache.org deltaspike-...@incubator.apache.org Cc: Sent: Thursday, 6 June 2013, 6:56 Subject: Servlet module prototype Hey all, I spent some time working on a first version of the servlet module. All the basic features are finished now and therefore I think its time to ask for some feedback. I pushed the code to the servlet branch on my github repo: https://github.com/chkal/deltaspike/tree/servlet The servlet module provides two major features: * Injection of servlet various objects * Servlet lifecycle events The producers are using the qualifier @Web to avoid conflicts with CDI 1.1. We could discuss whether some other name for the qualifier fits better. See the following classes from the tests to get an idea of what can be injected: https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/test/java/org/apache/deltaspike/test/servlet/impl/producer/ServletObjectInjectionBean.java https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/test/java/org/apache/deltaspike/test/servlet/impl/producer/ServletContextInjectionTest.java The lifecycle events are fired using the qualifiers @Initialized or @Destroyed just like in Seam Solder. I also added the @Web qualifier to all events, but we could discuss whether this is really necessary. The following classes show which events can be observed: https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/test/java/org/apache/deltaspike/test/servlet/impl/event/request/RequestResponseEventsObserver.java https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/test/java/org/apache/deltaspike/test/servlet/impl/event/session/SessionEventsObserver.java https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/test/java/org/apache/deltaspike/test/servlet/impl/event/context/ServletContextEventsObserver.java One thing that I'm not quite happy with is the way the ServletContext injection works. I'm currently using a map that stores the ServletContext for each context class loader. IMHO this is better than using HttpServletRequest.getServletContext() as it also works for threads outside of a request (like schedulers for example). I also wanted to avoid using the CDI application scope for storing the ServletContext to avoid problems regarding different implementations of the scope in regard to EAR packaging. I would be very interested in hearing your thoughts on this. :) One other thing. As I currently don't use any Servlet 3.0 features, the module depends on the Servlet 2.5 API. Do you think it makes sense to still support Servlet 2.5 or should we require at least Servlet 3.0? Looking forward to your feedback. Especially I would like to know if you think that the code should be merged into the upstream repository. :) Christian -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal -- Nicklas Karlsson, +358 40 5062266 Vaakunatie 10 as 7, 20780 Kaarina
Re: DISCUSS DeltaSpike-332
. 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 injection on JSF validator, converter, etc. Hantsy On 6/1/2013 22:11, Thomas Andraschko wrote: Also if BV 1.1 is coming soon, many customers can't upgrade to BV 1.1 or JavaEE 7 the next 1-2 years. So IMO it would be a great feature which shoudl be disabled per default. 2013/6/1 Romain Manni-Bucau rmannibu...@gmail.com Idem, not blocking IMO and bval 1.1 is coming so would be useless soon Le 1 juin 2013 15:56, Gerhard Petracek gerhard.petra...@gmail.com a écrit : hi john, codi doesn't do auto registration. you need @Advanced to enable it. if you aren't allowed to use bv 1.1 right know, you can just use BeanProvider manually (usually there are just few constraint-validators which need it at all) or keep what your are using now in parallel or just copy those few classes to your ee6 (only) project. at least in case of codi they are quite independent (and in most cases just simple wrappers). - -1 for adding it. regards, gerhard 2013/6/1 John D. Ament john.d.am...@gmail.com Hi All I wanted to begin introducing some level of BeanValidation Support. The main goal that I have is to be able to create CDI aware constraint validators, let's say you want to validate @NonExistentEmail then you should be able to run a query against your DB using your CDI services and determine if the given email is already present or not. To do this, both Seam3 and CODI introduced a CDI aware ConstraintFactory. When it creates an instance the instance is a CDI object, so it has full access to @Inject fields. I'd like to bring this type of functionality over to DS. The point where the two diverge is that CODI does an auto registration whereas Seam3 does a registration via validation.xml. As far as I know, CDI already allows the injection of Validator and ValidatorFactory (though the OWB guys can tell me if they disagree). Please let me know if anyone has concerns with adding this. Yes, I realize that this functionality is in bean val 1.1, but not everyone can upgrade to bean val 1.1 yet. John -- Hantsy Bai Blog:http://hantsy.blogspot.com LinkedIN:http://www.linkedin.com/in/hantsy
