[jira] [Commented] (DELTASPIKE-1126) variable support in ConfigResolver

2016-04-16 Thread John D. Ament (JIRA) 

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15244196#comment-15244196
 ] 

John D. Ament commented on DELTASPIKE-1126:
---

Since this is a new feature, should it be 1.6.1?

> variable support in ConfigResolver
> --
>
> Key: DELTASPIKE-1126
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1126
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.6.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.6.1
>
>
> I'd like to implement the following feature in ConfigResolver:
> {code}
> myapp.someapp.soap.endpoint=${someapp.host.url}/someservice/myendpoint
> {code}
> and 
> {code}
> someapp.host.url=http://localhost:8081
> {code}
> Of course this is a behaviour which needs to be enabled for each config 
> resolving.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1112) Document - getting started w/ DeltaSpike using Gradle

2016-04-16 Thread John D. Ament (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1112:
--
Fix Version/s: 1.6.1

This is pretty much wrapped up.

> Document - getting started w/ DeltaSpike using Gradle
> -
>
> Key: DELTASPIKE-1112
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1112
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 1.6.0
> Environment: Gradle
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.6.1
>
>
> Most users look at the docs and see maven.  Also provide gradle equivalents, 
> as there are some nuances with Gradle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (DELTASPIKE-1126) variable support in ConfigResolver

2016-04-16 Thread Mark Struberg (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg reopened DELTASPIKE-1126:
---

reopening as I'm not yet finished. 
See the discussion on the mailing list. Would love to make ConfigResolver 
default behaviour to pick up variables true by default.

> variable support in ConfigResolver
> --
>
> Key: DELTASPIKE-1126
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1126
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.6.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.6.1
>
>
> I'd like to implement the following feature in ConfigResolver:
> {code}
> myapp.someapp.soap.endpoint=${someapp.host.url}/someservice/myendpoint
> {code}
> and 
> {code}
> someapp.host.url=http://localhost:8081
> {code}
> Of course this is a behaviour which needs to be enabled for each config 
> resolving.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-680) Lazy init should not rely on BeanManagerProvider

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-680:

Fix Version/s: (was: 1.6.1)

> Lazy init should not rely on BeanManagerProvider
> 
>
> Key: DELTASPIKE-680
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-680
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.0.1
>Reporter: Harald Wellmann
>Assignee: Mark Struberg
>
> Trying to work with DeltaSpike Data in OSGi (with on-the-fly OSGification, 
> see DELTASPIKE-660), I found that things break when the TCCL is not set to 
> the classloader of the current repository.
> This is caused by lazy initialization of {{RepositoryComponent}} using 
> {{BeanManagerProvider}}.
> Now the current strategies of {{BeanManagerProvider}} to locate the "current" 
> {{BeanManager}} do not work in OSGi where each bundle may have its own 
> BeanManager and there is no obvious interpretation of "current", and the TCCL 
> is not by default set to anything useful for this problem.
> However, in the context of DeltaSpike Data, is it easy to avoid the 
> {{BeanManagerProvider}} even with lazy initialization. The correct 
> {{BeanManager}} is known when a {{RepositoryComponent}} is instantiated, so 
> its sufficient to keep a reference to this {{BeanManager}} to perform lazy 
> initialization.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1126) variable support in ConfigResolver

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1126.
--
Resolution: Fixed

> variable support in ConfigResolver
> --
>
> Key: DELTASPIKE-1126
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1126
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.6.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.6.1
>
>
> I'd like to implement the following feature in ConfigResolver:
> {code}
> myapp.someapp.soap.endpoint=${someapp.host.url}/someservice/myendpoint
> {code}
> and 
> {code}
> someapp.host.url=http://localhost:8081
> {code}
> Of course this is a behaviour which needs to be enabled for each config 
> resolving.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1104) Import Microscoped scopes into DeltaSpike

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1104:
-
Fix Version/s: (was: 1.6.1)
   1.7.0

