[jira] [Commented] (DELTASPIKE-1126) variable support in ConfigResolver
[ https://issues.apache.org/jira/browse/DELTASPIKE-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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-680) Lazy init should not rely on BeanManagerProvider
[ https://issues.apache.org/jira/browse/DELTASPIKE-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-680: Assignee: Mark Struberg (was: Harald Wellmann) > 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 > Fix For: 1.6.1 > > > 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] [Updated] (DELTASPIKE-1033) BeanManagerProvider might create mem leaks
[ 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
[ 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
[ 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)
first steps for the next release
hi @ all, if there are no objections, i will start with the first steps for the next release (v1.6.1) by the end of next week. regards, gerhard
[jira] [Closed] (DELTASPIKE-1022) Add support for evaluating access decision voters (defined for @Secured views) after processing view parameters
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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-1006) document @Transactional and @TransactionScoped support for @Repository
[ https://issues.apache.org/jira/browse/DELTASPIKE-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-1006: - Fix Version/s: 1.6.1 > 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] [Updated] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice
[ 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
[ 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
[ 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
[ 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
[ 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)