[jira] [Commented] (DELTASPIKE-1325) actively release ConfigSources and ConfigFilters if they implement Autocloseable
[ https://issues.apache.org/jira/browse/DELTASPIKE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425305#comment-16425305 ] ASF subversion and git services commented on DELTASPIKE-1325: - Commit 1e5003f92816ad6a55e57c81de9c0b2a1f9fe092 in deltaspike's branch refs/heads/master from [~struberg] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=1e5003f ] DELTASPIKE-1325 add documentation > actively release ConfigSources and ConfigFilters if they implement > Autocloseable > > > Key: DELTASPIKE-1325 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1325 > Project: DeltaSpike > Issue Type: Task > Components: Configuration >Affects Versions: 1.9.0 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 1.9.0 > > > When releasing the Config we should invoke close() on all the ConfigSources > and ConfigFilters if they implement java.lang.Autocloseable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1335) allow atomic access to n different TypedResolver values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426815#comment-16426815
]
ASF subversion and git services commented on DELTASPIKE-1335:
-
Commit 0ec1c1e5bca85141ddbe164d50743c13b572e73b in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=0ec1c1e ]
DELTASPIKE-1335 DELTASPIKE-1277 fix reportChangeListener
Also implement the config change callback in the new
ConfigurableTestConfigSource
> allow atomic access to n different TypedResolver values
> ---
>
> Key: DELTASPIKE-1335
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1335
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Configuration
>Affects Versions: 1.9.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.0
>
>
> If multiple related config values (TypedResolver) are accessed in the same
> request and the underlying config changes then we might up with a wild
> mixture of old and new values.
> An example would be to access some 'myapp.host' and 'myapp.port':
> The underlying values are 'oldserver' and '8080'.
> Now consider the following code:
> {code}
> // get the current host value
> TypedResolver hostCfg config.resolve("myapp.host");
> // and right inbetween the underlying values get
> // changed to 'newserver' and port 8082
> // get the current port for the host
> TypedResolver portCfg config.resolve("myapp.port");
> {code}
> In ths above code we would get the combination of 'oldserver' but with the
> new port 8081. And this will obviously blow up because that host+port
> combination doesn't exist.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1277) Force refresh of cached config values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426816#comment-16426816
]
ASF subversion and git services commented on DELTASPIKE-1277:
-
Commit 0ec1c1e5bca85141ddbe164d50743c13b572e73b in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=0ec1c1e ]
DELTASPIKE-1335 DELTASPIKE-1277 fix reportChangeListener
Also implement the config change callback in the new
ConfigurableTestConfigSource
> Force refresh of cached config values
> -
>
> Key: DELTASPIKE-1277
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Configuration
>Reporter: Alexander Falb
>Assignee: Mark Struberg
>Priority: Major
> Attachments: central_caching.patch, forcerefresh.patch
>
>
> When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled,
> there is no way of bypassing the cache and forcefully reloading the value
> from underlying datasources.
> The attached patch is a proposal of creating such an mechanism. It introduces
> a {{void forceRefresh()}} method to the {{TypedResolver}}, implements this
> method by resetting the {{reloadAfter}} field and adds a unit test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1335) allow atomic access to n different TypedResolver values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426814#comment-16426814
]
ASF subversion and git services commented on DELTASPIKE-1335:
-
Commit a6296773d14db2339289179cf80ddb0339519229 in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=a629677 ]
DELTASPIKE-1335 improve docs and tst handling
hacked together with Alexander Falb (elexx)
> allow atomic access to n different TypedResolver values
> ---
>
> Key: DELTASPIKE-1335
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1335
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Configuration
>Affects Versions: 1.9.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.0
>
>
> If multiple related config values (TypedResolver) are accessed in the same
> request and the underlying config changes then we might up with a wild
> mixture of old and new values.
> An example would be to access some 'myapp.host' and 'myapp.port':
> The underlying values are 'oldserver' and '8080'.
> Now consider the following code:
> {code}
> // get the current host value
> TypedResolver hostCfg config.resolve("myapp.host");
> // and right inbetween the underlying values get
> // changed to 'newserver' and port 8082
> // get the current port for the host
> TypedResolver portCfg config.resolve("myapp.port");
> {code}
> In ths above code we would get the combination of 'oldserver' but with the
> new port 8081. And this will obviously blow up because that host+port
> combination doesn't exist.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1335) allow atomic access to n different TypedResolver values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426812#comment-16426812
]
ASF subversion and git services commented on DELTASPIKE-1335:
-
Commit fdd1e3dcd9a12ceed831dd7460492b6dd788721c in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=fdd1e3d ]
DELTASPIKE-1335 proposal for atomic config access
crafted together with Manfred Huber
> allow atomic access to n different TypedResolver values
> ---
>
> Key: DELTASPIKE-1335
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1335
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Configuration
>Affects Versions: 1.9.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.0
>
>
> If multiple related config values (TypedResolver) are accessed in the same
> request and the underlying config changes then we might up with a wild
> mixture of old and new values.
> An example would be to access some 'myapp.host' and 'myapp.port':
> The underlying values are 'oldserver' and '8080'.
> Now consider the following code:
> {code}
> // get the current host value
> TypedResolver hostCfg config.resolve("myapp.host");
> // and right inbetween the underlying values get
> // changed to 'newserver' and port 8082
> // get the current port for the host
> TypedResolver portCfg config.resolve("myapp.port");
> {code}
> In ths above code we would get the combination of 'oldserver' but with the
> new port 8081. And this will obviously blow up because that host+port
> combination doesn't exist.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1335) allow atomic access to n different TypedResolver values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428066#comment-16428066
]
ASF subversion and git services commented on DELTASPIKE-1335:
-
Commit 9c125bd010de5bcd60f66ba2c3b0c019f108a5e0 in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=9c125bd ]
DELTASPIKE-1335 rename ConfigTransaction to ConfigSnapshot
> allow atomic access to n different TypedResolver values
> ---
>
> Key: DELTASPIKE-1335
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1335
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Configuration
>Affects Versions: 1.9.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.0
>
>
> If multiple related config values (TypedResolver) are accessed in the same
> request and the underlying config changes then we might up with a wild
> mixture of old and new values.
> An example would be to access some 'myapp.host' and 'myapp.port':
> The underlying values are 'oldserver' and '8080'.
> Now consider the following code:
> {code}
> // get the current host value
> TypedResolver hostCfg config.resolve("myapp.host");
> // and right inbetween the underlying values get
> // changed to 'newserver' and port 8082
> // get the current port for the host
> TypedResolver portCfg config.resolve("myapp.port");
> {code}
> In ths above code we would get the combination of 'oldserver' but with the
> new port 8081. And this will obviously blow up because that host+port
> combination doesn't exist.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1319) labeled alternatives
[ https://issues.apache.org/jira/browse/DELTASPIKE-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439980#comment-16439980 ] ASF subversion and git services commented on DELTASPIKE-1319: - Commit 463a8c9b81f4ce3a1c64565748e25f72eeba7988 in deltaspike's branch refs/heads/master from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=463a8c9 ] DELTASPIKE-1319 additional tests for labeled alternatives > labeled alternatives > > > Key: DELTASPIKE-1319 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1319 > Project: DeltaSpike > Issue Type: New Feature > Components: Core, TestControl >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.8.2 > > > target setup: ds-testcontrol as well as containers like meecrowave which > support one instance per test-class, but deploy the whole application. > in several cases it's essential to bind alternative beans only to a subset of > all tests. > currently we just support that partially via the mock-support (which is very > limited in several cases). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1319) labeled alternatives
[ https://issues.apache.org/jira/browse/DELTASPIKE-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439983#comment-16439983 ] ASF subversion and git services commented on DELTASPIKE-1319: - Commit 8a131ed14c3c51da13d1fce56892e2c1edfe8053 in deltaspike's branch refs/heads/deltaspike-1.8.x from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=8a131ed ] DELTASPIKE-1319 additional tests for labeled alternatives > labeled alternatives > > > Key: DELTASPIKE-1319 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1319 > Project: DeltaSpike > Issue Type: New Feature > Components: Core, TestControl >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.8.2 > > > target setup: ds-testcontrol as well as containers like meecrowave which > support one instance per test-class, but deploy the whole application. > in several cases it's essential to bind alternative beans only to a subset of > all tests. > currently we just support that partially via the mock-support (which is very > limited in several cases). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1335) allow atomic access to n different TypedResolver values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445642#comment-16445642
]
ASF subversion and git services commented on DELTASPIKE-1335:
-
Commit aabbc879e389bfa3538cbdfa52a19fbfae904616 in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=aabbc87 ]
DELTASPIKE-1335 move access to configured value to TppedResolver
Feedback from Jeff Mesnil and Tomas Langer.
It will be easier to understand if the access to the effective value
is done via TypedResolver and ConfigSnapshot is merely a value holder.
> allow atomic access to n different TypedResolver values
> ---
>
> Key: DELTASPIKE-1335
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1335
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Configuration
>Affects Versions: 1.9.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.0
>
>
> If multiple related config values (TypedResolver) are accessed in the same
> request and the underlying config changes then we might up with a wild
> mixture of old and new values.
> An example would be to access some 'myapp.host' and 'myapp.port':
> The underlying values are 'oldserver' and '8080'.
> Now consider the following code:
> {code}
> // get the current host value
> TypedResolver hostCfg config.resolve("myapp.host");
> // and right inbetween the underlying values get
> // changed to 'newserver' and port 8082
> // get the current port for the host
> TypedResolver portCfg config.resolve("myapp.port");
> {code}
> In ths above code we would get the combination of 'oldserver' but with the
> new port 8081. And this will obviously blow up because that host+port
> combination doesn't exist.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1322) clean up ConfigResolver
[ https://issues.apache.org/jira/browse/DELTASPIKE-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445707#comment-16445707 ] ASF subversion and git services commented on DELTASPIKE-1322: - Commit a67888d4b666f0b492c1e410fa96056eec5f54ba in deltaspike's branch refs/heads/master from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=a67888d ] DELTASPIKE-1322 cleanup > clean up ConfigResolver > --- > > Key: DELTASPIKE-1322 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1322 > Project: DeltaSpike > Issue Type: Improvement > Components: Configuration >Affects Versions: 1.8.1 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 1.9.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1338) support class-filter per test
[
https://issues.apache.org/jira/browse/DELTASPIKE-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445711#comment-16445711
]
ASF subversion and git services commented on DELTASPIKE-1338:
-
Commit 6475f49ce82cf568430792b81b58117e41423b17 in deltaspike's branch
refs/heads/master from [~gpetracek]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=6475f49 ]
DELTASPIKE-1338 tests for @TestControl#classFilter
> support class-filter per test
> -
>
> Key: DELTASPIKE-1338
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1338
> Project: DeltaSpike
> Issue Type: New Feature
> Components: TestControl
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
>
> based on DELTASPIKE-1337 it should be possible to define a class-filter per
> test.
> it allows type-safe isolation for tests and with cdi 1.1+ e.g. to build
> labeled-alternatives without text-based config.
> a possible approach looks like:
> {code:java}
> @Retention(RUNTIME)
> @Target(TYPE)
> public @interface Labeled {
> Class value();
> }
> public abstract class AbstractLabeledAlternativeFilter implements ClassFilter
> {
> private final Class activeLabel;
> protected AbstractLabeledAlternativeFilter(Class TestControl.Label> activeLabel) {
> this.activeLabel = activeLabel;
> }
> @Override
> public boolean isFiltered(Class targetClass) {
> if (!targetClass.isAnnotationPresent(Alternative.class)) {
> return false;
> }
> Labeled labeled = targetClass.getAnnotation(Labeled.class);
> if (labeled == null) {
> return false;
> }
> if (labeled.value().equals(activeLabel)) {
> return false;
> }
> return true;
> }
> }
> {code}
> {code:java}
> @Labeled(Label1Test.Label1.class)
> @Alternative
> @Priority(1)
> public class MyLabeledAlternativeBean1 extends MyBean { /*...*/ }
> @RunWith(CdiTestRunner.class)
> @TestControl(activeAlternativeLabel = Label1Test.Label1.class, classFilter =
> Label1Test.Label1Filter.class)
> public class Label1Test {
> @Inject
> private MyBean myBean;
> //tests
> public static class Label1 implements TestControl.Label {
> }
> public static class Label1Filter extends AbstractLabeledAlternativeFilter
> {
> public Label1Filter() {
> super(Label1.class);
> }
> }
> }
> {code}
> besides that other custom concepts are possible as well (not even bound to
> alternative-beans).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1338) support class-filter per test
[
https://issues.apache.org/jira/browse/DELTASPIKE-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445709#comment-16445709
]
ASF subversion and git services commented on DELTASPIKE-1338:
-
Commit 1c187042577258360680de517151d748807ff6c8 in deltaspike's branch
refs/heads/master from [~gpetracek]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=1c18704 ]
DELTASPIKE-1338 support for ClassFilter per @TestControl test
> support class-filter per test
> -
>
> Key: DELTASPIKE-1338
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1338
> Project: DeltaSpike
> Issue Type: New Feature
> Components: TestControl
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
>
> based on DELTASPIKE-1337 it should be possible to define a class-filter per
> test.
> it allows type-safe isolation for tests and with cdi 1.1+ e.g. to build
> labeled-alternatives without text-based config.
> a possible approach looks like:
> {code:java}
> @Retention(RUNTIME)
> @Target(TYPE)
> public @interface Labeled {
> Class value();
> }
> public abstract class AbstractLabeledAlternativeFilter implements ClassFilter
> {
> private final Class activeLabel;
> protected AbstractLabeledAlternativeFilter(Class TestControl.Label> activeLabel) {
> this.activeLabel = activeLabel;
> }
> @Override
> public boolean isFiltered(Class targetClass) {
> if (!targetClass.isAnnotationPresent(Alternative.class)) {
> return false;
> }
> Labeled labeled = targetClass.getAnnotation(Labeled.class);
> if (labeled == null) {
> return false;
> }
> if (labeled.value().equals(activeLabel)) {
> return false;
> }
> return true;
> }
> }
> {code}
> {code:java}
> @Labeled(Label1Test.Label1.class)
> @Alternative
> @Priority(1)
> public class MyLabeledAlternativeBean1 extends MyBean { /*...*/ }
> @RunWith(CdiTestRunner.class)
> @TestControl(activeAlternativeLabel = Label1Test.Label1.class, classFilter =
> Label1Test.Label1Filter.class)
> public class Label1Test {
> @Inject
> private MyBean myBean;
> //tests
> public static class Label1 implements TestControl.Label {
> }
> public static class Label1Filter extends AbstractLabeledAlternativeFilter
> {
> public Label1Filter() {
> super(Label1.class);
> }
> }
> }
> {code}
> besides that other custom concepts are possible as well (not even bound to
> alternative-beans).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1337) optional ClassFilter spi
[ https://issues.apache.org/jira/browse/DELTASPIKE-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445708#comment-16445708 ] ASF subversion and git services commented on DELTASPIKE-1337: - Commit b7808929786eee130e9a724390ff148644d0b127 in deltaspike's branch refs/heads/master from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=b780892 ] DELTASPIKE-1337 optional ClassFilter > optional ClassFilter spi > > > Key: DELTASPIKE-1337 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1337 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.8.2 > > > in several cases it's needed to get rid of beans and/or pre-defined beans. > that's possible with @Exclude, @Vetoed, @Typed(), scan-tag and > ProcessAnnotatedType#veto. > only #veto supports really dynamic cases - esp. in cases you don't have the > class/es in question under your control (or diff. teams have diff. > requirements). > a simple (but optional) ClassFilter spi allows: > * full control (like with #veto - just simpler) > * the concept of overruling based on config-ordinals > * to get rid of special behaviors defined for alternative-beans (see e.g. > observers in alternative-beans) > * to use the concept itself for different features/use-cases > (e.g. a class-filter per test-class via @TestControl to support more isolated > tests) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1337) optional ClassFilter spi
[ https://issues.apache.org/jira/browse/DELTASPIKE-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445734#comment-16445734 ] ASF subversion and git services commented on DELTASPIKE-1337: - Commit f7c12d726216fcdb47a5ec0b25314cd14aca723c in deltaspike's branch refs/heads/deltaspike-1.8.x from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=f7c12d7 ] DELTASPIKE-1337 optional ClassFilter > optional ClassFilter spi > > > Key: DELTASPIKE-1337 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1337 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.8.2 > > > in several cases it's needed to get rid of beans and/or pre-defined beans. > that's possible with @Exclude, @Vetoed, @Typed(), scan-tag and > ProcessAnnotatedType#veto. > only #veto supports really dynamic cases - esp. in cases you don't have the > class/es in question under your control (or diff. teams have diff. > requirements). > a simple (but optional) ClassFilter spi allows: > * full control (like with #veto - just simpler) > * the concept of overruling based on config-ordinals > * to get rid of special behaviors defined for alternative-beans (see e.g. > observers in alternative-beans) > * to use the concept itself for different features/use-cases > (e.g. a class-filter per test-class via @TestControl to support more isolated > tests) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1338) support class-filter per test
[
https://issues.apache.org/jira/browse/DELTASPIKE-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445735#comment-16445735
]
ASF subversion and git services commented on DELTASPIKE-1338:
-
Commit 3f219d6fbf87186edcd934848bff80ae608a6af7 in deltaspike's branch
refs/heads/deltaspike-1.8.x from [~gpetracek]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=3f219d6 ]
DELTASPIKE-1338 support for ClassFilter per @TestControl test
> support class-filter per test
> -
>
> Key: DELTASPIKE-1338
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1338
> Project: DeltaSpike
> Issue Type: New Feature
> Components: TestControl
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
>
> based on DELTASPIKE-1337 it should be possible to define a class-filter per
> test.
> it allows type-safe isolation for tests and with cdi 1.1+ e.g. to build
> labeled-alternatives without text-based config.
> a possible approach looks like:
> {code:java}
> @Retention(RUNTIME)
> @Target(TYPE)
> public @interface Labeled {
> Class value();
> }
> public abstract class AbstractLabeledAlternativeFilter implements ClassFilter
> {
> private final Class activeLabel;
> protected AbstractLabeledAlternativeFilter(Class TestControl.Label> activeLabel) {
> this.activeLabel = activeLabel;
> }
> @Override
> public boolean isFiltered(Class targetClass) {
> if (!targetClass.isAnnotationPresent(Alternative.class)) {
> return false;
> }
> Labeled labeled = targetClass.getAnnotation(Labeled.class);
> if (labeled == null) {
> return false;
> }
> if (labeled.value().equals(activeLabel)) {
> return false;
> }
> return true;
> }
> }
> {code}
> {code:java}
> @Labeled(Label1Test.Label1.class)
> @Alternative
> @Priority(1)
> public class MyLabeledAlternativeBean1 extends MyBean { /*...*/ }
> @RunWith(CdiTestRunner.class)
> @TestControl(activeAlternativeLabel = Label1Test.Label1.class, classFilter =
> Label1Test.Label1Filter.class)
> public class Label1Test {
> @Inject
> private MyBean myBean;
> //tests
> public static class Label1 implements TestControl.Label {
> }
> public static class Label1Filter extends AbstractLabeledAlternativeFilter
> {
> public Label1Filter() {
> super(Label1.class);
> }
> }
> }
> {code}
> besides that other custom concepts are possible as well (not even bound to
> alternative-beans).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1338) support class-filter per test
[
https://issues.apache.org/jira/browse/DELTASPIKE-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445736#comment-16445736
]
ASF subversion and git services commented on DELTASPIKE-1338:
-
Commit 9429dd07ce38359d905b30f86a5cfbe9a108841b in deltaspike's branch
refs/heads/deltaspike-1.8.x from [~gpetracek]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=9429dd0 ]
DELTASPIKE-1338 tests for @TestControl#classFilter
> support class-filter per test
> -
>
> Key: DELTASPIKE-1338
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1338
> Project: DeltaSpike
> Issue Type: New Feature
> Components: TestControl
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
>
> based on DELTASPIKE-1337 it should be possible to define a class-filter per
> test.
> it allows type-safe isolation for tests and with cdi 1.1+ e.g. to build
> labeled-alternatives without text-based config.
> a possible approach looks like:
> {code:java}
> @Retention(RUNTIME)
> @Target(TYPE)
> public @interface Labeled {
> Class value();
> }
> public abstract class AbstractLabeledAlternativeFilter implements ClassFilter
> {
> private final Class activeLabel;
> protected AbstractLabeledAlternativeFilter(Class TestControl.Label> activeLabel) {
> this.activeLabel = activeLabel;
> }
> @Override
> public boolean isFiltered(Class targetClass) {
> if (!targetClass.isAnnotationPresent(Alternative.class)) {
> return false;
> }
> Labeled labeled = targetClass.getAnnotation(Labeled.class);
> if (labeled == null) {
> return false;
> }
> if (labeled.value().equals(activeLabel)) {
> return false;
> }
> return true;
> }
> }
> {code}
> {code:java}
> @Labeled(Label1Test.Label1.class)
> @Alternative
> @Priority(1)
> public class MyLabeledAlternativeBean1 extends MyBean { /*...*/ }
> @RunWith(CdiTestRunner.class)
> @TestControl(activeAlternativeLabel = Label1Test.Label1.class, classFilter =
> Label1Test.Label1Filter.class)
> public class Label1Test {
> @Inject
> private MyBean myBean;
> //tests
> public static class Label1 implements TestControl.Label {
> }
> public static class Label1Filter extends AbstractLabeledAlternativeFilter
> {
> public Label1Filter() {
> super(Label1.class);
> }
> }
> }
> {code}
> besides that other custom concepts are possible as well (not even bound to
> alternative-beans).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1340) Delegate to JPA 2.2 getResultStream
[ https://issues.apache.org/jira/browse/DELTASPIKE-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16451885#comment-16451885 ] ASF subversion and git services commented on DELTASPIKE-1340: - Commit 5fb4ec168fb8c7a7d0431e5d5e62d03979d0d8a3 in deltaspike's branch refs/heads/master from [~tandraschko] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=5fb4ec1 ] DELTASPIKE-1340 Delegate to JPA 2.2 getResultStream > Delegate to JPA 2.2 getResultStream > --- > > Key: DELTASPIKE-1340 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1340 > Project: DeltaSpike > Issue Type: Improvement > Components: Data-Module >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Fix For: 1.9.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1341) [perf] QueryProcessorFactory could reuse QueryProcessors
[ https://issues.apache.org/jira/browse/DELTASPIKE-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16452174#comment-16452174 ] ASF subversion and git services commented on DELTASPIKE-1341: - Commit a13c57ff23ab066075038967e4b5c186adb405c5 in deltaspike's branch refs/heads/master from [~tandraschko] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=a13c57f ] DELTASPIKE-1340 Delegate to JPA 2.2 getResultStream + DELTASPIKE-1341 QueryProcessorFactory could reuse QueryProcessors > [perf] QueryProcessorFactory could reuse QueryProcessors > > > Key: DELTASPIKE-1341 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1341 > Project: DeltaSpike > Issue Type: Improvement > Components: Data-Module >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Fix For: 1.9.0 > > > currently there are recreated for each method can be easily be handled as > appscoped -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1339) Add support for dynamic interceptor binding, added via Extension
[ https://issues.apache.org/jira/browse/DELTASPIKE-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16447845#comment-16447845 ] ASF subversion and git services commented on DELTASPIKE-1339: - Commit e16cea14048cba867db28157ceed2d60a2a398d8 in deltaspike's branch refs/heads/master from [~tandraschko] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=e16cea1 ] DELTASPIKE-1339 Add support for dynamic interceptor binding, added via Extension > Add support for dynamic interceptor binding, added via Extension > > > Key: DELTASPIKE-1339 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1339 > Project: DeltaSpike > Issue Type: Improvement >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 1.9.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1339) Add support for dynamic interceptor binding, added via Extension
[ https://issues.apache.org/jira/browse/DELTASPIKE-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448051#comment-16448051 ] ASF subversion and git services commented on DELTASPIKE-1339: - Commit 269eb82f739828c3c5a081e361bec31437f7a9c7 in deltaspike's branch refs/heads/master from [~tandraschko] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=269eb82 ] DELTASPIKE-1339 Add support for dynamic interceptor binding, added via Extension > Add support for dynamic interceptor binding, added via Extension > > > Key: DELTASPIKE-1339 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1339 > Project: DeltaSpike > Issue Type: Improvement > Components: Data-Module, PartialBean, Proxy-Module >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 1.9.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1280) Automatic support for count* methods in EntityRepository
[ https://issues.apache.org/jira/browse/DELTASPIKE-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448274#comment-16448274 ] ASF subversion and git services commented on DELTASPIKE-1280: - Commit dc45c497353371fbd70bd3efd5c7f9ec5ebb926a in deltaspike's branch refs/heads/master from [~tandraschko] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=dc45c49 ] DELTASPIKE-1280 Automatic support for count* methods in EntityRepository > Automatic support for count* methods in EntityRepository > > > Key: DELTASPIKE-1280 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1280 > Project: DeltaSpike > Issue Type: New Feature > Components: Data-Module >Reporter: Artur Signell >Assignee: Thomas Andraschko >Priority: Minor > Fix For: 1.9.0 > > > Stream findByLocation(String location) > will automatically create a query for finding all persons with the given > location. > long countByLocation(String location); > could automatically create a query for counting all persons with the given > location. > This would be 1:1 with how Spring Data works: > http://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories.core-concepts -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1315) EntityRepository should offer an findOptionalBy
[ https://issues.apache.org/jira/browse/DELTASPIKE-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448226#comment-16448226 ] ASF subversion and git services commented on DELTASPIKE-1315: - Commit 1a6a0013aa55f0bfd6d8ff42e32e1a9f1b39633c in deltaspike's branch refs/heads/master from [~tandraschko] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=1a6a001 ] DELTASPIKE-1315 EntityRepository should offer an findOptionalBy > EntityRepository should offer an findOptionalBy > --- > > Key: DELTASPIKE-1315 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1315 > Project: DeltaSpike > Issue Type: New Feature > Components: Data-Module >Reporter: Kevin Grüneberg >Assignee: Thomas Andraschko >Priority: Minor > Fix For: 1.9.0 > > > The EntityRepository interface offers an findBy(PK id) method, that returns > the entity based on the ID. It would be great to also have an > findOptionalBy(PK id) that returns an optional. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1280) Automatic support for count* methods in EntityRepository
[ https://issues.apache.org/jira/browse/DELTASPIKE-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448266#comment-16448266 ] ASF subversion and git services commented on DELTASPIKE-1280: - Commit aa668679e7105e101226e4a2d2beaafb1e86c403 in deltaspike's branch refs/heads/master from [~tandraschko] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=aa66867 ] DELTASPIKE-1280 Automatic support for count* methods in EntityRepository > Automatic support for count* methods in EntityRepository > > > Key: DELTASPIKE-1280 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1280 > Project: DeltaSpike > Issue Type: New Feature > Components: Data-Module >Reporter: Artur Signell >Priority: Major > Fix For: 1.9.0 > > > Stream findByLocation(String location) > will automatically create a query for finding all persons with the given > location. > long countByLocation(String location); > could automatically create a query for counting all persons with the given > location. > This would be 1:1 with how Spring Data works: > http://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories.core-concepts -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1315) EntityRepository should offer an findOptionalBy
[ https://issues.apache.org/jira/browse/DELTASPIKE-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449687#comment-16449687 ] ASF subversion and git services commented on DELTASPIKE-1315: - Commit 376114096b824df854e69c1e86e34817c1a8 in deltaspike's branch refs/heads/master from [~tandraschko] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=3761140 ] DELTASPIKE-1315 fixed unit test > EntityRepository should offer an findOptionalBy > --- > > Key: DELTASPIKE-1315 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1315 > Project: DeltaSpike > Issue Type: New Feature > Components: Data-Module >Reporter: Kevin Grüneberg >Assignee: Thomas Andraschko >Priority: Minor > Fix For: 1.9.0 > > > The EntityRepository interface offers an findBy(PK id) method, that returns > the entity based on the ID. It would be great to also have an > findOptionalBy(PK id) that returns an optional. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1334) javadoc for ConfigPreProcessor#beforeAddToConfig
[ https://issues.apache.org/jira/browse/DELTASPIKE-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419787#comment-16419787 ] ASF subversion and git services commented on DELTASPIKE-1334: - Commit b194bca4cce763322185b65e833615cf5931821f in deltaspike's branch refs/heads/master from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=b194bca ] DELTASPIKE-1334 added javadoc for ConfigPreProcessor#beforeAddToConfig > javadoc for ConfigPreProcessor#beforeAddToConfig > > > Key: DELTASPIKE-1334 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1334 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Minor > Fix For: 1.8.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1334) javadoc for ConfigPreProcessor#beforeAddToConfig
[ https://issues.apache.org/jira/browse/DELTASPIKE-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419822#comment-16419822 ] ASF subversion and git services commented on DELTASPIKE-1334: - Commit 1785e0ff44d3f58c64cda0b257bdf0c23d7f40b0 in deltaspike's branch refs/heads/deltaspike-1.8.x from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=1785e0f ] DELTASPIKE-1334 added javadoc for ConfigPreProcessor#beforeAddToConfig > javadoc for ConfigPreProcessor#beforeAddToConfig > > > Key: DELTASPIKE-1334 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1334 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Minor > Fix For: 1.8.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1332) support further cases for custom view-meta-data
[ https://issues.apache.org/jira/browse/DELTASPIKE-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419821#comment-16419821 ] ASF subversion and git services commented on DELTASPIKE-1332: - Commit 45dba462b8f16d86e3246bc28910fb241ef332e1 in deltaspike's branch refs/heads/deltaspike-1.8.x from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=45dba46 ] DELTASPIKE-1332 support custom view-meta-data without default-values for primitive data-types > support further cases for custom view-meta-data > --- > > Key: DELTASPIKE-1332 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1332 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.8.2 > > > if meta-data gets merged (and not aggregated), merging with primitive types > is currently only supported if there is a default-value. otherwise > annotation-proxies throw a NPE. > use-case e.g.: > @WizardStep(1) shouldn't require a default-value -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1319) labeled alternatives
[ https://issues.apache.org/jira/browse/DELTASPIKE-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419818#comment-16419818 ] ASF subversion and git services commented on DELTASPIKE-1319: - Commit a2591c497f9f6f00c84b70d7a9f0b92b431e456e in deltaspike's branch refs/heads/deltaspike-1.8.x from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=a2591c4 ] DELTASPIKE-1319 basic support for test-suites and minor improvements > labeled alternatives > > > Key: DELTASPIKE-1319 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1319 > Project: DeltaSpike > Issue Type: New Feature > Components: Core, TestControl >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.8.2 > > > target setup: ds-testcontrol as well as containers like meecrowave which > support one instance per test-class, but deploy the whole application. > in several cases it's essential to bind alternative beans only to a subset of > all tests. > currently we just support that partially via the mock-support (which is very > limited in several cases). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1320) global alternative spi to support custom (type-safe) mechanisms
[ https://issues.apache.org/jira/browse/DELTASPIKE-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419817#comment-16419817 ] ASF subversion and git services commented on DELTASPIKE-1320: - Commit e0a2505580dea6d2d95d9677a0f1ec686ce398f4 in deltaspike's branch refs/heads/deltaspike-1.8.x from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=e0a2505 ] DELTASPIKE-1320 labeled alternatives take priority over global alternatives > global alternative spi to support custom (type-safe) mechanisms > --- > > Key: DELTASPIKE-1320 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1320 > Project: DeltaSpike > Issue Type: New Feature > Components: Core >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.8.2 > > > in combination with DELTASPIKE-1319 it should be possible to implement e.g. > type-safe labels based on binding-annotations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1320) global alternative spi to support custom (type-safe) mechanisms
[ https://issues.apache.org/jira/browse/DELTASPIKE-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419816#comment-16419816 ] ASF subversion and git services commented on DELTASPIKE-1320: - Commit 06fd261a76e5ad8e791fd0fd4dd2994614f062ec in deltaspike's branch refs/heads/deltaspike-1.8.x from [~struberg] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=06fd261 ] DELTASPIKE-1320 detect conflicts in globalAlternatives labeled Alternatives take precendence over globalAlternatives > global alternative spi to support custom (type-safe) mechanisms > --- > > Key: DELTASPIKE-1320 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1320 > Project: DeltaSpike > Issue Type: New Feature > Components: Core >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.8.2 > > > in combination with DELTASPIKE-1319 it should be possible to implement e.g. > type-safe labels based on binding-annotations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1331) minor type improvement of the ViewConfigNode spi
[ https://issues.apache.org/jira/browse/DELTASPIKE-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419820#comment-16419820 ] ASF subversion and git services commented on DELTASPIKE-1331: - Commit add0adf311d260b9e727e172d5248161bdc62d16 in deltaspike's branch refs/heads/deltaspike-1.8.x from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=add0adf ] DELTASPIKE-1331 improved method signature of ViewConfigNode#getSource > minor type improvement of the ViewConfigNode spi > > > Key: DELTASPIKE-1331 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1331 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Trivial > Fix For: 1.8.2 > > > usually #getMetaData is enough, however, to get the +physical+ annotations > via #getSource a cast from Class to Class is needed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1329) ProjectStageProducer should log changed values
[ https://issues.apache.org/jira/browse/DELTASPIKE-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419819#comment-16419819 ] ASF subversion and git services commented on DELTASPIKE-1329: - Commit 5892839f1d0e52a17b4672eda27ccb10687cc03b in deltaspike's branch refs/heads/deltaspike-1.8.x from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=5892839 ] DELTASPIKE-1329 log update of project-stage value > ProjectStageProducer should log changed values > -- > > Key: DELTASPIKE-1329 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1329 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.8.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1332) support further cases for custom view-meta-data
[ https://issues.apache.org/jira/browse/DELTASPIKE-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16423139#comment-16423139 ] ASF subversion and git services commented on DELTASPIKE-1332: - Commit 1c8bd4bdfd2ebc2688c67f9c703cc2036fde92c5 in deltaspike's branch refs/heads/master from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=1c8bd4b ] DELTASPIKE-1332 support custom view-meta-data without default-values for primitive data-types > support further cases for custom view-meta-data > --- > > Key: DELTASPIKE-1332 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1332 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.8.2 > > > if meta-data gets merged (and not aggregated), merging with primitive types > is currently only supported if there is a default-value. otherwise > annotation-proxies throw a NPE. > use-case e.g.: > @WizardStep(1) shouldn't require a default-value -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1332) support further cases for custom view-meta-data
[ https://issues.apache.org/jira/browse/DELTASPIKE-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16423143#comment-16423143 ] ASF subversion and git services commented on DELTASPIKE-1332: - Commit 45b3e3e844b7730ffc76cf0ab55049178ef943e7 in deltaspike's branch refs/heads/deltaspike-1.8.x from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=45b3e3e ] DELTASPIKE-1332 support custom view-meta-data without default-values for primitive data-types > support further cases for custom view-meta-data > --- > > Key: DELTASPIKE-1332 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1332 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.8.2 > > > if meta-data gets merged (and not aggregated), merging with primitive types > is currently only supported if there is a default-value. otherwise > annotation-proxies throw a NPE. > use-case e.g.: > @WizardStep(1) shouldn't require a default-value -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1332) support further cases for custom view-meta-data
[ https://issues.apache.org/jira/browse/DELTASPIKE-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16423213#comment-16423213 ] ASF subversion and git services commented on DELTASPIKE-1332: - Commit 3b959179ad7d880f8b1c479adf3fb3f42e85e67b in deltaspike's branch refs/heads/deltaspike-1.8.x from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=3b95917 ] DELTASPIKE-1332 backported tests > support further cases for custom view-meta-data > --- > > Key: DELTASPIKE-1332 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1332 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.8.2 > > > if meta-data gets merged (and not aggregated), merging with primitive types > is currently only supported if there is a default-value. otherwise > annotation-proxies throw a NPE. > use-case e.g.: > @WizardStep(1) shouldn't require a default-value -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1329) ProjectStageProducer should log changed values
[ https://issues.apache.org/jira/browse/DELTASPIKE-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16403670#comment-16403670 ] ASF subversion and git services commented on DELTASPIKE-1329: - Commit 138a061c378580203769c01e27d6052e9a1ab12b in deltaspike's branch refs/heads/master from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=138a061 ] DELTASPIKE-1329 log update of project-stage value > ProjectStageProducer should log changed values > -- > > Key: DELTASPIKE-1329 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1329 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.8.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1332) support further cases for custom view-meta-data
[ https://issues.apache.org/jira/browse/DELTASPIKE-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412211#comment-16412211 ] ASF subversion and git services commented on DELTASPIKE-1332: - Commit 82596c5749686ab5c747f191b1b8ee8359ae54d7 in deltaspike's branch refs/heads/master from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=82596c5 ] DELTASPIKE-1332 support custom view-meta-data without default-values for primitive data-types > support further cases for custom view-meta-data > --- > > Key: DELTASPIKE-1332 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1332 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.8.2 > > > if meta-data gets merged (and not aggregated), merging with primitive types > is currently only supported if there is a default-value. otherwise > annotation-proxies throw a NPE. > use-case e.g.: > @WizardStep(1) shouldn't require a default-value -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1331) minor type improvement of the ViewConfigNode spi
[ https://issues.apache.org/jira/browse/DELTASPIKE-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412210#comment-16412210 ] ASF subversion and git services commented on DELTASPIKE-1331: - Commit fe0106d4a0ceaded2f6f38bdc83292de2b4f in deltaspike's branch refs/heads/master from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=fe0106d ] DELTASPIKE-1331 improved method signature of ViewConfigNode#getSource > minor type improvement of the ViewConfigNode spi > > > Key: DELTASPIKE-1331 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1331 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Trivial > Fix For: 1.8.2 > > > usually #getMetaData is enough, however, to get the +physical+ annotations > via #getSource a cast from Class to Class is needed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1319) labeled alternatives
[ https://issues.apache.org/jira/browse/DELTASPIKE-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16382627#comment-16382627 ] ASF subversion and git services commented on DELTASPIKE-1319: - Commit ca6b722bd0cea0975580d74fefd53f25e9330cc5 in deltaspike's branch refs/heads/master from [~gpetracek] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=ca6b722 ] DELTASPIKE-1319 basic support for test-suites and minor improvements > labeled alternatives > > > Key: DELTASPIKE-1319 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1319 > Project: DeltaSpike > Issue Type: New Feature > Components: Core, TestControl >Affects Versions: 1.8.1 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.8.2 > > > target setup: ds-testcontrol as well as containers like meecrowave which > support one instance per test-class, but deploy the whole application. > in several cases it's essential to bind alternative beans only to a subset of > all tests. > currently we just support that partially via the mock-support (which is very > limited in several cases). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1322) clean up ConfigResolver
[ https://issues.apache.org/jira/browse/DELTASPIKE-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386187#comment-16386187 ] ASF subversion and git services commented on DELTASPIKE-1322: - Commit f56845c4ff08be03e61d293e54d7bcae72dccf30 in deltaspike's branch refs/heads/master from [~struberg] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=f56845c ] DELTASPIKE-1322 move config internas to impl > clean up ConfigResolver > --- > > Key: DELTASPIKE-1322 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1322 > Project: DeltaSpike > Issue Type: Improvement > Components: Configuration >Affects Versions: 1.8.1 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 1.9.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1322) clean up ConfigResolver
[ https://issues.apache.org/jira/browse/DELTASPIKE-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386188#comment-16386188 ] ASF subversion and git services commented on DELTASPIKE-1322: - Commit bd638aae11d6723b17c7b533e3e21c2106dd581a in deltaspike's branch refs/heads/master from [~struberg] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=bd638aa ] DELTASPIKE-1322 switch ConfigSources over anything which contains state is now getting moved over from ConfigResolver to Config > clean up ConfigResolver > --- > > Key: DELTASPIKE-1322 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1322 > Project: DeltaSpike > Issue Type: Improvement > Components: Configuration >Affects Versions: 1.8.1 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 1.9.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1322) clean up ConfigResolver
[ https://issues.apache.org/jira/browse/DELTASPIKE-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386189#comment-16386189 ] ASF subversion and git services commented on DELTASPIKE-1322: - Commit 5b07e197cb808cee108e1935cae18fc199c82a9f in deltaspike's branch refs/heads/master from [~struberg] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=5b07e19 ] DELTASPIKE-1322 mv more config pieces over 2 impl > clean up ConfigResolver > --- > > Key: DELTASPIKE-1322 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1322 > Project: DeltaSpike > Issue Type: Improvement > Components: Configuration >Affects Versions: 1.8.1 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 1.9.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1361) improved handling per ds-test
[ https://issues.apache.org/jira/browse/DELTASPIKE-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16670788#comment-16670788 ] ASF subversion and git services commented on DELTASPIKE-1361: - Commit 6aceb6f3437e608dae8f19c57c6578fcce72752e in deltaspike's branch refs/heads/master from gpetracek [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=6aceb6f ] DELTASPIKE-1361 small improvements (esp. for CdiTestRunner) > improved handling per ds-test > - > > Key: DELTASPIKE-1361 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1361 > Project: DeltaSpike > Issue Type: Improvement > Components: TestControl >Affects Versions: 1.9.0 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Minor > Fix For: 1.9.1 > > > in some cases the RunListener can "leak" to plain junit tests which leads to > ds-log-entries (which are mainly useful for cdi-based tests in combination > with external containers) also in case of plain junit tests. furthermore, the > cleanup of ThreadLocal should be unified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1359) deltaspike-data-module-test-ee7
[ https://issues.apache.org/jira/browse/DELTASPIKE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663471#comment-16663471 ] ASF subversion and git services commented on DELTASPIKE-1359: - Commit a62bec4dd3aae507bb39037fcde96c10a5f92bd8 in deltaspike's branch refs/heads/master from gpetracek [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=a62bec4 ] DELTASPIKE-1359 upgraded version numbers > deltaspike-data-module-test-ee7 > --- > > Key: DELTASPIKE-1359 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1359 > Project: DeltaSpike > Issue Type: Improvement > Components: Data-Module >Affects Versions: 1.9.0 >Reporter: Gerhard Petracek >Assignee: Mark Struberg >Priority: Major > > deltaspike-data-module-test-ee7 wasn't upgraded to 1.9.1-SNAPSHOT during the > release of 1.9.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-900) ResourceLocalTransactionStrategy not working with multiple EntityManagers
[
https://issues.apache.org/jira/browse/DELTASPIKE-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602004#comment-16602004
]
ASF subversion and git services commented on DELTASPIKE-900:
Commit 94776b09867fdea0875f3e3ca98f68a62f43e707 in deltaspike's branch
refs/heads/master from [~elexx]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=94776b0 ]
DELTASPIKE-900: commit tx if we started it
> ResourceLocalTransactionStrategy not working with multiple EntityManagers
> -
>
> Key: DELTASPIKE-900
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-900
> Project: DeltaSpike
> Issue Type: Bug
> Components: JPA-Module
>Affects Versions: 1.2.1, 1.3.0
>Reporter: Johannes Testori
>Assignee: Mark Struberg
>Priority: Major
>
> We are using CDI-ApplicationScoped services in a batch program with
> CdiControl. We started using multiple qualified EntityManagers in a single
> service annotated with @Transactional and encountered the problem that
> database changes are not committed. After some debugging we found the problem
> in the "execute"-method in ResourceLocalTransactionStrategy.
> for (Class emQualifier : emQualifiers)
> {
> EntityManager entityManager =
> resolveEntityManagerForQualifier(emQualifier);
> EntityManagerEntry entityManagerEntry =
> createEntityManagerEntry(entityManager, emQualifier);
> transactionBeanStorage.storeUsedEntityManager(entityManagerEntry);
> EntityTransaction transaction = getTransaction(entityManagerEntry);
> if (!transaction.isActive())
> {
> beforeBegin(invocationContext, entityManagerEntry, transaction);
> transaction.begin();
> }
> else if (isOutermostInterceptor)
> {
> outermostTransactionAlreadyExisted = true;
> }
> //don't move it before EntityTransaction#begin() and invoke it in any case
> beforeProceed(invocationContext, entityManagerEntry, transaction);
> }
> A transaction is created for the first EntityManager. But since the same
> transaction is assigned to the other EntityManagers,
> "outermostTransactionAlreadyExisted" is set to true. This is the cause for
> the transaction not being committed afterwards:
> if (isOutermostInterceptor)
> {
> if (!outermostTransactionAlreadyExisted)
> {
> // We only commit transactions we opened ourselfs.
> // If the transaction got opened outside of our interceptor chain
> // we must not handle it.
> // This e.g. happens if a Stateless EJB invokes a Transactional CDI
> bean
> // which uses the BeanManagedUserTransactionStrategy.
> We've seen this problem in version 1.2.1 and 1.3.0. (didn't try other
> versions).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-900) ResourceLocalTransactionStrategy not working with multiple EntityManagers
[
https://issues.apache.org/jira/browse/DELTASPIKE-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16601997#comment-16601997
]
ASF subversion and git services commented on DELTASPIKE-900:
Commit 7bd3c1d53eeda4b8bc14656515ba7e885f2f6473 in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=7bd3c1d ]
DELTASPIKE-900 add unit test for multiple BM tx
> ResourceLocalTransactionStrategy not working with multiple EntityManagers
> -
>
> Key: DELTASPIKE-900
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-900
> Project: DeltaSpike
> Issue Type: Bug
> Components: JPA-Module
>Affects Versions: 1.2.1, 1.3.0
>Reporter: Johannes Testori
>Assignee: Mark Struberg
>Priority: Major
>
> We are using CDI-ApplicationScoped services in a batch program with
> CdiControl. We started using multiple qualified EntityManagers in a single
> service annotated with @Transactional and encountered the problem that
> database changes are not committed. After some debugging we found the problem
> in the "execute"-method in ResourceLocalTransactionStrategy.
> for (Class emQualifier : emQualifiers)
> {
> EntityManager entityManager =
> resolveEntityManagerForQualifier(emQualifier);
> EntityManagerEntry entityManagerEntry =
> createEntityManagerEntry(entityManager, emQualifier);
> transactionBeanStorage.storeUsedEntityManager(entityManagerEntry);
> EntityTransaction transaction = getTransaction(entityManagerEntry);
> if (!transaction.isActive())
> {
> beforeBegin(invocationContext, entityManagerEntry, transaction);
> transaction.begin();
> }
> else if (isOutermostInterceptor)
> {
> outermostTransactionAlreadyExisted = true;
> }
> //don't move it before EntityTransaction#begin() and invoke it in any case
> beforeProceed(invocationContext, entityManagerEntry, transaction);
> }
> A transaction is created for the first EntityManager. But since the same
> transaction is assigned to the other EntityManagers,
> "outermostTransactionAlreadyExisted" is set to true. This is the cause for
> the transaction not being committed afterwards:
> if (isOutermostInterceptor)
> {
> if (!outermostTransactionAlreadyExisted)
> {
> // We only commit transactions we opened ourselfs.
> // If the transaction got opened outside of our interceptor chain
> // we must not handle it.
> // This e.g. happens if a Stateless EJB invokes a Transactional CDI
> bean
> // which uses the BeanManagedUserTransactionStrategy.
> We've seen this problem in version 1.2.1 and 1.3.0. (didn't try other
> versions).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-900) ResourceLocalTransactionStrategy not working with multiple EntityManagers
[
https://issues.apache.org/jira/browse/DELTASPIKE-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16601996#comment-16601996
]
ASF subversion and git services commented on DELTASPIKE-900:
Commit 779d28b39c267b960ebb65ab3187c63033f7c834 in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=779d28b ]
DELTASPIKE-900 proper EntityManager setup
> ResourceLocalTransactionStrategy not working with multiple EntityManagers
> -
>
> Key: DELTASPIKE-900
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-900
> Project: DeltaSpike
> Issue Type: Bug
> Components: JPA-Module
>Affects Versions: 1.2.1, 1.3.0
>Reporter: Johannes Testori
>Assignee: Mark Struberg
>Priority: Major
>
> We are using CDI-ApplicationScoped services in a batch program with
> CdiControl. We started using multiple qualified EntityManagers in a single
> service annotated with @Transactional and encountered the problem that
> database changes are not committed. After some debugging we found the problem
> in the "execute"-method in ResourceLocalTransactionStrategy.
> for (Class emQualifier : emQualifiers)
> {
> EntityManager entityManager =
> resolveEntityManagerForQualifier(emQualifier);
> EntityManagerEntry entityManagerEntry =
> createEntityManagerEntry(entityManager, emQualifier);
> transactionBeanStorage.storeUsedEntityManager(entityManagerEntry);
> EntityTransaction transaction = getTransaction(entityManagerEntry);
> if (!transaction.isActive())
> {
> beforeBegin(invocationContext, entityManagerEntry, transaction);
> transaction.begin();
> }
> else if (isOutermostInterceptor)
> {
> outermostTransactionAlreadyExisted = true;
> }
> //don't move it before EntityTransaction#begin() and invoke it in any case
> beforeProceed(invocationContext, entityManagerEntry, transaction);
> }
> A transaction is created for the first EntityManager. But since the same
> transaction is assigned to the other EntityManagers,
> "outermostTransactionAlreadyExisted" is set to true. This is the cause for
> the transaction not being committed afterwards:
> if (isOutermostInterceptor)
> {
> if (!outermostTransactionAlreadyExisted)
> {
> // We only commit transactions we opened ourselfs.
> // If the transaction got opened outside of our interceptor chain
> // we must not handle it.
> // This e.g. happens if a Stateless EJB invokes a Transactional CDI
> bean
> // which uses the BeanManagedUserTransactionStrategy.
> We've seen this problem in version 1.2.1 and 1.3.0. (didn't try other
> versions).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1363) news links to post and examples.
[ https://issues.apache.org/jira/browse/DELTASPIKE-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706943#comment-16706943 ] ASF subversion and git services commented on DELTASPIKE-1363: - Commit 757be9b18f5e5985cfdce7e1d5d9184734943d13 in deltaspike's branch refs/heads/master from [~tandraschko] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=757be9b ] DELTASPIKE-1363 > news links to post and examples. > > > Key: DELTASPIKE-1363 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1363 > Project: DeltaSpike > Issue Type: Task > Components: Documentation >Reporter: Daniel Dias dos Santos >Priority: Minor > Labels: documentation > Attachments: 77.patch > > > HI, > I created an PR in => https://github.com/apache/deltaspike/pull/77 , > but via github it gets kinda bad to merge from the sides of you, so I was > suggested to add a pacth around here. > thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1362) Very early JSF3.x support
[ https://issues.apache.org/jira/browse/DELTASPIKE-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16695759#comment-16695759 ] ASF subversion and git services commented on DELTASPIKE-1362: - Commit 3d524def6931ab36ab8e4a13c305fd3e98aa461b in deltaspike's branch refs/heads/master from [~tandraschko] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=3d524de ] DELTASPIKE-1362 Very early JSF3.x support > Very early JSF3.x support > - > > Key: DELTASPIKE-1362 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1362 > Project: DeltaSpike > Issue Type: Improvement >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Fix For: 1.9.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1357) Update ASM to 7.0
[ https://issues.apache.org/jira/browse/DELTASPIKE-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16695765#comment-16695765 ] ASF subversion and git services commented on DELTASPIKE-1357: - Commit 4bef6c54d707a840d622d4feafb7c506338ea253 in deltaspike's branch refs/heads/master from [~tandraschko] [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=4bef6c5 ] DELTASPIKE-1357 Update ASM to 7.0 > Update ASM to 7.0 > - > > Key: DELTASPIKE-1357 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1357 > Project: DeltaSpike > Issue Type: Improvement > Components: Proxy-Module >Affects Versions: 1.9.0 >Reporter: Christian Beikov >Assignee: Mark Struberg >Priority: Major > Fix For: 1.9.1 > > > Java 12 has a new class file version and ASM 6.2 does not yet have support > for that. ASM 6.2.1 on the other hand already does. Since it's a minor > update, please get that into 1.9.1 so we can start early testing with Java 12. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1365) Support extra JPQL comparators in method expressions
[ https://issues.apache.org/jira/browse/DELTASPIKE-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16737304#comment-16737304 ] ASF subversion and git services commented on DELTASPIKE-1365: - Commit bb7806352f50465f197061672e1e727bc81b33c3 in deltaspike's branch refs/heads/master from Thomas Andraschko [ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=bb78063 ] DELTASPIKE-1365: Support extra JPQL comparators in method expressions > Support extra JPQL comparators in method expressions > > > Key: DELTASPIKE-1365 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1365 > Project: DeltaSpike > Issue Type: Improvement > Components: Data-Module >Reporter: Ehsan Zaery Moghaddam >Priority: Minor > > The method expressions is currently supporting primary JPQL operators while > it seems feasible to implement other operators like "In", "NotIn", > "StartingWith", "True", etc. > I tried to add some of them and seems they works (of course thanks to the way > they've been designed so that it's easy to extend them). I'm just curious if > there is any technical consideration/limitation preventing us to have these > operators or is it because they were never been requested? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1375) Correctly spell futurable
[ https://issues.apache.org/jira/browse/DELTASPIKE-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800548#comment-16800548 ] ASF subversion and git services commented on DELTASPIKE-1375: - Commit 8ed131eac40d598ba630ec9aba77569551a2db5c in deltaspike's branch refs/heads/master from Thomas Andraschko [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=8ed131e ] DELTASPIKE-1375 > Correctly spell futurable > - > > Key: DELTASPIKE-1375 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1375 > Project: DeltaSpike > Issue Type: Improvement >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 1.9.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1374) Site has no reference to the release of version 1.9.0
[ https://issues.apache.org/jira/browse/DELTASPIKE-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800543#comment-16800543 ] ASF subversion and git services commented on DELTASPIKE-1374: - Commit a1dece59fed4bddfecc310b9a3ae7152a1c11827 in deltaspike's branch refs/heads/master from Thomas Andraschko [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=a1dece5 ] Merge pull request #88 from Daniel-Dos/fix-deltaspike-version DELTASPIKE-1374: fix version to 1.9.0 > Site has no reference to the release of version 1.9.0 > - > > Key: DELTASPIKE-1374 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1374 > Project: DeltaSpike > Issue Type: Bug > Components: Documentation >Affects Versions: 1.9.0 >Reporter: Daniel Dias >Priority: Major > Fix For: 1.9.1 > > Attachments: DELTASPIKE-1374.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > > 1 - In main page still has 1.8.2 ([https://deltaspike.apache.org/)] > 2 - In Dowload page too ([https://deltaspike.apache.org/download.html)] > 3 - here too (https://deltaspike.apache.org/documentation/configure.html) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1374) Site has no reference to the release of version 1.9.0
[ https://issues.apache.org/jira/browse/DELTASPIKE-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800542#comment-16800542 ] ASF subversion and git services commented on DELTASPIKE-1374: - Commit 1c72e46de94421a1cb4458ff4511ba8f956b2ebb in deltaspike's branch refs/heads/master from Daniel Dias [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=1c72e46 ] DELTASPIKE-1374: fix version to 1.9.0 > Site has no reference to the release of version 1.9.0 > - > > Key: DELTASPIKE-1374 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1374 > Project: DeltaSpike > Issue Type: Bug > Components: Documentation >Affects Versions: 1.9.0 >Reporter: Daniel Dias >Priority: Major > Fix For: 1.9.1 > > Attachments: DELTASPIKE-1374.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > > 1 - In main page still has 1.8.2 ([https://deltaspike.apache.org/)] > 2 - In Dowload page too ([https://deltaspike.apache.org/download.html)] > 3 - here too (https://deltaspike.apache.org/documentation/configure.html) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1369) [Scheduler] Enable/Disable based on custom condition
[
https://issues.apache.org/jira/browse/DELTASPIKE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794588#comment-16794588
]
ASF subversion and git services commented on DELTASPIKE-1369:
-
Commit 47453af0886c1de7cb9062870b5974f598d2384f in deltaspike's branch
refs/heads/master from Juri Berlanda
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=47453af ]
DELTASPIKE-1369: Add default implementations to SchedulerControl.
This should ease the development of actual implementations and default to
"everything runs".
Signed-off-by: Juri Berlanda
> [Scheduler] Enable/Disable based on custom condition
>
>
> Key: DELTASPIKE-1369
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1369
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Scheduler
>Reporter: Juri Berlanda
>Priority: Major
>
> As discussed on the mailing list, I propose to introduce some kind of
> pluggable Bean, which would allow to control both whether the Scheduler as a
> whole should start, as well as to provide a hook for controlling each single
> task invocation.
> The default implementation would always return true on both, which makes sure
> the default behavior is the same as it has always been. Being a Bean, it can
> be customized via CDI mechanisms (Specializes, Alternative, etc.).
> The Bean should provide the following signature:
> {{boolean isSchedulerEnabled();}}
> {{boolean vetoJobExecution(Class);}}
> TBD:
> * Provide support for multiple implementations of {{SchedulerControl}}
> * -Better name for shouldJobBeStarted?- Found
> * -Use JobName in shouldJobBeStarted?- Not needed as discussed on mailing
> list
> Development takes place at
> [https://github.com/j-be/deltaspike/tree/scheduler-control]
> Pull request can be found at https://github.com/apache/deltaspike/pull/84
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1369) [Scheduler] Enable/Disable based on custom condition
[
https://issues.apache.org/jira/browse/DELTASPIKE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794585#comment-16794585
]
ASF subversion and git services commented on DELTASPIKE-1369:
-
Commit f9c1903dce5acc4ea5e3df763e903bc293389416 in deltaspike's branch
refs/heads/master from Juri Berlanda
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=f9c1903 ]
DELTASPIKE-1369: Don't touch this.isActivated.
As per feedback on the pull-request, this.isActivated shall not be touched.
Signed-off-by: Juri Berlanda
> [Scheduler] Enable/Disable based on custom condition
>
>
> Key: DELTASPIKE-1369
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1369
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Scheduler
>Reporter: Juri Berlanda
>Priority: Major
>
> As discussed on the mailing list, I propose to introduce some kind of
> pluggable Bean, which would allow to control both whether the Scheduler as a
> whole should start, as well as to provide a hook for controlling each single
> task invocation.
> The default implementation would always return true on both, which makes sure
> the default behavior is the same as it has always been. Being a Bean, it can
> be customized via CDI mechanisms (Specializes, Alternative, etc.).
> The Bean should provide the following signature:
> {{boolean isSchedulerEnabled();}}
> {{boolean vetoJobExecution(Class);}}
> TBD:
> * Provide support for multiple implementations of {{SchedulerControl}}
> * -Better name for shouldJobBeStarted?- Found
> * -Use JobName in shouldJobBeStarted?- Not needed as discussed on mailing
> list
> Development takes place at
> [https://github.com/j-be/deltaspike/tree/scheduler-control]
> Pull request can be found at https://github.com/apache/deltaspike/pull/84
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1369) [Scheduler] Enable/Disable based on custom condition
[
https://issues.apache.org/jira/browse/DELTASPIKE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794583#comment-16794583
]
ASF subversion and git services commented on DELTASPIKE-1369:
-
Commit f807e025b3d8a4f42c704cb0fbc4ed0a4d578620 in deltaspike's branch
refs/heads/master from Juri Berlanda
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=f807e02 ]
DELTASPIKE-1369: Switch to conditdional lookup.
Instead of providing a default implementation, access to SchedulerControl
is implemented used BeanProvider and conditional lookup.
Signed-off-by: Juri Berlanda
> [Scheduler] Enable/Disable based on custom condition
>
>
> Key: DELTASPIKE-1369
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1369
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Scheduler
>Reporter: Juri Berlanda
>Priority: Major
>
> As discussed on the mailing list, I propose to introduce some kind of
> pluggable Bean, which would allow to control both whether the Scheduler as a
> whole should start, as well as to provide a hook for controlling each single
> task invocation.
> The default implementation would always return true on both, which makes sure
> the default behavior is the same as it has always been. Being a Bean, it can
> be customized via CDI mechanisms (Specializes, Alternative, etc.).
> The Bean should provide the following signature:
> {{boolean isSchedulerEnabled();}}
> {{boolean vetoJobExecution(Class);}}
> TBD:
> * Provide support for multiple implementations of {{SchedulerControl}}
> * -Better name for shouldJobBeStarted?- Found
> * -Use JobName in shouldJobBeStarted?- Not needed as discussed on mailing
> list
> Development takes place at
> [https://github.com/j-be/deltaspike/tree/scheduler-control]
> Pull request can be found at https://github.com/apache/deltaspike/pull/84
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1369) [Scheduler] Enable/Disable based on custom condition
[
https://issues.apache.org/jira/browse/DELTASPIKE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794587#comment-16794587
]
ASF subversion and git services commented on DELTASPIKE-1369:
-
Commit c37d3a0cee8577e5021b5663d39a09f9620fb716 in deltaspike's branch
refs/heads/master from Juri Berlanda
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=c37d3a0 ]
DELTASPIKE-1369: Add log statement if job execution was vetoed.
Signed-off-by: Juri Berlanda
> [Scheduler] Enable/Disable based on custom condition
>
>
> Key: DELTASPIKE-1369
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1369
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Scheduler
>Reporter: Juri Berlanda
>Priority: Major
>
> As discussed on the mailing list, I propose to introduce some kind of
> pluggable Bean, which would allow to control both whether the Scheduler as a
> whole should start, as well as to provide a hook for controlling each single
> task invocation.
> The default implementation would always return true on both, which makes sure
> the default behavior is the same as it has always been. Being a Bean, it can
> be customized via CDI mechanisms (Specializes, Alternative, etc.).
> The Bean should provide the following signature:
> {{boolean isSchedulerEnabled();}}
> {{boolean vetoJobExecution(Class);}}
> TBD:
> * Provide support for multiple implementations of {{SchedulerControl}}
> * -Better name for shouldJobBeStarted?- Found
> * -Use JobName in shouldJobBeStarted?- Not needed as discussed on mailing
> list
> Development takes place at
> [https://github.com/j-be/deltaspike/tree/scheduler-control]
> Pull request can be found at https://github.com/apache/deltaspike/pull/84
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1369) [Scheduler] Enable/Disable based on custom condition
[
https://issues.apache.org/jira/browse/DELTASPIKE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794589#comment-16794589
]
ASF subversion and git services commented on DELTASPIKE-1369:
-
Commit d2c0cd8caa5b9fd4bafc5941bfec4ff490ca5786 in deltaspike's branch
refs/heads/master from Gerhard Petracek
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=d2c0cd8 ]
Merge pull request #84 from j-be/scheduler-control
DELTASPIKE-1369 merged pull request
> [Scheduler] Enable/Disable based on custom condition
>
>
> Key: DELTASPIKE-1369
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1369
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Scheduler
>Reporter: Juri Berlanda
>Priority: Major
>
> As discussed on the mailing list, I propose to introduce some kind of
> pluggable Bean, which would allow to control both whether the Scheduler as a
> whole should start, as well as to provide a hook for controlling each single
> task invocation.
> The default implementation would always return true on both, which makes sure
> the default behavior is the same as it has always been. Being a Bean, it can
> be customized via CDI mechanisms (Specializes, Alternative, etc.).
> The Bean should provide the following signature:
> {{boolean isSchedulerEnabled();}}
> {{boolean vetoJobExecution(Class);}}
> TBD:
> * Provide support for multiple implementations of {{SchedulerControl}}
> * -Better name for shouldJobBeStarted?- Found
> * -Use JobName in shouldJobBeStarted?- Not needed as discussed on mailing
> list
> Development takes place at
> [https://github.com/j-be/deltaspike/tree/scheduler-control]
> Pull request can be found at https://github.com/apache/deltaspike/pull/84
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1369) [Scheduler] Enable/Disable based on custom condition
[
https://issues.apache.org/jira/browse/DELTASPIKE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794582#comment-16794582
]
ASF subversion and git services commented on DELTASPIKE-1369:
-
Commit b3347a48f2ba9d77d2d1cb10e808343ab6ab913f in deltaspike's branch
refs/heads/master from Juri Berlanda
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=b3347a4 ]
DELTASPIKE-1369: Fix typo in JavaDoc.
Signed-off-by: Juri Berlanda
> [Scheduler] Enable/Disable based on custom condition
>
>
> Key: DELTASPIKE-1369
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1369
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Scheduler
>Reporter: Juri Berlanda
>Priority: Major
>
> As discussed on the mailing list, I propose to introduce some kind of
> pluggable Bean, which would allow to control both whether the Scheduler as a
> whole should start, as well as to provide a hook for controlling each single
> task invocation.
> The default implementation would always return true on both, which makes sure
> the default behavior is the same as it has always been. Being a Bean, it can
> be customized via CDI mechanisms (Specializes, Alternative, etc.).
> The Bean should provide the following signature:
> {{boolean isSchedulerEnabled();}}
> {{boolean vetoJobExecution(Class);}}
> TBD:
> * Provide support for multiple implementations of {{SchedulerControl}}
> * -Better name for shouldJobBeStarted?- Found
> * -Use JobName in shouldJobBeStarted?- Not needed as discussed on mailing
> list
> Development takes place at
> [https://github.com/j-be/deltaspike/tree/scheduler-control]
> Pull request can be found at https://github.com/apache/deltaspike/pull/84
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1369) [Scheduler] Enable/Disable based on custom condition
[
https://issues.apache.org/jira/browse/DELTASPIKE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794586#comment-16794586
]
ASF subversion and git services commented on DELTASPIKE-1369:
-
Commit 2dcf476b0363a33c7b6aa709c65c4b7a8b9f9dcb in deltaspike's branch
refs/heads/master from Juri Berlanda
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=2dcf476 ]
DELTASPIKE-1369: Add log statement if scheduler was disabled.
Signed-off-by: Juri Berlanda
> [Scheduler] Enable/Disable based on custom condition
>
>
> Key: DELTASPIKE-1369
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1369
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Scheduler
>Reporter: Juri Berlanda
>Priority: Major
>
> As discussed on the mailing list, I propose to introduce some kind of
> pluggable Bean, which would allow to control both whether the Scheduler as a
> whole should start, as well as to provide a hook for controlling each single
> task invocation.
> The default implementation would always return true on both, which makes sure
> the default behavior is the same as it has always been. Being a Bean, it can
> be customized via CDI mechanisms (Specializes, Alternative, etc.).
> The Bean should provide the following signature:
> {{boolean isSchedulerEnabled();}}
> {{boolean vetoJobExecution(Class);}}
> TBD:
> * Provide support for multiple implementations of {{SchedulerControl}}
> * -Better name for shouldJobBeStarted?- Found
> * -Use JobName in shouldJobBeStarted?- Not needed as discussed on mailing
> list
> Development takes place at
> [https://github.com/j-be/deltaspike/tree/scheduler-control]
> Pull request can be found at https://github.com/apache/deltaspike/pull/84
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1369) [Scheduler] Enable/Disable based on custom condition
[
https://issues.apache.org/jira/browse/DELTASPIKE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794584#comment-16794584
]
ASF subversion and git services commented on DELTASPIKE-1369:
-
Commit 20bd2176c9a2599c11ded40cc2bc73d4d9f69140 in deltaspike's branch
refs/heads/master from Juri Berlanda
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=20bd217 ]
DELTASPIKE-1369: Switch to veto logic for job control.
This makes the implementation more similar to Quartz' TriggerListener.
Signed-off-by: Juri Berlanda
> [Scheduler] Enable/Disable based on custom condition
>
>
> Key: DELTASPIKE-1369
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1369
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Scheduler
>Reporter: Juri Berlanda
>Priority: Major
>
> As discussed on the mailing list, I propose to introduce some kind of
> pluggable Bean, which would allow to control both whether the Scheduler as a
> whole should start, as well as to provide a hook for controlling each single
> task invocation.
> The default implementation would always return true on both, which makes sure
> the default behavior is the same as it has always been. Being a Bean, it can
> be customized via CDI mechanisms (Specializes, Alternative, etc.).
> The Bean should provide the following signature:
> {{boolean isSchedulerEnabled();}}
> {{boolean vetoJobExecution(Class);}}
> TBD:
> * Provide support for multiple implementations of {{SchedulerControl}}
> * -Better name for shouldJobBeStarted?- Found
> * -Use JobName in shouldJobBeStarted?- Not needed as discussed on mailing
> list
> Development takes place at
> [https://github.com/j-be/deltaspike/tree/scheduler-control]
> Pull request can be found at https://github.com/apache/deltaspike/pull/84
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1369) [Scheduler] Enable/Disable based on custom condition
[
https://issues.apache.org/jira/browse/DELTASPIKE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794581#comment-16794581
]
ASF subversion and git services commented on DELTASPIKE-1369:
-
Commit 2d2f3c106f899af6589a55523c38ab2f78a2874d in deltaspike's branch
refs/heads/master from Juri Berlanda
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=2d2f3c1 ]
DELTASPIKE-1369: Move SchedulerControl to spi package.
Signed-off-by: Juri Berlanda
> [Scheduler] Enable/Disable based on custom condition
>
>
> Key: DELTASPIKE-1369
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1369
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Scheduler
>Reporter: Juri Berlanda
>Priority: Major
>
> As discussed on the mailing list, I propose to introduce some kind of
> pluggable Bean, which would allow to control both whether the Scheduler as a
> whole should start, as well as to provide a hook for controlling each single
> task invocation.
> The default implementation would always return true on both, which makes sure
> the default behavior is the same as it has always been. Being a Bean, it can
> be customized via CDI mechanisms (Specializes, Alternative, etc.).
> The Bean should provide the following signature:
> {{boolean isSchedulerEnabled();}}
> {{boolean vetoJobExecution(Class);}}
> TBD:
> * Provide support for multiple implementations of {{SchedulerControl}}
> * -Better name for shouldJobBeStarted?- Found
> * -Use JobName in shouldJobBeStarted?- Not needed as discussed on mailing
> list
> Development takes place at
> [https://github.com/j-be/deltaspike/tree/scheduler-control]
> Pull request can be found at https://github.com/apache/deltaspike/pull/84
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1369) [Scheduler] Enable/Disable based on custom condition
[
https://issues.apache.org/jira/browse/DELTASPIKE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794580#comment-16794580
]
ASF subversion and git services commented on DELTASPIKE-1369:
-
Commit 8e5e03ad0dc6852ec9a1f3fab060b26e025f35f7 in deltaspike's branch
refs/heads/master from Juri Berlanda
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=8e5e03a ]
DELTASPIKE-1369: Remove unneeded throws from execute() methods.
Signed-off-by: Juri Berlanda
> [Scheduler] Enable/Disable based on custom condition
>
>
> Key: DELTASPIKE-1369
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1369
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Scheduler
>Reporter: Juri Berlanda
>Priority: Major
>
> As discussed on the mailing list, I propose to introduce some kind of
> pluggable Bean, which would allow to control both whether the Scheduler as a
> whole should start, as well as to provide a hook for controlling each single
> task invocation.
> The default implementation would always return true on both, which makes sure
> the default behavior is the same as it has always been. Being a Bean, it can
> be customized via CDI mechanisms (Specializes, Alternative, etc.).
> The Bean should provide the following signature:
> {{boolean isSchedulerEnabled();}}
> {{boolean vetoJobExecution(Class);}}
> TBD:
> * Provide support for multiple implementations of {{SchedulerControl}}
> * -Better name for shouldJobBeStarted?- Found
> * -Use JobName in shouldJobBeStarted?- Not needed as discussed on mailing
> list
> Development takes place at
> [https://github.com/j-be/deltaspike/tree/scheduler-control]
> Pull request can be found at https://github.com/apache/deltaspike/pull/84
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1372) Test-Control module has a undeclared and undocumented de-facto runtime dependency on core-impl
[
https://issues.apache.org/jira/browse/DELTASPIKE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794573#comment-16794573
]
ASF subversion and git services commented on DELTASPIKE-1372:
-
Commit 4dca77e08d0ff56d3c34ef9079d5727c3bd2c801 in deltaspike's branch
refs/heads/master from Juri Berlanda
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=4dca77e ]
DELTASPIKE-1372 Fix test-control's dependencies.
Test-Control module has a de-facto runtime dependency on core-impl, which
is neither documented, nor declared in the pom. This commit adds it so
Test-Control works as described in the documentation.
> Test-Control module has a undeclared and undocumented de-facto runtime
> dependency on core-impl
> --
>
> Key: DELTASPIKE-1372
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1372
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.9.0
>Reporter: Juri Berlanda
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When setting up Test-Control Module like described in
> [http://deltaspike.apache.org/documentation/test-control.html] I end up with:
> {{java.lang.ExceptionInInitializerError}}
> {{ at
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.(CdiTestRunner.java:87)}}
> {{ at
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)}}
> {{ at
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)}}
> {{ at
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)}}
> {{ at
> org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)}}
> {{ Caused by: java.lang.RuntimeException: Could not load ConfigProvider}}
> {{ at
> org.apache.deltaspike.core.api.config.ConfigResolver.getConfigProvider(ConfigResolver.java:628)}}
> {{ at
> org.apache.deltaspike.core.api.config.ConfigResolver.resolve(ConfigResolver.java:613)}}
> {{ at
> org.apache.deltaspike.testcontrol.api.junit.TestBaseConfig$ContainerIntegration.(TestBaseConfig.java:29)}}
> {{ ... 15 more}}
> The reason is, that {{deltaspike-core-impl}} is missing on the classpath.
> Adding it solves the problem.
> So imho. we should add a {{runtime}} dependency on {{deltaspike-core-impl}}
> to {{deltaspike-test-control-module-impl}}. It should be a matter of
> replacing {{test}} to {{runtime}} on
> {{deltaspike-core-impl}} in {{deltaspike-test-control-module-impl}}'s
> {{pom.xml}}.
> I'll create a pull-request doing exactly that in a moment.
> EDIT: Pull-request exists at https://github.com/apache/deltaspike/pull/86
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1372) Test-Control module has a undeclared and undocumented de-facto runtime dependency on core-impl
[
https://issues.apache.org/jira/browse/DELTASPIKE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794574#comment-16794574
]
ASF subversion and git services commented on DELTASPIKE-1372:
-
Commit fcb567c9104d59a65953eb5f928901f177a199fe in deltaspike's branch
refs/heads/master from Gerhard Petracek
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=fcb567c ]
Merge pull request #86 from j-be/DELTASPIKE-1372
DELTASPIKE-1372 fixed dependency
> Test-Control module has a undeclared and undocumented de-facto runtime
> dependency on core-impl
> --
>
> Key: DELTASPIKE-1372
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1372
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.9.0
>Reporter: Juri Berlanda
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When setting up Test-Control Module like described in
> [http://deltaspike.apache.org/documentation/test-control.html] I end up with:
> {{java.lang.ExceptionInInitializerError}}
> {{ at
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.(CdiTestRunner.java:87)}}
> {{ at
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)}}
> {{ at
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)}}
> {{ at
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)}}
> {{ at
> org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)}}
> {{ Caused by: java.lang.RuntimeException: Could not load ConfigProvider}}
> {{ at
> org.apache.deltaspike.core.api.config.ConfigResolver.getConfigProvider(ConfigResolver.java:628)}}
> {{ at
> org.apache.deltaspike.core.api.config.ConfigResolver.resolve(ConfigResolver.java:613)}}
> {{ at
> org.apache.deltaspike.testcontrol.api.junit.TestBaseConfig$ContainerIntegration.(TestBaseConfig.java:29)}}
> {{ ... 15 more}}
> The reason is, that {{deltaspike-core-impl}} is missing on the classpath.
> Adding it solves the problem.
> So imho. we should add a {{runtime}} dependency on {{deltaspike-core-impl}}
> to {{deltaspike-test-control-module-impl}}. It should be a matter of
> replacing {{test}} to {{runtime}} on
> {{deltaspike-core-impl}} in {{deltaspike-test-control-module-impl}}'s
> {{pom.xml}}.
> I'll create a pull-request doing exactly that in a moment.
> EDIT: Pull-request exists at https://github.com/apache/deltaspike/pull/86
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1372) Test-Control module has a undeclared and undocumented de-facto runtime dependency on core-impl
[
https://issues.apache.org/jira/browse/DELTASPIKE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794575#comment-16794575
]
ASF subversion and git services commented on DELTASPIKE-1372:
-
Commit fcb567c9104d59a65953eb5f928901f177a199fe in deltaspike's branch
refs/heads/master from Gerhard Petracek
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=fcb567c ]
Merge pull request #86 from j-be/DELTASPIKE-1372
DELTASPIKE-1372 fixed dependency
> Test-Control module has a undeclared and undocumented de-facto runtime
> dependency on core-impl
> --
>
> Key: DELTASPIKE-1372
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1372
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.9.0
>Reporter: Juri Berlanda
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When setting up Test-Control Module like described in
> [http://deltaspike.apache.org/documentation/test-control.html] I end up with:
> {{java.lang.ExceptionInInitializerError}}
> {{ at
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.(CdiTestRunner.java:87)}}
> {{ at
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)}}
> {{ at
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)}}
> {{ at
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)}}
> {{ at
> org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)}}
> {{ Caused by: java.lang.RuntimeException: Could not load ConfigProvider}}
> {{ at
> org.apache.deltaspike.core.api.config.ConfigResolver.getConfigProvider(ConfigResolver.java:628)}}
> {{ at
> org.apache.deltaspike.core.api.config.ConfigResolver.resolve(ConfigResolver.java:613)}}
> {{ at
> org.apache.deltaspike.testcontrol.api.junit.TestBaseConfig$ContainerIntegration.(TestBaseConfig.java:29)}}
> {{ ... 15 more}}
> The reason is, that {{deltaspike-core-impl}} is missing on the classpath.
> Adding it solves the problem.
> So imho. we should add a {{runtime}} dependency on {{deltaspike-core-impl}}
> to {{deltaspike-test-control-module-impl}}. It should be a matter of
> replacing {{test}} to {{runtime}} on
> {{deltaspike-core-impl}} in {{deltaspike-test-control-module-impl}}'s
> {{pom.xml}}.
> I'll create a pull-request doing exactly that in a moment.
> EDIT: Pull-request exists at https://github.com/apache/deltaspike/pull/86
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1373) Fixed documentation Core - Injecting Resources
[
https://issues.apache.org/jira/browse/DELTASPIKE-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796374#comment-16796374
]
ASF subversion and git services commented on DELTASPIKE-1373:
-
Commit 2a4ecc1293dc2aa91927fdb36e2cedb047ff96a3 in deltaspike's branch
refs/heads/master from Daniel Dias
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=2a4ecc1 ]
DELTASPIKE-1373:fix doc core and InjectableResource
> Fixed documentation Core - Injecting Resources
> --
>
> Key: DELTASPIKE-1373
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1373
> Project: DeltaSpike
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 1.9.0
>Reporter: Daniel Dias dos Santos
>Priority: Critical
> Labels: documentation
> Fix For: 1.9.1
>
> Attachments: DELTASPIKE-1373.patch
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> at the following address :
> [https://deltaspike.apache.org/documentation/core.html]
>
> section : Injecting Resources
>
> since in 1.9.0 the same use the location as argument
> contains the annotation "{{@InjectableResource("myfile.properties")}}"
>
> since in 1.9.0 the same use the location as argument :
>
> @InjectableResource(location="myfile.properties")
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1373) Fixed documentation Core - Injecting Resources
[
https://issues.apache.org/jira/browse/DELTASPIKE-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796375#comment-16796375
]
ASF subversion and git services commented on DELTASPIKE-1373:
-
Commit 6de805f9687178eca316b13e59ce717165f90a26 in deltaspike's branch
refs/heads/master from Gerhard Petracek
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=6de805f ]
Merge pull request #87 from Daniel-Dos/adjusts-doc-core
DELTASPIKE-1373 merged pull request
> Fixed documentation Core - Injecting Resources
> --
>
> Key: DELTASPIKE-1373
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1373
> Project: DeltaSpike
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 1.9.0
>Reporter: Daniel Dias dos Santos
>Priority: Critical
> Labels: documentation
> Fix For: 1.9.1
>
> Attachments: DELTASPIKE-1373.patch
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> at the following address :
> [https://deltaspike.apache.org/documentation/core.html]
>
> section : Injecting Resources
>
> since in 1.9.0 the same use the location as argument
> contains the annotation "{{@InjectableResource("myfile.properties")}}"
>
> since in 1.9.0 the same use the location as argument :
>
> @InjectableResource(location="myfile.properties")
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1371) JPACriteriaAPISupport Documentation exemple wrong
[
https://issues.apache.org/jira/browse/DELTASPIKE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16790581#comment-16790581
]
ASF subversion and git services commented on DELTASPIKE-1371:
-
Commit b6c4d89fa62098c0c17fea8d4e2cc666ba2b2a41 in deltaspike's branch
refs/heads/master from Thomas Andraschko
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=b6c4d89 ]
Merge pull request #85 from Daniel-Dos/DELTASPIKE-1371
-DELTASPIKE-1371: Fixed documentation Data Module
> JPACriteriaAPISupport Documentation exemple wrong
> -
>
> Key: DELTASPIKE-1371
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1371
> Project: DeltaSpike
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 1.9.0
>Reporter: Daniel Dias dos Santos
>Priority: Critical
> Labels: documentation
> Fix For: 1.9.1
>
> Attachments: criteria.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> at the following address :
>
> [https://deltaspike.apache.org/documentation/data.html#JPACriteriaAPISupport]
> contains join and boolean examples using criteria, but using the repository
> {{AbstractEntityRepository which does not support criteria ()}}
> {{since it is used with Full or abstractFull}}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1371) JPACriteriaAPISupport Documentation exemple wrong
[
https://issues.apache.org/jira/browse/DELTASPIKE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16790582#comment-16790582
]
ASF subversion and git services commented on DELTASPIKE-1371:
-
Commit b6c4d89fa62098c0c17fea8d4e2cc666ba2b2a41 in deltaspike's branch
refs/heads/master from Thomas Andraschko
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=b6c4d89 ]
Merge pull request #85 from Daniel-Dos/DELTASPIKE-1371
-DELTASPIKE-1371: Fixed documentation Data Module
> JPACriteriaAPISupport Documentation exemple wrong
> -
>
> Key: DELTASPIKE-1371
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1371
> Project: DeltaSpike
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 1.9.0
>Reporter: Daniel Dias dos Santos
>Priority: Critical
> Labels: documentation
> Fix For: 1.9.1
>
> Attachments: criteria.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> at the following address :
>
> [https://deltaspike.apache.org/documentation/data.html#JPACriteriaAPISupport]
> contains join and boolean examples using criteria, but using the repository
> {{AbstractEntityRepository which does not support criteria ()}}
> {{since it is used with Full or abstractFull}}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1371) JPACriteriaAPISupport Documentation exemple wrong
[
https://issues.apache.org/jira/browse/DELTASPIKE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16790580#comment-16790580
]
ASF subversion and git services commented on DELTASPIKE-1371:
-
Commit 42865b1c42284d20c1712e5debc18635b37ecb07 in deltaspike's branch
refs/heads/master from Daniel Dias
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=42865b1 ]
-DELTASPIKE-1371: Fixed documentation Data Module
> JPACriteriaAPISupport Documentation exemple wrong
> -
>
> Key: DELTASPIKE-1371
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1371
> Project: DeltaSpike
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 1.9.0
>Reporter: Daniel Dias dos Santos
>Priority: Critical
> Labels: documentation
> Fix For: 1.9.1
>
> Attachments: criteria.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> at the following address :
>
> [https://deltaspike.apache.org/documentation/data.html#JPACriteriaAPISupport]
> contains join and boolean examples using criteria, but using the repository
> {{AbstractEntityRepository which does not support criteria ()}}
> {{since it is used with Full or abstractFull}}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1382) ClientWindowRenderMode.CLIENTWINDOW breaks Back button in certain Browser/BrowserPlugin combinations
[
https://issues.apache.org/jira/browse/DELTASPIKE-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861045#comment-16861045
]
ASF subversion and git services commented on DELTASPIKE-1382:
-
Commit 82da8a6c5d23513cb6368a642e9ccecc46fcf99a in deltaspike's branch
refs/heads/master from Thomas Andraschko
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=82da8a6 ]
Merge pull request #91 from j-be/DELTASPIKE-1382
DELTASPIKE-1382: Use window.location.replace() for WindowId redirect.
> ClientWindowRenderMode.CLIENTWINDOW breaks Back button in certain
> Browser/BrowserPlugin combinations
>
>
> Key: DELTASPIKE-1382
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1382
> Project: DeltaSpike
> Issue Type: Bug
> Components: JSF-Module
>Affects Versions: 1.9.0
> Environment: Tomcat 9.0.20
> MyFaces 2.3.2
> OpenWebBeans 2.0.8
> DeltaSpike JSF module 1.9.0
> Chrome/Chromium + uBlock Origin (just as one example)
>Reporter: Juri Berlanda
>Priority: Major
> Fix For: 1.9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It seems, that certain Browser / BrowserPlugin combinations start behaving
> weird, if ClientWindowRenderMode.CLIENTWINDOW is used. Known affected
> combinations are:
> * Firefox + Evernote Web Clipper
> * Chrome/Chromium + Evernote Web Clipper
> * Chrome/Chromium + uBlock Origin
> Note: Firefox + uBlock Origin for some reason is NOT affected.
> h1. Preconditions:
> * A JSF application with DeltaSpike JSF Modulke
> * ClientWindowRenderMode.CLIENTWINDOW
> * At least two pages (in the following they are referred to as "index.xhtml"
> and "second.xhtml")
> h1. Steps to reproduce:
> # Load index.xhtml
> # In the same Browser window navigate to second.xhtml - make sure the URL
> used for navigation does NOT contain dswid and dsrid
> # Hit the Back button
> h1. Expected:
> * Browser navigates back to index.xhtml
> h1. Actual (assuming the Browser/BrowserPlugin combination mentioned above):
> * Browser stays on second.xhtml same page (Actually, Browser navigates back
> to second.xhtml without dswid and dsrid and then again to second.xhtml with
> those paramter, but the user hardly notices that)
> h1. Reason / Potential Fix:
> This issue is caused by windowhandler.html using {{window.location =
> redirectUrl;}} and can be fixed by replacing that with
> {{window.location.replace(redirectUrl);}}. Referencing
> https://www.w3schools.com/jsref/met_loc_replace.asp I would say the solution
> is widely supported.
> h1. Further notes:
> * I will shortly create a PullRequest on GitHub referencing this issue
> * If there is need for it, I'd be happy to provide a minimal project
> demonstrating the issue
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1382) ClientWindowRenderMode.CLIENTWINDOW breaks Back button in certain Browser/BrowserPlugin combinations
[
https://issues.apache.org/jira/browse/DELTASPIKE-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861046#comment-16861046
]
ASF subversion and git services commented on DELTASPIKE-1382:
-
Commit 82da8a6c5d23513cb6368a642e9ccecc46fcf99a in deltaspike's branch
refs/heads/master from Thomas Andraschko
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=82da8a6 ]
Merge pull request #91 from j-be/DELTASPIKE-1382
DELTASPIKE-1382: Use window.location.replace() for WindowId redirect.
> ClientWindowRenderMode.CLIENTWINDOW breaks Back button in certain
> Browser/BrowserPlugin combinations
>
>
> Key: DELTASPIKE-1382
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1382
> Project: DeltaSpike
> Issue Type: Bug
> Components: JSF-Module
>Affects Versions: 1.9.0
> Environment: Tomcat 9.0.20
> MyFaces 2.3.2
> OpenWebBeans 2.0.8
> DeltaSpike JSF module 1.9.0
> Chrome/Chromium + uBlock Origin (just as one example)
>Reporter: Juri Berlanda
>Priority: Major
> Fix For: 1.9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It seems, that certain Browser / BrowserPlugin combinations start behaving
> weird, if ClientWindowRenderMode.CLIENTWINDOW is used. Known affected
> combinations are:
> * Firefox + Evernote Web Clipper
> * Chrome/Chromium + Evernote Web Clipper
> * Chrome/Chromium + uBlock Origin
> Note: Firefox + uBlock Origin for some reason is NOT affected.
> h1. Preconditions:
> * A JSF application with DeltaSpike JSF Modulke
> * ClientWindowRenderMode.CLIENTWINDOW
> * At least two pages (in the following they are referred to as "index.xhtml"
> and "second.xhtml")
> h1. Steps to reproduce:
> # Load index.xhtml
> # In the same Browser window navigate to second.xhtml - make sure the URL
> used for navigation does NOT contain dswid and dsrid
> # Hit the Back button
> h1. Expected:
> * Browser navigates back to index.xhtml
> h1. Actual (assuming the Browser/BrowserPlugin combination mentioned above):
> * Browser stays on second.xhtml same page (Actually, Browser navigates back
> to second.xhtml without dswid and dsrid and then again to second.xhtml with
> those paramter, but the user hardly notices that)
> h1. Reason / Potential Fix:
> This issue is caused by windowhandler.html using {{window.location =
> redirectUrl;}} and can be fixed by replacing that with
> {{window.location.replace(redirectUrl);}}. Referencing
> https://www.w3schools.com/jsref/met_loc_replace.asp I would say the solution
> is widely supported.
> h1. Further notes:
> * I will shortly create a PullRequest on GitHub referencing this issue
> * If there is need for it, I'd be happy to provide a minimal project
> demonstrating the issue
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1382) ClientWindowRenderMode.CLIENTWINDOW breaks Back button in certain Browser/BrowserPlugin combinations
[
https://issues.apache.org/jira/browse/DELTASPIKE-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861044#comment-16861044
]
ASF subversion and git services commented on DELTASPIKE-1382:
-
Commit 8ff76c7df591d271103f7253451110568d227e82 in deltaspike's branch
refs/heads/master from Juri Berlanda
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=8ff76c7 ]
DELTASPIKE-1382: Use window.location.replace() for WindowId redirect.
While assigning window.location directly seems to work well in most of the
cases, it manages to break Browser's back button if certain plugins are
installed.
Signed-off-by: Juri Berlanda
> ClientWindowRenderMode.CLIENTWINDOW breaks Back button in certain
> Browser/BrowserPlugin combinations
>
>
> Key: DELTASPIKE-1382
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1382
> Project: DeltaSpike
> Issue Type: Bug
> Components: JSF-Module
>Affects Versions: 1.9.0
> Environment: Tomcat 9.0.20
> MyFaces 2.3.2
> OpenWebBeans 2.0.8
> DeltaSpike JSF module 1.9.0
> Chrome/Chromium + uBlock Origin (just as one example)
>Reporter: Juri Berlanda
>Priority: Major
> Fix For: 1.9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It seems, that certain Browser / BrowserPlugin combinations start behaving
> weird, if ClientWindowRenderMode.CLIENTWINDOW is used. Known affected
> combinations are:
> * Firefox + Evernote Web Clipper
> * Chrome/Chromium + Evernote Web Clipper
> * Chrome/Chromium + uBlock Origin
> Note: Firefox + uBlock Origin for some reason is NOT affected.
> h1. Preconditions:
> * A JSF application with DeltaSpike JSF Modulke
> * ClientWindowRenderMode.CLIENTWINDOW
> * At least two pages (in the following they are referred to as "index.xhtml"
> and "second.xhtml")
> h1. Steps to reproduce:
> # Load index.xhtml
> # In the same Browser window navigate to second.xhtml - make sure the URL
> used for navigation does NOT contain dswid and dsrid
> # Hit the Back button
> h1. Expected:
> * Browser navigates back to index.xhtml
> h1. Actual (assuming the Browser/BrowserPlugin combination mentioned above):
> * Browser stays on second.xhtml same page (Actually, Browser navigates back
> to second.xhtml without dswid and dsrid and then again to second.xhtml with
> those paramter, but the user hardly notices that)
> h1. Reason / Potential Fix:
> This issue is caused by windowhandler.html using {{window.location =
> redirectUrl;}} and can be fixed by replacing that with
> {{window.location.replace(redirectUrl);}}. Referencing
> https://www.w3schools.com/jsref/met_loc_replace.asp I would say the solution
> is widely supported.
> h1. Further notes:
> * I will shortly create a PullRequest on GitHub referencing this issue
> * If there is need for it, I'd be happy to provide a minimal project
> demonstrating the issue
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1378) EntityManagerRefLookup returns null globalEntityManager when lazyInitGlobalEntityManager is called by multiple threads
[ https://issues.apache.org/jira/browse/DELTASPIKE-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839831#comment-16839831 ] ASF subversion and git services commented on DELTASPIKE-1378: - Commit eb6ae03a3286232ad0606d2f2bf6f4eb82607ab6 in deltaspike's branch refs/heads/master from Gerhard Petracek [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=eb6ae03 ] DELTASPIKE-1378 fixed initialization of EntityManagerRefLookup > EntityManagerRefLookup returns null globalEntityManager when > lazyInitGlobalEntityManager is called by multiple threads > -- > > Key: DELTASPIKE-1378 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1378 > Project: DeltaSpike > Issue Type: Bug > Components: JPA-Module >Affects Versions: 1.9.0 >Reporter: Raymond Domingo >Assignee: Thomas Andraschko >Priority: Major > Fix For: 1.9.1 > > > *Situation* > If multiple threads invoke lazyInitGlobalEntityManager at same time and > lazyInitGlobalEntityManager isn't invoked before. Some of these threads might > end up with a null entitymanager, because lazyInitGlobalEntityManager isn't > synchronized (or this.globalEntityManagerInitialized = true is at wrong > place). > Might be *important* to fix this, because In rare situations this might break > your application and even cause inconsistent data. > *Problem* > entityManager is null after initialization is concurrently called > *Expected* > entityManager won't be null when initialized concurrently > > *PR* > [https://github.com/apache/deltaspike/pull/89] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1383) Authorizer is marked initialized before being fully initialed. NullPointerException follows.
[
https://issues.apache.org/jira/browse/DELTASPIKE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16873585#comment-16873585
]
ASF subversion and git services commented on DELTASPIKE-1383:
-
Commit d95495b81b52f15f4712ba062c404eb33ecc892b in deltaspike's branch
refs/heads/master from hidde.wieringa
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=d95495b ]
DELTASPIKE-1383 Fix multiple threads causing NPE in Authorizer
> Authorizer is marked initialized before being fully initialed.
> NullPointerException follows.
>
>
> Key: DELTASPIKE-1383
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1383
> Project: DeltaSpike
> Issue Type: Bug
> Components: Security-Module
>Affects Versions: 1.8.0, 1.8.1, 1.8.2, 1.9.0
>Reporter: Hidde Wieringa
>Assignee: Gerhard Petracek
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Similar to DELTASPIKE-1378!
> Authorizer is marked initialized before being fully initialed. A
> NullPointerException follows.
> This is caused by {{boundAuthorizerBean}} being used for determining if the
> Authorizer is initialized. Futhermore {{boundAuthorizerMethodProxy}} is also
> initialized in that method, and used elsewhere. Another thread can see the
> non-null {{boundAuthorizerBean}} and assume {{boundAuthorizerMethodProxy}} is
> also non-null. This results in a nullpointer exception.
> Stack trace (with some class names removed):
> {noformat}
> 14:17:14.541 [XNIO-1 task-3] ERROR c.n.h.g.h.u.h.DelegateExceptionHandler
> - java.lang.NullPointerException
> org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> at
> org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:78)
> at
> org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:222)
> at
> org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175)
> at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418)
> at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
> at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:106)
> at
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at javax.servlet.FilterChain$doFilter.call(Unknown Source)
> at
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:31)
> at
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:50)
> at
> xxx..xx.xx.XxFilter$$OwbInterceptProxy0.doFilter(XxFilter.java)
> at
> xxx..xx.xx.XxFilter$$OwbNormalScopeProxy0.doFilter(XxFilter.java)
> at
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
>
[jira] [Commented] (DELTASPIKE-1377) issue with @Repository + @Query annotation and clustered wildfly
[
https://issues.apache.org/jira/browse/DELTASPIKE-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886039#comment-16886039
]
ASF subversion and git services commented on DELTASPIKE-1377:
-
Commit ab2fa0d1715084a364c666504ad4b4ea74a23cdc in deltaspike's branch
refs/heads/master from Mark Struberg
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=ab2fa0d ]
DELTASPIKE-1377 fix array handling for native types
> issue with @Repository + @Query annotation and clustered wildfly
> -
>
> Key: DELTASPIKE-1377
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1377
> Project: DeltaSpike
> Issue Type: Bug
> Components: Data-Module
>Affects Versions: 1.9.0
>Reporter: Andrew Schmidt
>Assignee: Mark Struberg
>Priority: Major
> Attachments: cdri-test.zip, stack.txt
>
>
> Setup: 2 x wildfly 15.0.1.Final (weld-core updated to 3.0.6)
> Clustered standalone-full-ha setup, same machine with a port offset for the
> second machine.
>
> Repo:
> {code:java}
> @Repository
> @ApplicationScoped
> public interface AnimalRepo extends EntityRepository
> {
>@Query( value = "select a from Animal a where ?1 = a.name" )
>Animal findByName(String name);
> }
> {code}
> Session bean:
> {code:java}
> @SessionScoped
> @Named
> public class MyBean implements Serializable
> {
> private static final long serialVersionUID = 1L;
> @Inject
> private AnimalRepo animalRepo;
> public Long getTest()
> {
> return animalRepo.count();
> }
> }
> {code}
> index.xhtml
> {code:java}
>
> #{myBean.test}
>
> {code}
> Visiting the first server yields no error, but upon visiting the second
> server:
> {code:java}
> WELD-001500: Failed to deserialize proxy object with beanId
> org.apache.deltaspike.core.util.bean.ImmutableBeanWrapper:AnimalRepo[@javax.enterprise.context.ApplicationScoped()@org.apache.deltaspike.data.api.Repository(forEntity=class
>
> java.lang.Object,methodPrefix=)]{AnimalRepo.findByName[@org.apache.deltaspike.data.api.Query(hints=[Ljavax.persistence.QueryHint;@774c6737,isNative=false,lock=NONE,max=0,named=,singleResult=JPA,value=select
> a from Animal where ?1 = a.name)](java.lang.String);}
> {code}
> Interestingly, If the @Query annotation is removed from the findByName
> query, there is no issue.
> See attached project.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (DELTASPIKE-1377) issue with @Repository + @Query annotation and clustered wildfly
[
https://issues.apache.org/jira/browse/DELTASPIKE-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886038#comment-16886038
]
ASF subversion and git services commented on DELTASPIKE-1377:
-
Commit 6f7de55890adb92fca49985380fe9dfb65e821f8 in deltaspike's branch
refs/heads/master from Vladimir Dvorak
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=6f7de55 ]
DELTASPIKE-1377 fix typeId evaluation
Signed-off-by: Mark Struberg
> issue with @Repository + @Query annotation and clustered wildfly
> -
>
> Key: DELTASPIKE-1377
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1377
> Project: DeltaSpike
> Issue Type: Bug
> Components: Data-Module
>Affects Versions: 1.9.0
>Reporter: Andrew Schmidt
>Assignee: Mark Struberg
>Priority: Major
> Attachments: cdri-test.zip, stack.txt
>
>
> Setup: 2 x wildfly 15.0.1.Final (weld-core updated to 3.0.6)
> Clustered standalone-full-ha setup, same machine with a port offset for the
> second machine.
>
> Repo:
> {code:java}
> @Repository
> @ApplicationScoped
> public interface AnimalRepo extends EntityRepository
> {
>@Query( value = "select a from Animal a where ?1 = a.name" )
>Animal findByName(String name);
> }
> {code}
> Session bean:
> {code:java}
> @SessionScoped
> @Named
> public class MyBean implements Serializable
> {
> private static final long serialVersionUID = 1L;
> @Inject
> private AnimalRepo animalRepo;
> public Long getTest()
> {
> return animalRepo.count();
> }
> }
> {code}
> index.xhtml
> {code:java}
>
> #{myBean.test}
>
> {code}
> Visiting the first server yields no error, but upon visiting the second
> server:
> {code:java}
> WELD-001500: Failed to deserialize proxy object with beanId
> org.apache.deltaspike.core.util.bean.ImmutableBeanWrapper:AnimalRepo[@javax.enterprise.context.ApplicationScoped()@org.apache.deltaspike.data.api.Repository(forEntity=class
>
> java.lang.Object,methodPrefix=)]{AnimalRepo.findByName[@org.apache.deltaspike.data.api.Query(hints=[Ljavax.persistence.QueryHint;@774c6737,isNative=false,lock=NONE,max=0,named=,singleResult=JPA,value=select
> a from Animal where ?1 = a.name)](java.lang.String);}
> {code}
> Interestingly, If the @Query annotation is removed from the findByName
> query, there is no issue.
> See attached project.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (DELTASPIKE-1377) issue with @Repository + @Query annotation and clustered wildfly
[
https://issues.apache.org/jira/browse/DELTASPIKE-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886063#comment-16886063
]
ASF subversion and git services commented on DELTASPIKE-1377:
-
Commit 7909fc405176ab4f718f3901350983e81378ac37 in deltaspike's branch
refs/heads/master from Mark Struberg
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=7909fc4 ]
DELTASPIKE-1377 also fix issue with nested arrays
txs to Vladimir Dvorak (skybber) for the report and parts of the patch.
> issue with @Repository + @Query annotation and clustered wildfly
> -
>
> Key: DELTASPIKE-1377
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1377
> Project: DeltaSpike
> Issue Type: Bug
> Components: Data-Module
>Affects Versions: 1.9.0
>Reporter: Andrew Schmidt
>Assignee: Mark Struberg
>Priority: Major
> Attachments: cdri-test.zip, stack.txt
>
>
> Setup: 2 x wildfly 15.0.1.Final (weld-core updated to 3.0.6)
> Clustered standalone-full-ha setup, same machine with a port offset for the
> second machine.
>
> Repo:
> {code:java}
> @Repository
> @ApplicationScoped
> public interface AnimalRepo extends EntityRepository
> {
>@Query( value = "select a from Animal a where ?1 = a.name" )
>Animal findByName(String name);
> }
> {code}
> Session bean:
> {code:java}
> @SessionScoped
> @Named
> public class MyBean implements Serializable
> {
> private static final long serialVersionUID = 1L;
> @Inject
> private AnimalRepo animalRepo;
> public Long getTest()
> {
> return animalRepo.count();
> }
> }
> {code}
> index.xhtml
> {code:java}
>
> #{myBean.test}
>
> {code}
> Visiting the first server yields no error, but upon visiting the second
> server:
> {code:java}
> WELD-001500: Failed to deserialize proxy object with beanId
> org.apache.deltaspike.core.util.bean.ImmutableBeanWrapper:AnimalRepo[@javax.enterprise.context.ApplicationScoped()@org.apache.deltaspike.data.api.Repository(forEntity=class
>
> java.lang.Object,methodPrefix=)]{AnimalRepo.findByName[@org.apache.deltaspike.data.api.Query(hints=[Ljavax.persistence.QueryHint;@774c6737,isNative=false,lock=NONE,max=0,named=,singleResult=JPA,value=select
> a from Animal where ?1 = a.name)](java.lang.String);}
> {code}
> Interestingly, If the @Query annotation is removed from the findByName
> query, there is no issue.
> See attached project.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (DELTASPIKE-1383) Authorizer is marked initialized before being fully initialed. NullPointerException follows.
[
https://issues.apache.org/jira/browse/DELTASPIKE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874021#comment-16874021
]
ASF subversion and git services commented on DELTASPIKE-1383:
-
Commit 2ae479efbafe7e09b1d43b3ed9ff00ef51985072 in deltaspike's branch
refs/heads/master from Gerhard Petracek
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=2ae479e ]
DELTASPIKE-1383 fixed formatting
> Authorizer is marked initialized before being fully initialed.
> NullPointerException follows.
>
>
> Key: DELTASPIKE-1383
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1383
> Project: DeltaSpike
> Issue Type: Bug
> Components: Security-Module
>Affects Versions: 1.8.0, 1.8.1, 1.8.2, 1.9.0
>Reporter: Hidde Wieringa
>Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Similar to DELTASPIKE-1378!
> Authorizer is marked initialized before being fully initialed. A
> NullPointerException follows.
> This is caused by {{boundAuthorizerBean}} being used for determining if the
> Authorizer is initialized. Futhermore {{boundAuthorizerMethodProxy}} is also
> initialized in that method, and used elsewhere. Another thread can see the
> non-null {{boundAuthorizerBean}} and assume {{boundAuthorizerMethodProxy}} is
> also non-null. This results in a nullpointer exception.
> Stack trace (with some class names removed):
> {noformat}
> 14:17:14.541 [XNIO-1 task-3] ERROR c.n.h.g.h.u.h.DelegateExceptionHandler
> - java.lang.NullPointerException
> org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> at
> org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:78)
> at
> org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:222)
> at
> org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175)
> at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418)
> at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
> at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:106)
> at
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at javax.servlet.FilterChain$doFilter.call(Unknown Source)
> at
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:31)
> at
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> xxx..xx.xx.XxFilter.doFilter(XxFilter.groovy:50)
> at
> xxx..xx.xx.XxFilter$$OwbInterceptProxy0.doFilter(XxFilter.java)
> at
> xxx..xx.xx.XxFilter$$OwbNormalScopeProxy0.doFilter(XxFilter.java)
> at
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
>
[jira] [Commented] (DELTASPIKE-1385) support init under high load
[ https://issues.apache.org/jira/browse/DELTASPIKE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905552#comment-16905552 ] ASF subversion and git services commented on DELTASPIKE-1385: - Commit 8936f921f39d270ecd5cc762d92c0b66f579b61d in deltaspike's branch refs/heads/master from Gerhard Petracek [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=8936f92 ] DELTASPIKE-1385 added support for init under high load > support init under high load > > > Key: DELTASPIKE-1385 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1385 > Project: DeltaSpike > Issue Type: Improvement > Components: BeanValidation-Module, Core, JSF-Module >Affects Versions: 1.9.0 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.9.1 > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (DELTASPIKE-1385) support init under high load
[ https://issues.apache.org/jira/browse/DELTASPIKE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905551#comment-16905551 ] ASF subversion and git services commented on DELTASPIKE-1385: - Commit 752a4a57fa79a939dc1713d4c8bbc83b3fc6df5e in deltaspike's branch refs/heads/master from Gerhard Petracek [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=752a4a5 ] DELTASPIKE-1385 added support for init under high load > support init under high load > > > Key: DELTASPIKE-1385 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1385 > Project: DeltaSpike > Issue Type: Improvement > Components: BeanValidation-Module, Core, JSF-Module >Affects Versions: 1.9.0 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.9.1 > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (DELTASPIKE-1385) support init under high load
[ https://issues.apache.org/jira/browse/DELTASPIKE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905550#comment-16905550 ] ASF subversion and git services commented on DELTASPIKE-1385: - Commit 8cc79884c6e2d0490eaa3a3c69dc6d0073973783 in deltaspike's branch refs/heads/master from Gerhard Petracek [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=8cc7988 ] DELTASPIKE-1385 added support for init under high load > support init under high load > > > Key: DELTASPIKE-1385 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1385 > Project: DeltaSpike > Issue Type: Improvement > Components: BeanValidation-Module, Core, JSF-Module >Affects Versions: 1.9.0 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 1.9.1 > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (DELTASPIKE-1396) Incorrect parameter meaning in AbstractQuartzScheduler.stop of Scheduler Module
[ https://issues.apache.org/jira/browse/DELTASPIKE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969891#comment-16969891 ] ASF subversion and git services commented on DELTASPIKE-1396: - Commit c7b3a2ea084c40066b533de13f57b28eb21da876 in deltaspike's branch refs/heads/master from Mark Struberg [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=c7b3a2e ] DELTASPIKE-1396 switch default to false for backward compat reasons Since the deltaspike.scheduler.force_stop logic was inverted we now also have to invert the default from TRUE to FALSE as noted by Gary Hodgson. > Incorrect parameter meaning in AbstractQuartzScheduler.stop of Scheduler > Module > --- > > Key: DELTASPIKE-1396 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1396 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Gary Hodgson >Assignee: Mark Struberg >Priority: Major > Fix For: 1.9.2 > > Time Spent: 10m > Remaining Estimate: 0h > > The AbstractQuartzScheduler.stop method calls the shutdown method of the > Quartz scheduler with the base config of "deltaspike.scheduler.force_stop": > > this.scheduler.shutdown(SchedulerBaseConfig.LifecycleIntegration.FORCE_STOP); > > ([https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/impl/src/main/java/org/apache/deltaspike/scheduler/impl/AbstractQuartzScheduler.java#L161]) > However the parameter is called waitForJobsToComplete > * @param waitForJobsToComplete > * if true the scheduler will not allow this method > * to return until all currently executing jobs have completed. > which means the config actually does the opposite of what it intends, i.e. > deltaspike.scheduler.force_stop=true would actually wait for the executing > jobs to complete rather than stopping immediately. > I presume this would be fixed by negating the parameter: > > this.scheduler.shutdown(!SchedulerBaseConfig.LifecycleIntegration.FORCE_STOP); > > Mailing List Thread: > [https://lists.apache.org/thread.html/366d51433ea5c5deb7e1d83e09891e426bff9cae0eb6bff98990eb40@%3Cusers.deltaspike.apache.org%3E] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1396) Incorrect parameter meaning in AbstractQuartzScheduler.stop of Scheduler Module
[ https://issues.apache.org/jira/browse/DELTASPIKE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969612#comment-16969612 ] ASF subversion and git services commented on DELTASPIKE-1396: - Commit 4794da1f7cd2e566a4c241c8ea6d74ee523d3c3a in deltaspike's branch refs/heads/master from Mark Struberg [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=4794da1 ] DELTASPIKE-1396 inverted waitForJobsToComplete logic txs to Gary Hodgson for the report and catch! > Incorrect parameter meaning in AbstractQuartzScheduler.stop of Scheduler > Module > --- > > Key: DELTASPIKE-1396 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1396 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Gary Hodgson >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The AbstractQuartzScheduler.stop method calls the shutdown method of the > Quartz scheduler with the base config of "deltaspike.scheduler.force_stop": > > this.scheduler.shutdown(SchedulerBaseConfig.LifecycleIntegration.FORCE_STOP); > > ([https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/impl/src/main/java/org/apache/deltaspike/scheduler/impl/AbstractQuartzScheduler.java#L161]) > However the parameter is called waitForJobsToComplete > * @param waitForJobsToComplete > * if true the scheduler will not allow this method > * to return until all currently executing jobs have completed. > which means the config actually does the opposite of what it intends, i.e. > deltaspike.scheduler.force_stop=true would actually wait for the executing > jobs to complete rather than stopping immediately. > I presume this would be fixed by negating the parameter: > > this.scheduler.shutdown(!SchedulerBaseConfig.LifecycleIntegration.FORCE_STOP); > > Mailing List Thread: > [https://lists.apache.org/thread.html/366d51433ea5c5deb7e1d83e09891e426bff9cae0eb6bff98990eb40@%3Cusers.deltaspike.apache.org%3E] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1364) Variable Replacement with @ConfigProperty not project stage aware
[
https://issues.apache.org/jira/browse/DELTASPIKE-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971205#comment-16971205
]
ASF subversion and git services commented on DELTASPIKE-1364:
-
Commit 63bbcfb75f437c7cee2578c07a4131e18e709ecf in deltaspike's branch
refs/heads/master from Mark Struberg
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=63bbcfb ]
DELTASPIKE-1364 Variables in @ConfigProperty
Unit test only.
Seems I already fixed that while reworking the Config to an interface.
> Variable Replacement with @ConfigProperty not project stage aware
> -
>
> Key: DELTASPIKE-1364
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1364
> Project: DeltaSpike
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 1.8.2
>Reporter: Nicolò Chieffo
>Assignee: Mark Struberg
>Priority: Major
>
> reading a property with injection does not correctly use project stage
> properties.
> I have a property file with this content:
>
> {code:java}
> xxx.frontend.prefix=https://dev.xxx.it
> xxx.frontend.prefix.Production=https://prod.xxx.it
> xxx.rsalogin.url=${xxx.frontend.prefix}/#/rsalogin/{rsalogin}
> {code}
>
>
> when reading xxx.rsalogin.url using annontations
> {code:java}
> @Inject
> @ConfigProperty(name = "xxx.rsalogin.url")
> private String url;
> {code}
> In the production environment (noticed that I don't have a
> org.apache.deltaspike.ProjectStage=Production property set because by default
> the stage is Production) it should be evaluated as
> *[https://prod.xxx.it/#/rsalogin/\{rsalogin}|https://prod.xxx.it/#/rsalogin/]*
> but instead I get
> *[https://dev.xxx.it/#/rsalogin/\{rsalogin}|https://dev.xxx.it/#/rsalogin/]*
> When using the declarative API it works correctly
> {code:java}
> ConfigResolver.getProjectStageAwarePropertyValue("xxx.rsalogin.url",
> "");{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1398) Weblogic memory leak
[
https://issues.apache.org/jira/browse/DELTASPIKE-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16994602#comment-16994602
]
ASF subversion and git services commented on DELTASPIKE-1398:
-
Commit 02e33e5125b995a184e7678f0938ad107e98cd2e in deltaspike's branch
refs/heads/master from Thomas Andraschko
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=02e33e5 ]
DELTASPIKE-1398 - fixed delegation and change it to more agressive use of
CDI.current. This also fixes the mem leak as our caching isn't used anymore.
> Weblogic memory leak
>
>
> Key: DELTASPIKE-1398
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1398
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Core
>Affects Versions: 1.8.0
>Reporter: THEODOROS CHAIKALIS
>Priority: Blocker
> Fix For: 1.9.2
>
> Attachments: mleak-1.png, mleak-2-leak.png, mleak-2.png,
> mleak-debug1.png, mleak-debug2.png, mleak-debug3.png, server_small.war,
> server_small.zip
>
>
> This extends previously reported issue 1392
> Iam returning back to a previously reported serious memory leak in Weblogic
> 12.2.1-3.
> To be more precise: EJB helpler classes (EJBName_randomChars_NoIntfViewImpl)
> are not being garbage collected after application removal.
>
> Steps to reproduce:
>
> # deploy the attached war (server-small)
> # {{open the webpage at /server-small/views/index.xhtml (mleak2)}}
> # monitor the classes created with a profiler (with starting name
> gr.teohaik...) (mleak1)
> # delete the app
> # check again the profiler. The ejbs are still there! (mleak3)
>
> A suggestion in 1392 was to debug BeanManagerProvider, so we did.
> {{but bpmSingleton.bminfos contains 2 objects. but method }}
> {{cleanupStoredBeanManagerOnShutdown(@Observes BeforeShutdown beforeShutdown)
> }}
> {{is called only once}}
> Attached you can see relevant object contents in the debugger screenshots
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1386) Unhandled Exception in DefaultConfigSourceProvider causes deployment failure
[
https://issues.apache.org/jira/browse/DELTASPIKE-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952249#comment-16952249
]
ASF subversion and git services commented on DELTASPIKE-1386:
-
Commit 0eff953a7e5a4df01ab8ded7a1737fd9278178a3 in deltaspike's branch
refs/heads/master from Mark Struberg
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=0eff953 ]
DELTASPIKE-1386 check SecurityAccess when accessing user home dir
txs to Thomas Frühbeck for the report!
> Unhandled Exception in DefaultConfigSourceProvider causes deployment failure
>
>
> Key: DELTASPIKE-1386
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1386
> Project: DeltaSpike
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.9.1
>Reporter: Thomas Frühbeck
>Assignee: Mark Struberg
>Priority: Major
>
> For some reason DefaultConfigSourceProvider tries to access the home
> directory of the services user.
> If the access is prohibited by SecurityManager, the AccessControlException is
> not handled and the deployment of the complete application fails.
> 2019-09-15 23:19:21,075 ERROR [org.jboss.msc.service.fail] (MSC service
> thread 1-6) MSC01: Failed to start service
> jboss.deployment.unit."mssms-sec-ear.ear".POST_MODULE:
> org.jboss.msc.service.StartException in service jboss.
> deployment.unit."mssms-sec-ear.ear".POST_MODULE: WFLYSRV0153: Failed to
> process phase POST_MODULE of deployment "mssms-sec-ear.ear"
> at
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.util.ServiceConfigurationError:
> org.apache.deltaspike.core.spi.config.ConfigSourceProvider: Provider
> org.apache.deltaspike.core.impl.config.DefaultConfigSourceProvider could not
> be instantiated
> at java.util.ServiceLoader.fail(ServiceLoader.java:232)
> at java.util.ServiceLoader.access$100(ServiceLoader.java:185)
> at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:384)
> at java.util.ServiceLoader$LazyIterator.access$700(ServiceLoader.java:323)
> at java.util.ServiceLoader$LazyIterator$2.run(ServiceLoader.java:407)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:409)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at
> org.apache.deltaspike.core.util.ServiceUtils.loadServiceImplementations(ServiceUtils.java:81)
> at org.apache.deltaspike.core.impl.config.ConfigImpl.init(ConfigImpl.java:70)
> at
> org.apache.deltaspike.core.impl.config.ConfigProviderImpl.getConfig(ConfigProviderImpl.java:53)
> at
> org.apache.deltaspike.core.impl.config.ConfigProviderImpl.getConfig(ConfigProviderImpl.java:43)
> at
> org.apache.deltaspike.core.api.config.ConfigResolver.resolve(ConfigResolver.java:613)
> at
> org.apache.deltaspike.core.api.config.base.CoreBaseConfig$BeanManagerIntegration.(CoreBaseConfig.java:30)
> at
> org.apache.deltaspike.core.api.provider.BeanManagerProvider.(BeanManagerProvider.java:79)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at
> org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:53)
> at
> org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:121)
> at
> org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81)
> at
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: java.security.AccessControlException: WFSM01: Permission check
> failed (permission "("java.io.FilePermission"
> "/home/thomas/.deltaspike/apache-deltaspike.properties" "read")" in code
> source "(vfs:/work/java/mssms/w
> ildfly1011/standalone/deployments/mssms-sec-ear.ear/lib/deltaspike-core-api-1.9.0.jar
> )" of "null")
> at
>
[jira] [Commented] (DELTASPIKE-1388) Can't extend Repository defined as an interface
[
https://issues.apache.org/jira/browse/DELTASPIKE-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946626#comment-16946626
]
ASF subversion and git services commented on DELTASPIKE-1388:
-
Commit ae9f7523ffee786576ee76429d9632f90f4e8b1b in deltaspike's branch
refs/heads/master from Tomasz Wyszomirski
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=ae9f752 ]
DELTASPIKE-1388 - Fix initialization issue when using repos extended on
interface.
> Can't extend Repository defined as an interface
> ---
>
> Key: DELTASPIKE-1388
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1388
> Project: DeltaSpike
> Issue Type: Bug
> Components: Data-Module
>Affects Versions: 1.9.1
>Reporter: Tomasz Wyszomirski
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When I define my repository of interface like this:
> @Repository
> public interface SuperRepository extends FullEntityRepository< MyEntity,
> Long>{}
> and try to extend it like this:
> @Repository
> public interface ExtendedRepository extends SuperRepository {}
>
> I get initialization failure in:
> org.apache.deltaspike.data.impl.metaEntityMetadataInitializer#init(RepositoryMetadata)[39]
> Caused by: java.lang.NullPointerException
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.EntityMetadataInitializer.init(EntityMetadataInitializer.java:39)
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.EntityMetadataInitializer$Proxy$_$$_WeldClientProxy.init(Unknown
> Source)
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.RepositoryMetadataInitializer.init(RepositoryMetadataInitializer.java:83)
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.RepositoryMetadataInitializer$Proxy$_$$_WeldClientProxy.init(Unknown
> Source)
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.RepositoryMetadataHandler.init(RepositoryMetadataHandler.java:50)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1388) Can't extend Repository defined as an interface
[
https://issues.apache.org/jira/browse/DELTASPIKE-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946627#comment-16946627
]
ASF subversion and git services commented on DELTASPIKE-1388:
-
Commit 7cfff5a23812520073286e427583e020cd87c932 in deltaspike's branch
refs/heads/master from Thomas Andraschko
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=7cfff5a ]
Merge pull request #97 from twyszomirski/DELTASPIKE-1388
DELTASPIKE-1388 - Fix initialization issue when using repos extended on
interface
> Can't extend Repository defined as an interface
> ---
>
> Key: DELTASPIKE-1388
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1388
> Project: DeltaSpike
> Issue Type: Bug
> Components: Data-Module
>Affects Versions: 1.9.1
>Reporter: Tomasz Wyszomirski
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When I define my repository of interface like this:
> @Repository
> public interface SuperRepository extends FullEntityRepository< MyEntity,
> Long>{}
> and try to extend it like this:
> @Repository
> public interface ExtendedRepository extends SuperRepository {}
>
> I get initialization failure in:
> org.apache.deltaspike.data.impl.metaEntityMetadataInitializer#init(RepositoryMetadata)[39]
> Caused by: java.lang.NullPointerException
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.EntityMetadataInitializer.init(EntityMetadataInitializer.java:39)
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.EntityMetadataInitializer$Proxy$_$$_WeldClientProxy.init(Unknown
> Source)
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.RepositoryMetadataInitializer.init(RepositoryMetadataInitializer.java:83)
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.RepositoryMetadataInitializer$Proxy$_$$_WeldClientProxy.init(Unknown
> Source)
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.RepositoryMetadataHandler.init(RepositoryMetadataHandler.java:50)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1388) Can't extend Repository defined as an interface
[
https://issues.apache.org/jira/browse/DELTASPIKE-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946628#comment-16946628
]
ASF subversion and git services commented on DELTASPIKE-1388:
-
Commit 7cfff5a23812520073286e427583e020cd87c932 in deltaspike's branch
refs/heads/master from Thomas Andraschko
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=7cfff5a ]
Merge pull request #97 from twyszomirski/DELTASPIKE-1388
DELTASPIKE-1388 - Fix initialization issue when using repos extended on
interface
> Can't extend Repository defined as an interface
> ---
>
> Key: DELTASPIKE-1388
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1388
> Project: DeltaSpike
> Issue Type: Bug
> Components: Data-Module
>Affects Versions: 1.9.1
>Reporter: Tomasz Wyszomirski
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When I define my repository of interface like this:
> @Repository
> public interface SuperRepository extends FullEntityRepository< MyEntity,
> Long>{}
> and try to extend it like this:
> @Repository
> public interface ExtendedRepository extends SuperRepository {}
>
> I get initialization failure in:
> org.apache.deltaspike.data.impl.metaEntityMetadataInitializer#init(RepositoryMetadata)[39]
> Caused by: java.lang.NullPointerException
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.EntityMetadataInitializer.init(EntityMetadataInitializer.java:39)
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.EntityMetadataInitializer$Proxy$_$$_WeldClientProxy.init(Unknown
> Source)
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.RepositoryMetadataInitializer.init(RepositoryMetadataInitializer.java:83)
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.RepositoryMetadataInitializer$Proxy$_$$_WeldClientProxy.init(Unknown
> Source)
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.RepositoryMetadataHandler.init(RepositoryMetadataHandler.java:50)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1387) Update ASM to 7.2
[ https://issues.apache.org/jira/browse/DELTASPIKE-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16944474#comment-16944474 ] ASF subversion and git services commented on DELTASPIKE-1387: - Commit 2633035598ea0d44db9ea157f8bcadfadcf50ba9 in deltaspike's branch refs/heads/master from Christian Beikov [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=2633035 ] DELTASPIKE-1387 - Update ASM to 7.1 for Java 13 support > Update ASM to 7.2 > - > > Key: DELTASPIKE-1387 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1387 > Project: DeltaSpike > Issue Type: Improvement > Components: Proxy-Module >Affects Versions: 1.9.1 >Reporter: Christian Beikov >Priority: Major > Fix For: 1.9.2 > > Time Spent: 3h > Remaining Estimate: 0h > > Java 13 was just released and has a new class file version and ASM 7.0 does > not have support for that. ASM 7.2 on the other hand already does. Since it's > a minor update, please get that into 1.9.2 so we can start testing with Java > 13. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1387) Update ASM to 7.2
[ https://issues.apache.org/jira/browse/DELTASPIKE-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16944475#comment-16944475 ] ASF subversion and git services commented on DELTASPIKE-1387: - Commit 966d6dd326d742699d65827e7512c60f4f2db5a4 in deltaspike's branch refs/heads/master from Thomas Andraschko [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=966d6dd ] Merge pull request #96 from beikov/patch-1 DELTASPIKE-1387 - Update ASM to 7.2 for Java 13 support > Update ASM to 7.2 > - > > Key: DELTASPIKE-1387 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1387 > Project: DeltaSpike > Issue Type: Improvement > Components: Proxy-Module >Affects Versions: 1.9.1 >Reporter: Christian Beikov >Priority: Major > Fix For: 1.9.2 > > Time Spent: 3h > Remaining Estimate: 0h > > Java 13 was just released and has a new class file version and ASM 7.0 does > not have support for that. ASM 7.2 on the other hand already does. Since it's > a minor update, please get that into 1.9.2 so we can start testing with Java > 13. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1390) Client window handler doesn't work with frames
[ https://issues.apache.org/jira/browse/DELTASPIKE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16950283#comment-16950283 ] ASF subversion and git services commented on DELTASPIKE-1390: - Commit f9f0c6aaf997d7a8224d06290048f2e8eae5f1d7 in deltaspike's branch refs/heads/master from Thomas Andraschko [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=f9f0c6a ] Merge pull request #98 from beikov/DELTASPIKE-1390 DELTASPIKE-1390 - Test and fix for CLIENTWINDOW mode with frames > Client window handler doesn't work with frames > -- > > Key: DELTASPIKE-1390 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1390 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) > Components: JSF-Module >Reporter: Christian Beikov >Priority: Major > Fix For: 1.9.2 > > Time Spent: 40m > Remaining Estimate: 0h > > The CLIENTWINDOW handler code loses the window when frames are involved. > Using e.g. a window scoped bean with the Primefaces Dialog Framework will > result in issues. The bean is initialized in window1. A click on a button > opens a dialog, which is opened through an iframe, but the dialog doesn't use > the window id defined in the parent window. If a button in the dialog > requires the original bean, it will find an uninitialized bean, because the > frame gets a new window id window2. > The solution is to use the root window for the window id. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1391) CLIENTWINDOW JS code breaks Primefaces tabview
[
https://issues.apache.org/jira/browse/DELTASPIKE-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16950282#comment-16950282
]
ASF subversion and git services commented on DELTASPIKE-1391:
-
Commit 4a05ebf6c8b4c43b5bf1cb2505950589f9beb2de in deltaspike's branch
refs/heads/master from Christian Beikov
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=4a05ebf ]
DELTASPIKE-1391 - Never install tokenized redirect handler for any anchor links
> CLIENTWINDOW JS code breaks Primefaces tabview
> --
>
> Key: DELTASPIKE-1391
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1391
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: JSF-Module
>Reporter: Christian Beikov
>Priority: Major
> Fix For: 1.9.2
>
>
> Using a Primefaces tabview is impossible with the CLIENTWINDOW JS code as it
> will do a page redirect for links that have a href like {{#tabview:tabId}}
> which is due to the fact, that all links except ones with just {{#}} in the
> href, get a special onclick handler causing this. The intent of the handler
> is to handle opening new windows, but it should ignore any links with any
> kind of anchor navigation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1390) Client window handler doesn't work with frames
[ https://issues.apache.org/jira/browse/DELTASPIKE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16950281#comment-16950281 ] ASF subversion and git services commented on DELTASPIKE-1390: - Commit cdc155ef3042ec93bce3574eef78e9d78eaecbad in deltaspike's branch refs/heads/master from Christian Beikov [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=cdc155e ] DELTASPIKE-1390 - Fix CLIENTWINDOW mode to work with frames > Client window handler doesn't work with frames > -- > > Key: DELTASPIKE-1390 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1390 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) > Components: JSF-Module >Reporter: Christian Beikov >Priority: Major > Fix For: 1.9.2 > > Time Spent: 40m > Remaining Estimate: 0h > > The CLIENTWINDOW handler code loses the window when frames are involved. > Using e.g. a window scoped bean with the Primefaces Dialog Framework will > result in issues. The bean is initialized in window1. A click on a button > opens a dialog, which is opened through an iframe, but the dialog doesn't use > the window id defined in the parent window. If a button in the dialog > requires the original bean, it will find an uninitialized bean, because the > frame gets a new window id window2. > The solution is to use the root window for the window id. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1390) Client window handler doesn't work with frames
[ https://issues.apache.org/jira/browse/DELTASPIKE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16950284#comment-16950284 ] ASF subversion and git services commented on DELTASPIKE-1390: - Commit f9f0c6aaf997d7a8224d06290048f2e8eae5f1d7 in deltaspike's branch refs/heads/master from Thomas Andraschko [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=f9f0c6a ] Merge pull request #98 from beikov/DELTASPIKE-1390 DELTASPIKE-1390 - Test and fix for CLIENTWINDOW mode with frames > Client window handler doesn't work with frames > -- > > Key: DELTASPIKE-1390 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1390 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) > Components: JSF-Module >Reporter: Christian Beikov >Priority: Major > Fix For: 1.9.2 > > Time Spent: 40m > Remaining Estimate: 0h > > The CLIENTWINDOW handler code loses the window when frames are involved. > Using e.g. a window scoped bean with the Primefaces Dialog Framework will > result in issues. The bean is initialized in window1. A click on a button > opens a dialog, which is opened through an iframe, but the dialog doesn't use > the window id defined in the parent window. If a button in the dialog > requires the original bean, it will find an uninitialized bean, because the > frame gets a new window id window2. > The solution is to use the root window for the window id. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1390) Client window handler doesn't work with frames
[ https://issues.apache.org/jira/browse/DELTASPIKE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16950280#comment-16950280 ] ASF subversion and git services commented on DELTASPIKE-1390: - Commit 3eba0378b4ddd613749ed60a5353f73fff76b89f in deltaspike's branch refs/heads/master from Christian Beikov [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=3eba037 ] DELTASPIKE-1390 - Test that frames don't work with CLIENTWINDOW mode > Client window handler doesn't work with frames > -- > > Key: DELTASPIKE-1390 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1390 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) > Components: JSF-Module >Reporter: Christian Beikov >Priority: Major > Fix For: 1.9.2 > > Time Spent: 40m > Remaining Estimate: 0h > > The CLIENTWINDOW handler code loses the window when frames are involved. > Using e.g. a window scoped bean with the Primefaces Dialog Framework will > result in issues. The bean is initialized in window1. A click on a button > opens a dialog, which is opened through an iframe, but the dialog doesn't use > the window id defined in the parent window. If a button in the dialog > requires the original bean, it will find an uninitialized bean, because the > frame gets a new window id window2. > The solution is to use the root window for the window id. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1405) upgrade to apache-parent 23 and fix distribution
[ https://issues.apache.org/jira/browse/DELTASPIKE-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17081719#comment-17081719 ] ASF subversion and git services commented on DELTASPIKE-1405: - Commit e346e97cb8b76130fe1d6a6902c9846ecddac797 in deltaspike's branch refs/heads/master from Mark Struberg [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=e346e97 ] DELTASPIKE-1405 upgrade to apache parent 23 and fix distribution > upgrade to apache-parent 23 and fix distribution > > > Key: DELTASPIKE-1405 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1405 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Build >Affects Versions: 1.9.3 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 1.9.4 > > > Right now we use a maven-assembly-plugin which fails for the full > distribution. > We also should upgrade to the latest apache-parent. -- This message was sent by Atlassian Jira (v8.3.4#803005)