> Import Microscoped scopes into DeltaSpike
> -
>
> Key: DELTASPIKE-1104
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1104
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Core, Servlet-Module, Timer-Module
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.7.0
>
>
> Import the newly created microscoped scopes into DeltaSpike.
> Some high level mappings
> MethodScoped -> Core
> DomainScoped -> Servlet
> HeaderScoped -> Servlet
> TimerScoped -> New module?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1112) Document - getting started w/ DeltaSpike using Gradle

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1112:
-
Fix Version/s: (was: 1.6.1)

> Document - getting started w/ DeltaSpike using Gradle
> -
>
> Key: DELTASPIKE-1112
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1112
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 1.6.0
> Environment: Gradle
>Reporter: John D. Ament
>Assignee: John D. Ament
>
> Most users look at the docs and see maven.  Also provide gradle equivalents, 
> as there are some nuances with Gradle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-872) Support mocking on proxied beans

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-872:

Fix Version/s: (was: 1.6.1)

> Support mocking on proxied beans
> 
>
> Key: DELTASPIKE-872
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-872
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: TestControl
>Affects Versions: 1.3.0
>Reporter: Rafael
>Assignee: Thomas Andraschko
>
> Currently test control mock feature is not supported on proxies (e.g: beans 
> with interceptors), a sample test which fails because of this limitation can 
> be found here: 
> https://github.com/rmpestano/ee6-ds-demo/blob/master/src/test/java/org/os890/demo/ee6/test/MockTest.java
>  
> .
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1110) Document new async capabilities

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1110:
-
Fix Version/s: (was: 1.6.1)

> Document new async capabilities
> ---
>
> Key: DELTASPIKE-1110
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1110
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core, Documentation
>Affects Versions: 1.6.0
>Reporter: John D. Ament
>Assignee: John D. Ament
>
> DeltaSpike 1.6.0 added some new Async capabilities.  Those should be 
> documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1033) BeanManagerProvider might create mem leaks

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1033:
-
Fix Version/s: (was: 1.6.1)

> BeanManagerProvider might create mem leaks
> --
>
> Key: DELTASPIKE-1033
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1033
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.5.1
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>
> We currently use a Map in BeanManagerProvider. 
> This is a class 1 candidate to generate mem leaks when a webapp gets 
> undeployed. We should switch to using WeakReferences instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-724) upgrade version of the tomee-arquillian adapter

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-724:

Fix Version/s: (was: 1.6.1)

> upgrade version of the tomee-arquillian adapter
> ---
>
> Key: DELTASPIKE-724
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-724
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Build, Tests
>Reporter: Gerhard Petracek
>Assignee: Romain Manni-Bucau
>
> to test against tomee 1.7.1



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-813) improve basic core documentation

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-813:

Fix Version/s: (was: 1.6.1)

> improve basic core documentation
> 
>
> Key: DELTASPIKE-813
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-813
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Documentation
>Affects Versions: 1.2.1
>Reporter: Gerhard Petracek
>Assignee: Rafael Benevides
>
> in this first step we should improve everything which is marked red or yellow 
> in the documentation column and green or yellow in the "importance for 
> average users" column ( see 
> https://cwiki.apache.org/confluence/display/DeltaSpike/DS-Core+Overview )



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DELTASPIKE-1022) Add support for evaluating access decision voters (defined for @Secured views) after processing view parameters

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek closed DELTASPIKE-1022.


