[jira] [Commented] (DELTASPIKE-473) Add support for javax.transaction.Transactional annotation added in JTA 1.2 spec
[ https://issues.apache.org/jira/browse/DELTASPIKE-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858202#comment-13858202 ] Gerhard Petracek commented on DELTASPIKE-473: - @transactional from ds is just an alternative (and simple) approach with some advantages and some disadvantages. -> if you like the std. annotations, you are welcome to use them. as mentioned by romain: it isn't portable enough for ds -> it's more a topic for the other projects (if needed: they can provide special support for ds). > Add support for javax.transaction.Transactional annotation added in JTA 1.2 > spec > > > Key: DELTASPIKE-473 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-473 > Project: DeltaSpike > Issue Type: Improvement > Components: Data-Module, JPA-Module, TestControl >Affects Versions: 0.6 >Reporter: Ivan Vasyliev > Attachments: add_jta_1_2_into_deltaspike.patch > > > https://www.youtube.com/watch?v=rChkWy2NFyQ > The @Transactional annotation is already part of JavaEE, so there is no need > to have custom one. > The idea is to reuse code from JTA implementation. The one which already > supports 1.2 is Jbosstm(Narayana). I've made an attempt to incorporate it > into deltaspike. Please see attached changes and testcase. > Few notes on it: > - The producers for openwebbeans and weld are different, I've made > openwebbeans ones > - There is 2 system preferences which needs to be set to make narayana create > system folders under proper location (see surefire plugin config) > - Latest hibernate can autodetect JTA platform > - EntityManager created outside of JTA transaction can't join it > automatically, thats why there is proxy which join EM into > (http://stackoverflow.com/questions/9182/skipping-jta-sync-registration-due-to-auto-join-checking/11124021#11124021) > - Code based on this examples: > https://github.com/jbosstm/quickstart/tree/master/ArjunaJTA/standalone-jta-1_2 > - I did not make attempt to create generic datasource registration function, > this maybe subject for other issue -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[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
Marking as resolved, I think the horse is sufficiently puree'd here.
> 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
>
> Attachments: DELTASPIKE-399_merged_interface.patch
>
>
> Seam 3's Solder module had some nice resource loading functionality within
> the org.jboss.solder.resourceLoader packages. With it you could do the
> following:
> // Load a properties file
> @Inject @Resource("app.properties")
> private Properties appProperties;
> or:
> @Inject
> private ResourceProvider resourceProvider
> public Properties getHostProperties() {
>String hostname = java.net.InetAddress.getLocalHost().getHostName();
>return resourceProvider.loadPropertiesBundle(hostname + ".properties");
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-473) Add support for javax.transaction.Transactional annotation added in JTA 1.2 spec
[ https://issues.apache.org/jira/browse/DELTASPIKE-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858091#comment-13858091 ] Romain Manni-Bucau commented on DELTASPIKE-473: --- Hi Some inputs without particular order: 1) in tests arquillian @Transactional helps to test half of use cases 2) ProductServiceTest will not work excepted in standalone so not enough to be portable and handled my DS IMHO 3) one important issue stays: repositories don't handle @Transactional (whatever it is, DS or javax), the best for DS would be to update its annotation to be closer to JavaEE 7 + implement a backend using a DS CDI bean @Transactional (as "gateway" or "wrapper") > Add support for javax.transaction.Transactional annotation added in JTA 1.2 > spec > > > Key: DELTASPIKE-473 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-473 > Project: DeltaSpike > Issue Type: Improvement > Components: Data-Module, JPA-Module, TestControl >Affects Versions: 0.6 >Reporter: Ivan Vasyliev > Attachments: add_jta_1_2_into_deltaspike.patch > > > https://www.youtube.com/watch?v=rChkWy2NFyQ > The @Transactional annotation is already part of JavaEE, so there is no need > to have custom one. > The idea is to reuse code from JTA implementation. The one which already > supports 1.2 is Jbosstm(Narayana). I've made an attempt to incorporate it > into deltaspike. Please see attached changes and testcase. > Few notes on it: > - The producers for openwebbeans and weld are different, I've made > openwebbeans ones > - There is 2 system preferences which needs to be set to make narayana create > system folders under proper location (see surefire plugin config) > - Latest hibernate can autodetect JTA platform > - EntityManager created outside of JTA transaction can't join it > automatically, thats why there is proxy which join EM into > (http://stackoverflow.com/questions/9182/skipping-jta-sync-registration-due-to-auto-join-checking/11124021#11124021) > - Code based on this examples: > https://github.com/jbosstm/quickstart/tree/master/ArjunaJTA/standalone-jta-1_2 > - I did not make attempt to create generic datasource registration function, > this maybe subject for other issue -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (DELTASPIKE-473) Add support for javax.transaction.Transactional annotation added in JTA 1.2 spec
[ https://issues.apache.org/jira/browse/DELTASPIKE-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858089#comment-13858089 ] Ivan Vasyliev edited comment on DELTASPIKE-473 at 12/28/13 6:14 PM: I'm not sure why you closed this feature request because of issue in one particular proposed solution, but anyway: I compiled example on how to plug my patch into deltaspike w/o affecting its core deps: https://github.com/vasilievip/cdi-jpa-jta-generic-dao. Maybe it makes sense to keep this issue open? I see, for example, one can update @Transactional annotation from deltaspike to be JTA 1.2 compliant. There are many ways to get this done, my attempt is one of them. was (Author: vasilievip): I'm not sure why you closed this feature request because of issue in one proposed solution, but anyway: I compiled example on how to plug my patch into deltaspike w/o affecting its core deps: https://github.com/vasilievip/cdi-jpa-jta-generic-dao. Maybe it makes sense to keep this issue open? I see foe example one can update @Transactional annotation from deltaspike to be JTA 1.2 compliant. There are many ways to get this done, my attempt is one of them. > Add support for javax.transaction.Transactional annotation added in JTA 1.2 > spec > > > Key: DELTASPIKE-473 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-473 > Project: DeltaSpike > Issue Type: Improvement > Components: Data-Module, JPA-Module, TestControl >Affects Versions: 0.6 >Reporter: Ivan Vasyliev > Attachments: add_jta_1_2_into_deltaspike.patch > > > https://www.youtube.com/watch?v=rChkWy2NFyQ > The @Transactional annotation is already part of JavaEE, so there is no need > to have custom one. > The idea is to reuse code from JTA implementation. The one which already > supports 1.2 is Jbosstm(Narayana). I've made an attempt to incorporate it > into deltaspike. Please see attached changes and testcase. > Few notes on it: > - The producers for openwebbeans and weld are different, I've made > openwebbeans ones > - There is 2 system preferences which needs to be set to make narayana create > system folders under proper location (see surefire plugin config) > - Latest hibernate can autodetect JTA platform > - EntityManager created outside of JTA transaction can't join it > automatically, thats why there is proxy which join EM into > (http://stackoverflow.com/questions/9182/skipping-jta-sync-registration-due-to-auto-join-checking/11124021#11124021) > - Code based on this examples: > https://github.com/jbosstm/quickstart/tree/master/ArjunaJTA/standalone-jta-1_2 > - I did not make attempt to create generic datasource registration function, > this maybe subject for other issue -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-473) Add support for javax.transaction.Transactional annotation added in JTA 1.2 spec
[ https://issues.apache.org/jira/browse/DELTASPIKE-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858089#comment-13858089 ] Ivan Vasyliev commented on DELTASPIKE-473: -- I'm not sure why you closed this feature request because of issue in one proposed solution, but anyway: I compiled example on how to plug my patch into deltaspike w/o affecting its core deps: https://github.com/vasilievip/cdi-jpa-jta-generic-dao. Maybe it makes sense to keep this issue open? I see foe example one can update @Transactional annotation from deltaspike to be JTA 1.2 compliant. There are many ways to get this done, my attempt is one of them. > Add support for javax.transaction.Transactional annotation added in JTA 1.2 > spec > > > Key: DELTASPIKE-473 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-473 > Project: DeltaSpike > Issue Type: Improvement > Components: Data-Module, JPA-Module, TestControl >Affects Versions: 0.6 >Reporter: Ivan Vasyliev > Attachments: add_jta_1_2_into_deltaspike.patch > > > https://www.youtube.com/watch?v=rChkWy2NFyQ > The @Transactional annotation is already part of JavaEE, so there is no need > to have custom one. > The idea is to reuse code from JTA implementation. The one which already > supports 1.2 is Jbosstm(Narayana). I've made an attempt to incorporate it > into deltaspike. Please see attached changes and testcase. > Few notes on it: > - The producers for openwebbeans and weld are different, I've made > openwebbeans ones > - There is 2 system preferences which needs to be set to make narayana create > system folders under proper location (see surefire plugin config) > - Latest hibernate can autodetect JTA platform > - EntityManager created outside of JTA transaction can't join it > automatically, thats why there is proxy which join EM into > (http://stackoverflow.com/questions/9182/skipping-jta-sync-registration-due-to-auto-join-checking/11124021#11124021) > - Code based on this examples: > https://github.com/jbosstm/quickstart/tree/master/ArjunaJTA/standalone-jta-1_2 > - I did not make attempt to create generic datasource registration function, > this maybe subject for other issue -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (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-tabpanel&focusedCommentId=13858041#comment-13858041
]
Gerhard Petracek edited comment on DELTASPIKE-399 at 12/28/13 3:33 PM:
---
@john: we can change it once owb 1.2.2 is released (but not the enum-value for
1.2.x), since it doesn't need to implement this cdi 1.1 rule.
@christian:
if we just test the stream in the producer and return a custom InputStream as
proxy instead (which knows the path and opens a real stream lazily), we could
reduce the impact.
was (Author: gpetracek):
@john: we can change it once owb 1.2.2 is released, since it doesn't need to
implement this cdi 1.1 rule.
@christian:
if we just test the stream in the producer and return a custom InputStream as
proxy instead (which knows the path and opens a real stream lazily), we could
reduce the impact.
> 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
>
> Attachments: DELTASPIKE-399_merged_interface.patch
>
>
> Seam 3's Solder module had some nice resource loading functionality within
> the org.jboss.solder.resourceLoader packages. With it you could do the
> following:
> // Load a properties file
> @Inject @Resource("app.properties")
> private Properties appProperties;
> or:
> @Inject
> private ResourceProvider resourceProvider
> public Properties getHostProperties() {
>String hostname = java.net.InetAddress.getLocalHost().getHostName();
>return resourceProvider.loadPropertiesBundle(hostname + ".properties");
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-399) Incorporate Solder's ResourceLoader features into DeltaSpike
[
https://issues.apache.org/jira/browse/DELTASPIKE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858041#comment-13858041
]
Gerhard Petracek commented on DELTASPIKE-399:
-
@john: we can change it once owb 1.2.2 is released, since it doesn't need to
implement this cdi 1.1 rule.
@christian:
if we just test the stream in the producer and return a custom InputStream as
proxy instead (which knows the path and opens a real stream lazily), we could
reduce the impact.
> 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
>
> Attachments: DELTASPIKE-399_merged_interface.patch
>
>
> Seam 3's Solder module had some nice resource loading functionality within
> the org.jboss.solder.resourceLoader packages. With it you could do the
> following:
> // Load a properties file
> @Inject @Resource("app.properties")
> private Properties appProperties;
> or:
> @Inject
> private ResourceProvider resourceProvider
> public Properties getHostProperties() {
>String hostname = java.net.InetAddress.getLocalHost().getHostName();
>return resourceProvider.loadPropertiesBundle(hostname + ".properties");
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-399) Incorporate Solder's ResourceLoader features into DeltaSpike
[
https://issues.apache.org/jira/browse/DELTASPIKE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858040#comment-13858040
]
John D. Ament commented on DELTASPIKE-399:
--
We need to fix the CdiImplementation enum, since the OWB limitation is fixed in
OWB 1.2.2. The test will get incorrectly skipped in OWB 1.2.2.
> 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
>
> Attachments: DELTASPIKE-399_merged_interface.patch
>
>
> Seam 3's Solder module had some nice resource loading functionality within
> the org.jboss.solder.resourceLoader packages. With it you could do the
> following:
> // Load a properties file
> @Inject @Resource("app.properties")
> private Properties appProperties;
> or:
> @Inject
> private ResourceProvider resourceProvider
> public Properties getHostProperties() {
>String hostname = java.net.InetAddress.getLocalHost().getHostName();
>return resourceProvider.loadPropertiesBundle(hostname + ".properties");
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-399) Incorporate Solder's ResourceLoader features into DeltaSpike
[
https://issues.apache.org/jira/browse/DELTASPIKE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858039#comment-13858039
]
Gerhard Petracek commented on DELTASPIKE-399:
-
+1 and the same is true for the 2nd #close if the first one fails
> 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
>
> Attachments: DELTASPIKE-399_merged_interface.patch
>
>
> Seam 3's Solder module had some nice resource loading functionality within
> the org.jboss.solder.resourceLoader packages. With it you could do the
> following:
> // Load a properties file
> @Inject @Resource("app.properties")
> private Properties appProperties;
> or:
> @Inject
> private ResourceProvider resourceProvider
> public Properties getHostProperties() {
>String hostname = java.net.InetAddress.getLocalHost().getHostName();
>return resourceProvider.loadPropertiesBundle(hostname + ".properties");
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-399) Incorporate Solder's ResourceLoader features into DeltaSpike
[
https://issues.apache.org/jira/browse/DELTASPIKE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858036#comment-13858036
]
John D. Ament commented on DELTASPIKE-399:
--
I fixed an issue where the patch was not closing streams that were opened,
leading to memory leaks.
Since we didn't reach a usable solution in this, I'm going to add support for
multi InputStreams (via list) in case they expect multiple. (I was really
hoping to not have to add this)
> 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
>
> Attachments: DELTASPIKE-399_merged_interface.patch
>
>
> Seam 3's Solder module had some nice resource loading functionality within
> the org.jboss.solder.resourceLoader packages. With it you could do the
> following:
> // Load a properties file
> @Inject @Resource("app.properties")
> private Properties appProperties;
> or:
> @Inject
> private ResourceProvider resourceProvider
> public Properties getHostProperties() {
>String hostname = java.net.InetAddress.getLocalHost().getHostName();
>return resourceProvider.loadPropertiesBundle(hostname + ".properties");
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (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
]
Gerhard Petracek updated DELTASPIKE-399:
Attachment: (was: DELTASPIKE-399_ambiguous_file_check.patch)
> 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
>
> Attachments: DELTASPIKE-399_merged_interface.patch
>
>
> Seam 3's Solder module had some nice resource loading functionality within
> the org.jboss.solder.resourceLoader packages. With it you could do the
> following:
> // Load a properties file
> @Inject @Resource("app.properties")
> private Properties appProperties;
> or:
> @Inject
> private ResourceProvider resourceProvider
> public Properties getHostProperties() {
>String hostname = java.net.InetAddress.getLocalHost().getHostName();
>return resourceProvider.loadPropertiesBundle(hostname + ".properties");
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (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-tabpanel&focusedCommentId=13857621#comment-13857621
]
Gerhard Petracek edited comment on DELTASPIKE-399 at 12/28/13 1:19 PM:
---
@john:
i changed it quickly for an easier discussion -> please have a look at the
patch (DELTASPIKE-399_merged_interface.patch - applies on
aa9cf17b224c912824ed09e359cb25d9b74ea3f3).
was (Author: gpetracek):
@john:
i changed it quickly for an easier discussion -> please have a look at the
patch (DELTASPIKE-399_merged_interface.patch).
> 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
>
> Attachments: DELTASPIKE-399_ambiguous_file_check.patch,
> DELTASPIKE-399_merged_interface.patch
>
>
> Seam 3's Solder module had some nice resource loading functionality within
> the org.jboss.solder.resourceLoader packages. With it you could do the
> following:
> // Load a properties file
> @Inject @Resource("app.properties")
> private Properties appProperties;
> or:
> @Inject
> private ResourceProvider resourceProvider
> public Properties getHostProperties() {
>String hostname = java.net.InetAddress.getLocalHost().getHostName();
>return resourceProvider.loadPropertiesBundle(hostname + ".properties");
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-399) Incorporate Solder's ResourceLoader features into DeltaSpike
[
https://issues.apache.org/jira/browse/DELTASPIKE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13857996#comment-13857996
]
Christian Kaltepoth commented on DELTASPIKE-399:
@ [~struberg]: I agree with John that injecting a Properties object is _not_
the main usecase of this feature. The idea is to be able to inject all kind of
stuff like XML documents, images, other binary data, etc. But I agree that
injecting an InputStream may be problematic. Either we tell users to inject
Instance instead or we create some class that allows to open the
InputStream several times.
> 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
>
> Attachments: DELTASPIKE-399_ambiguous_file_check.patch,
> DELTASPIKE-399_merged_interface.patch
>
>
> Seam 3's Solder module had some nice resource loading functionality within
> the org.jboss.solder.resourceLoader packages. With it you could do the
> following:
> // Load a properties file
> @Inject @Resource("app.properties")
> private Properties appProperties;
> or:
> @Inject
> private ResourceProvider resourceProvider
> public Properties getHostProperties() {
>String hostname = java.net.InetAddress.getLocalHost().getHostName();
>return resourceProvider.loadPropertiesBundle(hostname + ".properties");
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (DELTASPIKE-481) Use unique archive names in Servlet module integration tests
[
https://issues.apache.org/jira/browse/DELTASPIKE-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Kaltepoth updated DELTASPIKE-481:
---
Description: As pointed out by [~gpetracek] in DELTASPIKE-399, integration
test archives should have unique names to prevent problems with Arquillian's
deploymentExportPath. (was: As pointed out by [~gpetracek] in DELTASPIKE-399,
integration test archives should have unique names to prevent problems with
Arquillian's {{deploymentExportPath}}.)
> Use unique archive names in Servlet module integration tests
>
>
> Key: DELTASPIKE-481
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-481
> Project: DeltaSpike
> Issue Type: Task
> Components: Servlet-Module
>Affects Versions: 0.5
>Reporter: Christian Kaltepoth
>Assignee: Christian Kaltepoth
>Priority: Minor
>
> As pointed out by [~gpetracek] in DELTASPIKE-399, integration test archives
> should have unique names to prevent problems with Arquillian's
> deploymentExportPath.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (DELTASPIKE-481) Use unique archive names in Servlet module integration tests
Christian Kaltepoth created DELTASPIKE-481:
--
Summary: Use unique archive names in Servlet module integration
tests
Key: DELTASPIKE-481
URL: https://issues.apache.org/jira/browse/DELTASPIKE-481
Project: DeltaSpike
Issue Type: Task
Components: Servlet-Module
Affects Versions: 0.5
Reporter: Christian Kaltepoth
Assignee: Christian Kaltepoth
Priority: Minor
As pointed out by [~gpetracek] in DELTASPIKE-399, integration test archives
should have unique names to prevent problems with Arquillian's
{{deploymentExportPath}}.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