> Add support for evaluating access decision voters (defined for @Secured 
> views) after processing view parameters
> ---
>
> Key: DELTASPIKE-1022
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1022
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: JSF-Module
>Affects Versions: 1.5.1
>Reporter: Juan Pablo Angamarca
>Priority: Minor
>
> Deltaspike allows for securing views with access decision voters by 
> annotating the view config classes in a typesafe view-config (@Secured). The 
> issue I'm experiencing is, ADVs are evaluated before page parameters are set, 
> and authorization could depend on page parameters, (example: a page that 
> serves to create and edit entities, depending on a entity-id passed to it, 
> or, a particular property of the entity with the passed id).
> The sample application application that demonstrates this can be found at 
> https://github.com/jpangamarca/deltaspike-authorization-demo (there you'll 
> find instructions for running it), and works like this (it is very 
> simplistic, for the sake of demonstration):
> - There are two users, 'john' and 'peter'. john is authorized to create and 
> edit employees, and peter is authorized for edits only (permission codes are 
> 'employee.create' and 'employee.edit', and are stored in a set in User.java). 
> A reference to the currently logged-in user is stored in the UserSession 
> session-scoped bean. The currently logged-in user can be changed at the 
> homepage.
> - The application has a employee.xhtml page. If an employee id is not 
> provided, the page will be used to create a employee. If an id is passed, it 
> will be used to edit an employee.
> - The ADV checks for the id passed to the page to find out what permission 
> the user needs to access the page. But it is evaluated before the id is set 
> (via a page parameter), resulting on 'peter' being unable to edit employees 
> (the id is not set = 'employee.create' is required) and 'john' being 
> authorized with the wrong permission (he has the 'employee.create' 
> permission, but should be authorized with 'employee.edit'). See application 
> logging.
> Seam, for example, evaluates page parameters first, then restrict expressions 
> (analogous to ADVs) and then page actions (see Seam pages.xml: 
> http://shrubbery.homeip.net/c/display/W/Seam+pages.xml#Seampagesxml-restrictrestrict).
>  My Seam application (which I'm porting to CDI) works without any problems 
> with these authorization requirements.
> The application implements a Deltaspike exception handler, which handles the 
> authorization violations.
> Is there any chance to support this kind of authorization requirements?
> Thanks for your attention.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (DELTASPIKE-1006) document @Transactional and @TransactionScoped support for @Repository

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek reassigned DELTASPIKE-1006:


Assignee: Gerhard Petracek

> document @Transactional and @TransactionScoped support for @Repository
> --
>
> Key: DELTASPIKE-1006
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1006
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Data-Module, Documentation
>Affects Versions: 1.5.1
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
> Fix For: 1.6.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1022) Add support for evaluating access decision voters (defined for @Secured views) after processing view parameters

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1022.
--
Resolution: Later

if there are further users interested in it and there isn't a (simple) 
workaround, please re-open the ticket.

> Add support for evaluating access decision voters (defined for @Secured 
> views) after processing view parameters
> ---
>
> Key: DELTASPIKE-1022
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1022
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: JSF-Module
>Affects Versions: 1.5.1
>Reporter: Juan Pablo Angamarca
>Priority: Minor
>
> Deltaspike allows for securing views with access decision voters by 
> annotating the view config classes in a typesafe view-config (@Secured). The 
> issue I'm experiencing is, ADVs are evaluated before page parameters are set, 
> and authorization could depend on page parameters, (example: a page that 
> serves to create and edit entities, depending on a entity-id passed to it, 
> or, a particular property of the entity with the passed id).
> The sample application application that demonstrates this can be found at 
> https://github.com/jpangamarca/deltaspike-authorization-demo (there you'll 
> find instructions for running it), and works like this (it is very 
> simplistic, for the sake of demonstration):
> - There are two users, 'john' and 'peter'. john is authorized to create and 
> edit employees, and peter is authorized for edits only (permission codes are 
> 'employee.create' and 'employee.edit', and are stored in a set in User.java). 
> A reference to the currently logged-in user is stored in the UserSession 
> session-scoped bean. The currently logged-in user can be changed at the 
> homepage.
> - The application has a employee.xhtml page. If an employee id is not 
> provided, the page will be used to create a employee. If an id is passed, it 
> will be used to edit an employee.
> - The ADV checks for the id passed to the page to find out what permission 
> the user needs to access the page. But it is evaluated before the id is set 
> (via a page parameter), resulting on 'peter' being unable to edit employees 
> (the id is not set = 'employee.create' is required) and 'john' being 
> authorized with the wrong permission (he has the 'employee.create' 
> permission, but should be authorized with 'employee.edit'). See application 
> logging.
> Seam, for example, evaluates page parameters first, then restrict expressions 
> (analogous to ADVs) and then page actions (see Seam pages.xml: 
> http://shrubbery.homeip.net/c/display/W/Seam+pages.xml#Seampagesxml-restrictrestrict).
>  My Seam application (which I'm porting to CDI) works without any problems 
> with these authorization requirements.
> The application implements a Deltaspike exception handler, which handles the 
> authorization violations.
> Is there any chance to support this kind of authorization requirements?
> Thanks for your attention.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1037) add support for constructor taking a single String parameter or fromString static method for @ConfigProperty

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1037:
-
Assignee: Mark Struberg  (was: Romain Manni-Bucau)

> add support for constructor taking a single String parameter or fromString 
> static method for @ConfigProperty
> 
>
> Key: DELTASPIKE-1037
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1037
> Project: DeltaSpike
>  Issue Type: New Feature
>Affects Versions: 1.5.1
>Reporter: Romain Manni-Bucau
>Assignee: Mark Struberg
> Attachments: DELTASPIKE-generic-config.patch
>
>
> Support injection of unknown types if they take a String as parameter or have 
> a static fromString(String) method



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1128) add deltaspike.future.timeout to CoreBaseConfig

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1128.
--
Resolution: Fixed

> add deltaspike.future.timeout to CoreBaseConfig
> ---
>
> Key: DELTASPIKE-1128
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1128
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Core
>Affects Versions: 1.6.0
>Reporter: Gerhard Petracek
> Fix For: 1.6.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1032) document creating quartz scheduling jobs at runtime

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1032:
-
Fix Version/s: 1.6.1

> document creating quartz scheduling jobs at runtime
> ---
>
> Key: DELTASPIKE-1032
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1032
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Pablo Pita Leira
>Assignee: Gerhard Petracek
>Priority: Minor
> Fix For: 1.6.1
>
> Attachments: scheduler.adoc
>
>
> In certain cases the scheduling jobs have to be created at runtime, for 
> example, because the configuration details like polling intervals for the 
> jobs are given at runtime or because the number of jobs to be executed is 
> unknown. This case should be documented as well. 
> In this case, unwrap Deltaspike's jobScheduler and work directly with the 
> base (Quartz) Scheduler instance. 
> As we are still using the (Quartz) JobFactory provided by DeltaSpike, the 
> jobs created get their dependencies via CDI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1032) document creating quartz scheduling jobs at runtime

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1032.
--
Resolution: Fixed

> document creating quartz scheduling jobs at runtime
> ---
>
> Key: DELTASPIKE-1032
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1032
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Pablo Pita Leira
>Assignee: Gerhard Petracek
>Priority: Minor
> Fix For: 1.6.1
>
> Attachments: scheduler.adoc
>
>
> In certain cases the scheduling jobs have to be created at runtime, for 
> example, because the configuration details like polling intervals for the 
> jobs are given at runtime or because the number of jobs to be executed is 
> unknown. This case should be documented as well. 
> In this case, unwrap Deltaspike's jobScheduler and work directly with the 
> base (Quartz) Scheduler instance. 
> As we are still using the (Quartz) JobFactory provided by DeltaSpike, the 
> jobs created get their dependencies via CDI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1006) document @Transactional and @TransactionScoped support for @Repository

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1006.
--
Resolution: Fixed

> document @Transactional and @TransactionScoped support for @Repository
> --
>
> Key: DELTASPIKE-1006
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1006
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Data-Module, Documentation
>Affects Versions: 1.5.1
>Reporter: Gerhard Petracek
> Fix For: 1.6.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1113) WindowIdHtmlRenderer should skip DELEGATED

2016-04-16 Thread Thomas Andraschko (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved DELTASPIKE-1113.
---
Resolution: Fixed

> WindowIdHtmlRenderer should skip DELEGATED
> --
>
> Key: DELTASPIKE-1113
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1113
> Project: DeltaSpike
>  Issue Type: Task
>  Components: JSF-Module, JSF22-Module
>Affects Versions: 1.5.4
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
> Fix For: 1.6.1
>
>
> The WindowIdHtmlRenderer currently renders our script, also if DELEGATED is 
> used.
> As the windowhandling is completely delegated to JSF, we don't need our 
> scripts here - also windowhandler.js currently does NOTHING when DELEGATED is 
> used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-1128) add deltaspike.future.timeout to CoreBaseConfig

2016-04-16 Thread Gerhard Petracek (JIRA) 
Gerhard Petracek created DELTASPIKE-1128:


 Summary: add deltaspike.future.timeout to CoreBaseConfig
 Key: DELTASPIKE-1128
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1128
 Project: DeltaSpike
  Issue Type: Task
  Components: Core
Affects Versions: 1.6.0
Reporter: Gerhard Petracek
 Fix For: 1.6.1






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1116:
-
Fix Version/s: 1.6.1

> CdiTestRunner injects test class fields twice
> -
>
> Key: DELTASPIKE-1116
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: TestControl
>Affects Versions: 1.6.0
> Environment: Apache Maven 3.2.5 
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\Program Files\apache-maven-3.2.5
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Falko Modler
>Assignee: Gerhard Petracek
>Priority: Minor
> Fix For: 1.6.1
>
> Attachments: DELTASPIKE-1116.zip
>
>
> {{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in 
> {{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes 
> it possible to use injected beans in a {{@Before}} method or even in a JUnit 
> {{TestRule}}.
> But shortly before executing the actual test method, 
> {{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*, 
> overwriting any changes that have been made to the fields in a JUnit 
> {{TestRule}} or a {{@Before}} method in the test.
> The second injection was introduced by DELTASPIKE-342:
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
> I don't know why there needs to be a second injection at all.
> All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
> PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which 
> is the default value.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-1116:
-
Affects Version/s: (was: 1.5.4)
   (was: 1.0.2)

> CdiTestRunner injects test class fields twice
> -
>
> Key: DELTASPIKE-1116
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: TestControl
>Affects Versions: 1.6.0
> Environment: Apache Maven 3.2.5 
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\Program Files\apache-maven-3.2.5
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Falko Modler
>Assignee: Gerhard Petracek
>Priority: Minor
> Fix For: 1.6.1
>
> Attachments: DELTASPIKE-1116.zip
>
>
> {{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in 
> {{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes 
> it possible to use injected beans in a {{@Before}} method or even in a JUnit 
> {{TestRule}}.
> But shortly before executing the actual test method, 
> {{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*, 
> overwriting any changes that have been made to the fields in a JUnit 
> {{TestRule}} or a {{@Before}} method in the test.
> The second injection was introduced by DELTASPIKE-342:
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
> I don't know why there needs to be a second injection at all.
> All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
> PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which 
> is the default value.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1120) LockedInterceptor needs to use an InterceptorStrategy

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1120.
--
Resolution: Fixed

> LockedInterceptor needs to use an InterceptorStrategy
> -
>
> Key: DELTASPIKE-1120
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1120
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.6.0
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
> Fix For: 1.6.1
>
> Attachments: DELTASPIKE_1120.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1119) FutureableInterceptor needs to use an InterceptorStrategy

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1119.
--
Resolution: Fixed

> FutureableInterceptor needs to use an InterceptorStrategy
> -
>
> Key: DELTASPIKE-1119
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1119
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.6.0
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
> Fix For: 1.6.1
>
> Attachments: DELTASPIKE_1119.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1118) ThrottledInterceptor needs to use an InterceptorStrategy

2016-04-16 Thread Gerhard Petracek (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved DELTASPIKE-1118.
--
Resolution: Fixed

> ThrottledInterceptor needs to use an InterceptorStrategy
> 
>
> Key: DELTASPIKE-1118
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1118
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.6.0
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
> Fix For: 1.6.1
>
> Attachments: DELTASPIKE_1118.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)