[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715964#comment-17715964 ] Romain Manni-Bucau commented on DELTASPIKE-1434: [~vanta] EE always had been selected for its stability until they start breaking and the adoption decrease so yes they exist and try to migrate without having to do it every year cause it costs money. To answer your timeline question: it is not about the timeline since ASF does not have any strong timeline, it is likely more about the investment you can do. For example join the discussion about the pruning on the list and when there is an agreement, if you cover all mainstream servers (I guess payara, tomee, wildfly) for the IT then the release is 3 days (vote process) but has no real blocker nor challenge. If you consider the project as a consommable and don't care about the OSS side I'm tempted to say you should migrate to something more commercial like quarkus (money helps to maintain software in real life ;)). > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715794#comment-17715794 ] Romain Manni-Bucau commented on DELTASPIKE-1434: > Releases are cheap! There is no rule saying that a project can't make several > major releases in a (short) period. Not for end users when they need to change their code every year/month (maybe you are an exception), the EE and Microprofile mess prove it being very true for a lot of our user base. > And then take your time to make any improvements on top for the next major > release. Deleting will not happen *on top*, this is the main issue and why there is a discussion. > IMO it would be better to make a release that just replaces "javax" with > "jakarta" of the current/latest javax version of a lib. There is no need of a > major version here. One could use even a Maven classifier. I was for the classifier option to have an early access flavor but the breaking change in EE API limit this solution now and will not enable to run in any jakarta server so we have to do the big jump sadly and therefore the IT question which require some investment. > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715768#comment-17715768 ] Romain Manni-Bucau commented on DELTASPIKE-1434: [~mgrigorov] this can look accurate but in pactise you hide the most important points: * this is a breaking version so you have to ask yourself as a project maintainer what you want to break more to give some stability to users (if you don't it means you will do a pure conversion release then break with next major, likely worse), * javax -> jakarta is not only about renaming, EE broke itself just after the renaming (CDI API for ex) so this is not only a renaming thing to migrate, this is also why the bytecode manipulation often works but also fails regularly, * even following this rule you still hit the fact containers are not up to date or no more compatible so you still have IT work > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715725#comment-17715725 ] Romain Manni-Bucau commented on DELTASPIKE-1434: The main issue is migrating away from it means doing yourself part of it since there is no real alternative in CDI land (microprofile is insanely unstable and doesnt cover 60% of DS) so tempted to say it depends what you use. For your information there are discussions on what should be kept for v2 (jakarta) or not on the list. As usual it is easy to say to the OSS "do my job" but the idea is more "join and help" so you are both welcome to join the list and do PR to make it move faster. > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715306#comment-17715306 ] Romain Manni-Bucau commented on DELTASPIKE-1434: The harm would be to just deliver soemthing broken and imply people keep investing time in pure lost, we dont work like that. As of today arquillian is partially ready so question is the container coverage we want. I guess payara, tomee, maybe wildfly (less sure today). Feel free to help to uodate the setup Jeremy to make it move faster. > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17678135#comment-17678135 ] Romain Manni-Bucau commented on DELTASPIKE-1434: CDI 4.0 is not backward compatible with CDI 3.0 (both in jakarta namespace), it requires some codechange to ensure it can run on both but can also mean we drop CDI 1.0 support (supporting 1, 2 and 4 is way harder than 2-4). Surely something to discuss on the list. > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (DELTASPIKE-1402) ~/.deltaspike/apache-deltaspike.properties doesn't pickup changes during runtime
[
https://issues.apache.org/jira/browse/DELTASPIKE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120916#comment-17120916
]
Romain Manni-Bucau edited comment on DELTASPIKE-1402 at 6/1/20, 10:38 AM:
--
I guess we need to refine the target:
# hot reloading
# bootstrap config (what if the config is mapped to a runtime model, it can be
reloaded, it will never be refreshed)
# immutable deployments (some deployments will not want to reload cause it
means potentially breaking a valid deployment)
# performances: most servlet container have a dev mode with reloading at read
and a prod mode where it is disabled to avoid any IO which are cheap if done
alone but can be expensive if the disk is used with an IO expensive app
Therefore I suspect we can need a toggle to enable a refresh at read or a
cached mode (read once). Using an enum it can enable us to add later a
background refresh if needed so I would add something like
{code:java}
deltaspike.configsource.userhome.reloadStrategy=[SYNCHRONOUS_AT_READ|NONE|SKIP]
{code}
Side note: SKIP means "I don't want that, most apps of that machine use it but
not me"
Hope it makes sense.
was (Author: romain.manni-bucau):
I guess we need to refine the target:
# hot reloading
# bootstrap config (what if the config is mapped to a runtime model, it can be
reloaded, it will never be refreshed)
# immutable deployments (some deployments will not want to reload cause it
means potentially breaking a valid deployment)
# performances: most servlet container have a dev mode with reloading at read
and a prod mode where it is disabled to avoid any IO which are cheap if done
alone but can be expensive if the disk is used with an IO expensive app
Therefore I suspect we can need a toggle to enable a refresh at read or a
cached mode (read once). Using an enum it can enable us to add later a
background refresh if needed so I would add something like
{code:java}
deltaspike.configsource.userhome.reloadStrategy=[SYNCHRONOUS_AT_READ|NONE]
{code}
Hope it makes sense.
> ~/.deltaspike/apache-deltaspike.properties doesn't pickup changes during
> runtime
>
>
> Key: DELTASPIKE-1402
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1402
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Configuration
>Affects Versions: 1.9.3
>Reporter: Mark Struberg
>Priority: Major
> Fix For: 1.9.4
>
>
> Right now the {{ConfigSource}} registered via
> {{org.apache.deltaspike.core.impl.config.DefaultConfigSourceProvider#addUserHomeConfigSource}}
> does not reload dynamically if the file got changed.
> That means DeltaSpike Config right now doesn't automatically pick up changes
> in this file.
> The same is true for other
> {{org.apache.deltaspike.core.impl.config.PropertyFileConfigSource}} but most
> of them are in a jar anyway, so it doesn't make any difference.
> Of course for PropertyFileConfigSources representing native files on the disk
> it might also be nice to detect dynamic changes.
> It might be perfectly fine to have changes only picked up based on the
> last-changed timestamp of the file and only checked every minute or so.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1402) ~/.deltaspike/apache-deltaspike.properties doesn't pickup changes during runtime
[
https://issues.apache.org/jira/browse/DELTASPIKE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120916#comment-17120916
]
Romain Manni-Bucau commented on DELTASPIKE-1402:
I guess we need to refine the target:
# hot reloading
# bootstrap config (what if the config is mapped to a runtime model, it can be
reloaded, it will never be refreshed)
# immutable deployments (some deployments will not want to reload cause it
means potentially breaking a valid deployment)
# performances: most servlet container have a dev mode with reloading at read
and a prod mode where it is disabled to avoid any IO which are cheap if done
alone but can be expensive if the disk is used with an IO expensive app
Therefore I suspect we can need a toggle to enable a refresh at read or a
cached mode (read once). Using an enum it can enable us to add later a
background refresh if needed so I would add something like
{code:java}
deltaspike.configsource.userhome.reloadStrategy=[SYNCHRONOUS_AT_READ|NONE]
{code}
Hope it makes sense.
> ~/.deltaspike/apache-deltaspike.properties doesn't pickup changes during
> runtime
>
>
> Key: DELTASPIKE-1402
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1402
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Configuration
>Affects Versions: 1.9.3
>Reporter: Mark Struberg
>Priority: Major
> Fix For: 1.9.4
>
>
> Right now the {{ConfigSource}} registered via
> {{org.apache.deltaspike.core.impl.config.DefaultConfigSourceProvider#addUserHomeConfigSource}}
> does not reload dynamically if the file got changed.
> That means DeltaSpike Config right now doesn't automatically pick up changes
> in this file.
> The same is true for other
> {{org.apache.deltaspike.core.impl.config.PropertyFileConfigSource}} but most
> of them are in a jar anyway, so it doesn't make any difference.
> Of course for PropertyFileConfigSources representing native files on the disk
> it might also be nice to detect dynamic changes.
> It might be perfectly fine to have changes only picked up based on the
> last-changed timestamp of the file and only checked every minute or so.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1366) Add Junit5 testing support
[
https://issues.apache.org/jira/browse/DELTASPIKE-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111798#comment-17111798
]
Romain Manni-Bucau commented on DELTASPIKE-1366:
[~Sethi] you can exclude openwebbeans transitive deps and it works with weld,
just dependencies management stuff (indeed by default it brings owb ;)). I see
no issue to bring it to DS if it does not depend on any other DS module though.
> Add Junit5 testing support
> --
>
> Key: DELTASPIKE-1366
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1366
> Project: DeltaSpike
> Issue Type: Wish
> Components: TestControl, Tests
>Affects Versions: 1.9.0
>Reporter: John Smith
>Priority: Major
>
> Are there any plans to provide a junit5 extension like the CdiTestRunner in
> the test-control module for junit4?
> {{Especially the feature of the DynamicMockManager that allows you to add
> mocks on per test basis is pretty nice for testing.}}
> {{This would be highly appreciated. }}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1366) Add Junit5 testing support
[
https://issues.apache.org/jira/browse/DELTASPIKE-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111449#comment-17111449
]
Romain Manni-Bucau commented on DELTASPIKE-1366:
Hi, if it helps, openwebbeans-junit5 is just a wrapper around CDI 2 SeContainer
so portable accross CDI implementation (once the implementation dependency
selected) and is already available since some time
[http://openwebbeans.apache.org/openwebbeans-junit5.html]. Can fill the gap and
avoid the legacy CdiTestRunner relies on (thinking about BeanProvider and
CdiCtrl which were pre-CDI 2).
> Add Junit5 testing support
> --
>
> Key: DELTASPIKE-1366
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1366
> Project: DeltaSpike
> Issue Type: Wish
> Components: TestControl, Tests
>Affects Versions: 1.9.0
>Reporter: John Smith
>Priority: Major
>
> Are there any plans to provide a junit5 extension like the CdiTestRunner in
> the test-control module for junit4?
> {{Especially the feature of the DynamicMockManager that allows you to add
> mocks on per test basis is pretty nice for testing.}}
> {{This would be highly appreciated. }}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-193) Setup SecurityManager enabled CI build
[ https://issues.apache.org/jira/browse/DELTASPIKE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825085#comment-16825085 ] Romain Manni-Bucau commented on DELTASPIKE-193: --- Think it is worth doing it since apps can run under a SM so while we are a lib we must comply to that requirement IMHO. > Setup SecurityManager enabled CI build > -- > > Key: DELTASPIKE-193 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-193 > Project: DeltaSpike > Issue Type: Task > Components: Build >Affects Versions: 0.2-incubating >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > > We currently don't have any CI environment which uses a SecurityManager. We > should add such an environment to check whether DeltaSpike properly uses > doPrivileged blocks where needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1357) Update ASM to 6.2.1 for preliminary Java 12 support
[ https://issues.apache.org/jira/browse/DELTASPIKE-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16633615#comment-16633615 ] Romain Manni-Bucau commented on DELTASPIKE-1357: maybe we should go straight on asm 7-beta which got released 2 days ago? 6.2.1 does not support java 11 properly. > Update ASM to 6.2.1 for preliminary Java 12 support > --- > > 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 >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-1345) Support JavaEE Security annotation
[
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482847#comment-16482847
]
Romain Manni-Bucau commented on DELTASPIKE-1345:
[~gpetracek] hmm, why can't we use the same evaluation than in security module
but triggered by javax.security annotation? We would have an event which would
set if we are allowed or not and [~princemtl] would observe it and use the
request to evaluate it. That's what I had in mind. Providing a default impl
using the request would not be as useful as just handling the interceptor and
preprocess roles etc from a standard API automatically IMO (secural contexts
wouldn't be handled based on the cdi request).
> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Security-Module
>Reporter: Jonathan Laterreur
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER =
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) !=
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed =
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed =
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed =
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour
> appeler cette fonction « {} »", request.getUserPrincipal() != null ?
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1345) Support JavaEE Security annotation
[
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16481990#comment-16481990
]
Romain Manni-Bucau commented on DELTASPIKE-1345:
+1 to have this feature but 1. Not activated by default 2. Abstracted at the
role evaluation (not assume request is the source of truth all the time).
> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Security-Module
>Reporter: Jonathan Laterreur
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER =
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) !=
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed =
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed =
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed =
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour
> appeler cette fonction « {} »", request.getUserPrincipal() != null ?
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DELTASPIKE-1345) Support JavaEE Security annotation
[
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated DELTASPIKE-1345:
---
Priority: Minor (was: Blocker)
> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Security-Module
>Reporter: Jonathan Laterreur
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER =
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) !=
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed =
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed =
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed =
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour
> appeler cette fonction « {} »", request.getUserPrincipal() != null ?
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DELTASPIKE-1345) Support JavaEE Security annotation
[
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated DELTASPIKE-1345:
---
Priority: Blocker (was: Major)
> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Security-Module
>Reporter: Jonathan Laterreur
>Priority: Blocker
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER =
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) !=
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed =
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed =
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed =
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour
> appeler cette fonction « {} »", request.getUserPrincipal() != null ?
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1333) Support default methods in interface based configuration
[
https://issues.apache.org/jira/browse/DELTASPIKE-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415151#comment-16415151
]
Romain Manni-Bucau commented on DELTASPIKE-1333:
Hi Niels,
Do you want to do a PR on github to fix it? Technically we'd want to add a
small SPI (ServiceLoader probably) in ConfigurationExtension to load a
ConfigurationProxyProvider which instantiate a proxy from its Class. It would
be used in ProxyConfigurationLifecycle#create. By default we would keep current
implementation without default support using java proxy but if partialbean
module is present we would use the partialbean bytecode generation which can
support default methods.
Side note: no need of default methods for this use case, use a converter ;).
Romain
> Support default methods in interface based configuration
>
>
> Key: DELTASPIKE-1333
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1333
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Configuration
>Affects Versions: 1.8.1
> Environment: Java 8, DeltaSpike 1.8.1
>Reporter: Niels Ull Harremoes
>Priority: Minor
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> I wanted to implement a default method in one of my configuration methods as
> a simple way to configure a Duration:
> {code:java}
> @Configuration
> interface CacheConfig {
> @ConfigProperty(name = "cache.lifetime", defaultValue = "P1D")
> String cacheLifetime();
> default Duration getCacheLifetimeDuration() {
> try {
> return Duration.parse(cacheLifetime());
> } catch (DateTimeParseException e) {
> ...
> }
> }
> {code}
> However, a runtime I get the error
> {quote}java.lang.UnsupportedOperationException: public default
> java.time.Duration com.example.CacheConfig.getLifetimeDuration() doesn't have
> @ConfigProperty and therefore is illegal
> {quote}
> It would be nice if default methods were not processed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1311) Allow Excluded Repositories
[ https://issues.apache.org/jira/browse/DELTASPIKE-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16313201#comment-16313201 ] Romain Manni-Bucau commented on DELTASPIKE-1311: No need of veto since it will not be seen so I tend to join Gerhard here, is it only a legacy, EE 6 enhancement? If so we should fully support exclude (doable since part of the core feature) IMHO. > Allow Excluded Repositories > --- > > Key: DELTASPIKE-1311 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1311 > Project: DeltaSpike > Issue Type: Improvement > Components: Data-Module >Affects Versions: 1.8.1 >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 1.8.2 > > > When a repository is discovered, if it has @Exclude on it, then don't include > it as a possible repository bean. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (DELTASPIKE-1303) @Configuration proxies should support List without converters
[ https://issues.apache.org/jira/browse/DELTASPIKE-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved DELTASPIKE-1303. Resolution: Fixed > @Configuration proxies should support List without converters > - > > Key: DELTASPIKE-1303 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1303 > Project: DeltaSpike > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 1.8.1 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DELTASPIKE-1303) @Configuration proxies should support List without converters
Romain Manni-Bucau created DELTASPIKE-1303: -- Summary: @Configuration proxies should support List without converters Key: DELTASPIKE-1303 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1303 Project: DeltaSpike Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 1.8.1 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1296) PropertyFileConfig doesn't work with internal extensions
[ https://issues.apache.org/jira/browse/DELTASPIKE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266801#comment-16266801 ] Romain Manni-Bucau commented on DELTASPIKE-1296: If we register them at AfterBeanDiscovery phase we would be deterministic and solve the inter extension issue. Strictly speaking having a single AfterDeploymentValidation deltaspike extension and sorting ourself all the extensions using this hook would make it deterministic too and solve the original issue. In any case current implementation is not usable since it leads to a misbehavior in most cases cause using the SPI file for a PropertyFileConfig is all but recommanded in all our doc and would lead to a simple ConfigSource so is not justified. > PropertyFileConfig doesn't work with internal extensions > > > Key: DELTASPIKE-1296 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1296 > Project: DeltaSpike > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Romain Manni-Bucau >Assignee: Mark Struberg > > We register PropertyFileConfig in AfterDeploymentValidation hook but > extensions potentially already read the config entries. Technically there is > probably no blocker to do it earlier and we should probably ensure all our > extensions read keys in AfterDeploymentValidation. > My use case was a configured cron expression in the scheduler usage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (DELTASPIKE-1296) PropertyFileConfig doesn't work with internal extensions
[ https://issues.apache.org/jira/browse/DELTASPIKE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau reopened DELTASPIKE-1296: > PropertyFileConfig doesn't work with internal extensions > > > Key: DELTASPIKE-1296 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1296 > Project: DeltaSpike > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Romain Manni-Bucau >Assignee: Mark Struberg > > We register PropertyFileConfig in AfterDeploymentValidation hook but > extensions potentially already read the config entries. Technically there is > probably no blocker to do it earlier and we should probably ensure all our > extensions read keys in AfterDeploymentValidation. > My use case was a configured cron expression in the scheduler usage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1296) PropertyFileConfig doesn't work with internal extensions
[ https://issues.apache.org/jira/browse/DELTASPIKE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266630#comment-16266630 ] Romain Manni-Bucau commented on DELTASPIKE-1296: Hi Mark, issue is really to have a config module not compatible with other module usage. 1 should directly register the config and not way for any later phase to ensure it is used by other extensions IMO. I'm also fine forbidding any discovery other than SPI one since it would make it work smoothly but it is less user friendly. > PropertyFileConfig doesn't work with internal extensions > > > Key: DELTASPIKE-1296 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1296 > Project: DeltaSpike > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Romain Manni-Bucau >Assignee: Mark Struberg > > We register PropertyFileConfig in AfterDeploymentValidation hook but > extensions potentially already read the config entries. Technically there is > probably no blocker to do it earlier and we should probably ensure all our > extensions read keys in AfterDeploymentValidation. > My use case was a configured cron expression in the scheduler usage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (DELTASPIKE-1296) PropertyFileConfig doesn't work with internal extensions
[ https://issues.apache.org/jira/browse/DELTASPIKE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau reopened DELTASPIKE-1296: > PropertyFileConfig doesn't work with internal extensions > > > Key: DELTASPIKE-1296 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1296 > Project: DeltaSpike > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Romain Manni-Bucau >Assignee: Mark Struberg > > We register PropertyFileConfig in AfterDeploymentValidation hook but > extensions potentially already read the config entries. Technically there is > probably no blocker to do it earlier and we should probably ensure all our > extensions read keys in AfterDeploymentValidation. > My use case was a configured cron expression in the scheduler usage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1302) ThreadPoolManager: ExecutorService map is always empty
[ https://issues.apache.org/jira/browse/DELTASPIKE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266083#comment-16266083 ] Romain Manni-Bucau commented on DELTASPIKE-1302: pushed the proposed impl, updated the doc with the config keys. Can you give it a try and let us know if it works good enough for you please? > ThreadPoolManager: ExecutorService map is always empty > -- > > Key: DELTASPIKE-1302 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1302 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 1.8.0 >Reporter: Alonso Gonzalez >Priority: Minor > > ThreadPoolManager contains a ConcurrentHashMap that maps from a pool name to > an ExecutorService. Unfortunately the map never gets populated. It's always > empty. > I need this because I want to use a specific ExecutorService with @Futureable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1302) ThreadPoolManager: ExecutorService map is always empty
[ https://issues.apache.org/jira/browse/DELTASPIKE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266021#comment-16266021 ] Romain Manni-Bucau commented on DELTASPIKE-1302: Created a branch on our repo with this strategy - https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=shortlog;h=refs/heads/fb/DELTASPIKE-1302_ThreadPoolManager-configuration > ThreadPoolManager: ExecutorService map is always empty > -- > > Key: DELTASPIKE-1302 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1302 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 1.8.0 >Reporter: Alonso Gonzalez >Priority: Minor > > ThreadPoolManager contains a ConcurrentHashMap that maps from a pool name to > an ExecutorService. Unfortunately the map never gets populated. It's always > empty. > I need this because I want to use a specific ExecutorService with @Futureable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (DELTASPIKE-1302) ThreadPoolManager: ExecutorService map is always empty
[ https://issues.apache.org/jira/browse/DELTASPIKE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265953#comment-16265953 ] Romain Manni-Bucau edited comment on DELTASPIKE-1302 at 11/26/17 10:31 AM: --- Not sure i got it but idea is to make it working out of the box without any dpi config which always lead to a poor testing coverage or harder user integration IMHO. So we would just have a single lookup chain impl. was (Author: romain.manni-bucau): Not dure i got it but idea is to make it working out of the box without any dpi config which always lead to a poor testing coverage or harder user integration IMHO. So we would just have a single lookup chain impl. > ThreadPoolManager: ExecutorService map is always empty > -- > > Key: DELTASPIKE-1302 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1302 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 1.8.0 >Reporter: Alonso Gonzalez >Priority: Minor > > ThreadPoolManager contains a ConcurrentHashMap that maps from a pool name to > an ExecutorService. Unfortunately the map never gets populated. It's always > empty. > I need this because I want to use a specific ExecutorService with @Futureable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1302) ThreadPoolManager: ExecutorService map is always empty
[ https://issues.apache.org/jira/browse/DELTASPIKE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265953#comment-16265953 ] Romain Manni-Bucau commented on DELTASPIKE-1302: Not dure i got it but idea is to make it working out of the box without any dpi config which always lead to a poor testing coverage or harder user integration IMHO. So we would just have a single lookup chain impl. > ThreadPoolManager: ExecutorService map is always empty > -- > > Key: DELTASPIKE-1302 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1302 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 1.8.0 >Reporter: Alonso Gonzalez >Priority: Minor > > ThreadPoolManager contains a ConcurrentHashMap that maps from a pool name to > an ExecutorService. Unfortunately the map never gets populated. It's always > empty. > I need this because I want to use a specific ExecutorService with @Futureable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1302) ThreadPoolManager: ExecutorService map is always empty
[ https://issues.apache.org/jira/browse/DELTASPIKE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265862#comment-16265862 ] Romain Manni-Bucau commented on DELTASPIKE-1302: Way less than config module sincr we cache the resulting instance do it will not impact perfs. > ThreadPoolManager: ExecutorService map is always empty > -- > > Key: DELTASPIKE-1302 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1302 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 1.8.0 >Reporter: Alonso Gonzalez >Priority: Minor > > ThreadPoolManager contains a ConcurrentHashMap that maps from a pool name to > an ExecutorService. Unfortunately the map never gets populated. It's always > empty. > I need this because I want to use a specific ExecutorService with @Futureable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1302) ThreadPoolManager: ExecutorService map is always empty
[ https://issues.apache.org/jira/browse/DELTASPIKE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265791#comment-16265791 ] Romain Manni-Bucau commented on DELTASPIKE-1302: Why not: 1. if a @Named matches and is of Executor type use it 2. try to look it up in jndi (managed executor service case) 3. fallback on deltaspike config with defaults - ensuring we have 1 ES per "name" with a low size default wdyt? > ThreadPoolManager: ExecutorService map is always empty > -- > > Key: DELTASPIKE-1302 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1302 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 1.8.0 >Reporter: Alonso Gonzalez >Priority: Minor > > ThreadPoolManager contains a ConcurrentHashMap that maps from a pool name to > an ExecutorService. Unfortunately the map never gets populated. It's always > empty. > I need this because I want to use a specific ExecutorService with @Futureable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1302) ThreadPoolManager: ExecutorService map is always empty
[ https://issues.apache.org/jira/browse/DELTASPIKE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265622#comment-16265622 ] Romain Manni-Bucau commented on DELTASPIKE-1302: Not sure, configurig an ES by name is simple enough to be built in IMO and I can bet the SPI would never be used. > ThreadPoolManager: ExecutorService map is always empty > -- > > Key: DELTASPIKE-1302 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1302 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 1.8.0 >Reporter: Alonso Gonzalez >Priority: Minor > > ThreadPoolManager contains a ConcurrentHashMap that maps from a pool name to > an ExecutorService. Unfortunately the map never gets populated. It's always > empty. > I need this because I want to use a specific ExecutorService with @Futureable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1302) ThreadPoolManager: ExecutorService map is always empty
[ https://issues.apache.org/jira/browse/DELTASPIKE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265491#comment-16265491 ] Romain Manni-Bucau commented on DELTASPIKE-1302: The outcome of the discussion was that you can always use an alternative. Im tempted to use some config for that instead, want to try a pr? > ThreadPoolManager: ExecutorService map is always empty > -- > > Key: DELTASPIKE-1302 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1302 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 1.8.0 >Reporter: Alonso Gonzalez >Priority: Minor > > ThreadPoolManager contains a ConcurrentHashMap that maps from a pool name to > an ExecutorService. Unfortunately the map never gets populated. It's always > empty. > I need this because I want to use a specific ExecutorService with @Futureable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1285) DeltaSpike Dependency Injection using Vaadin-CDI and Payara Micro
[
https://issues.apache.org/jira/browse/DELTASPIKE-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239996#comment-16239996
]
Romain Manni-Bucau commented on DELTASPIKE-1285:
Hi Mario
Did you report it to Payara? Looks like a nasty big pf the container.
> DeltaSpike Dependency Injection using Vaadin-CDI and Payara Micro
> -
>
> Key: DELTASPIKE-1285
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1285
> Project: DeltaSpike
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.8.0
> Environment: payara micro 4.1.2.172
> com.vaadin:vaadin-cdi:2.0.0 (deltaspike comes with vaadin dependency)
> docker-environment (based on openjdk-jre-8)
>Reporter: Sven Redelin
> Labels: easyfix
>
> Dear all,
> I got a really strange error in my environment setup and would not say, that
> the deltaspike API has a real bug, but from my point of view the
> implementation can be improved.
> *the problem*
> I've got the given setup.
> Vaadin Application using vaadin-cdi in version 2.0.0 and vaadin usage of
> version 8.0.6.
> with vaadin-cdi I got the dependency of deltaspike-core and -impl.
> The application built into a war file will be deployed using docker based on
> openjdk-jre-8 on payara-micro.
> While deployment I got the following very huge stacktrace.
> {code}
> org.glassfish.deployment.common.DeploymentException: CDI deployment
> failure:Exception List with 5 exceptions:
> Exception 0 :
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied
> dependencies for type DeltaSpikeContextExtension with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private
> org.apache.deltaspike.core.impl.scope.viewaccess.ViewAccessContextArtifactProducer.deltaSpikeContextExtension
> at
> org.apache.deltaspike.core.impl.scope.viewaccess.ViewAccessContextArtifactProducer.deltaSpikeContextExtension(ViewAccessContextArtifactProducer.java:0)
> at
> org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:362)
> at
> org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:284)
> at
> org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:137)
> at
> org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:158)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:501)
> at
> org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:487)
> at
> org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:462)
> at
> org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:454)
> at
> org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
> at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:227)
> at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
> at
> org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:329)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:220)
> at
> org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:487)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
> at
> com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:134)
> at
>
[jira] [Updated] (DELTASPIKE-1296) PropertyFileConfig doesn't work with internal extensions
[ https://issues.apache.org/jira/browse/DELTASPIKE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated DELTASPIKE-1296: --- Affects Version/s: 1.8.0 > PropertyFileConfig doesn't work with internal extensions > > > Key: DELTASPIKE-1296 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1296 > Project: DeltaSpike > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Romain Manni-Bucau > > We register PropertyFileConfig in AfterDeploymentValidation hook but > extensions potentially already read the config entries. Technically there is > probably no blocker to do it earlier and we should probably ensure all our > extensions read keys in AfterDeploymentValidation. > My use case was a configured cron expression in the scheduler usage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DELTASPIKE-1296) PropertyFileConfig doesn't work with internal extensions
Romain Manni-Bucau created DELTASPIKE-1296: -- Summary: PropertyFileConfig doesn't work with internal extensions Key: DELTASPIKE-1296 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1296 Project: DeltaSpike Issue Type: Bug Reporter: Romain Manni-Bucau We register PropertyFileConfig in AfterDeploymentValidation hook but extensions potentially already read the config entries. Technically there is probably no blocker to do it earlier and we should probably ensure all our extensions read keys in AfterDeploymentValidation. My use case was a configured cron expression in the scheduler usage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DELTASPIKE-1288) Default values are not interpolated
Romain Manni-Bucau created DELTASPIKE-1288:
--
Summary: Default values are not interpolated
Key: DELTASPIKE-1288
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1288
Project: DeltaSpike
Issue Type: Bug
Affects Versions: 1.8.0
Reporter: Romain Manni-Bucau
using ${user.home}/foo should be interpolated even when read from defaultValue
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DELTASPIKE-1283) Placeholders not supported for defaults
[
https://issues.apache.org/jira/browse/DELTASPIKE-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated DELTASPIKE-1283:
---
Issue Type: Improvement (was: Bug)
> Placeholders not supported for defaults
> ---
>
> Key: DELTASPIKE-1283
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1283
> Project: DeltaSpike
> Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>
> It would be neat and common to be able to use placeholders for default values
> as well. Typically:
> {code}
> @ConfigProperty(name = "", defaultValue = "${user.home}/foo.txt")
> String path();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[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=16084084#comment-16084084
]
Romain Manni-Bucau commented on DELTASPIKE-1277:
Hmm, not sure why it would prevent to log changes more than today. In case of
no cache we shouldnt hit any cache IMHO.
Logging a wrong value is as bad as using a wrong value at runtime because IIRC
this log statement was "ops" intended so it would lead to a misunderstanding of
the system which is quite dangerous.
What's the blocker - technically -to bypass any cache if cache is disabled?
Directly going to the ConfigResolver (configsources) sounds doable and a good
option to me. Am I missing something?
> 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
> 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
(v6.4.14#64029)
[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=16082443#comment-16082443
]
Romain Manni-Bucau commented on DELTASPIKE-1277:
Really looks close to what I have in mind. I have however some questions after
the patch review (some unclear area):
- if not using caching do we still "cache" in the shared cache? If not we can
try to do it I think otherwise if you read twice the same key the behavior is
now different from what it is today (you can get a corrupted data)
- any reason to not move to a ConfigContext and add another Map (tried to write
it in previous comment but re-reading it was maybe not clear): I think it would
be beneficial to store all config contextual (per classloader) data in a single
structure (I called it ConfigContext but any other name is good). It would
allow to have all the data you can need in all related places and avoid to
clear cache in config source method for instance ;)
Once these small tech-y details "fixed"/"discussed" I'd like to have a small
iteration on the API. Maybe having a "ConfigCacheManager" can be beneficial
instead of polluting the ConfigResolver itself (even if it delegates, it is
purely in term of API here) and we should surely embrace more java 8 - just
providing functional interface but not having any strong adherance):
{code}
// surely added as a bean but also accessible from the ConfigContext for
extensions?
public interface ConfigCacheLManager {
void clear();
void remove(String key);
void removeIf(BiPredicate predicate); // for all cached
values, if the predicate matches then remove
}
{code}
Nice thing about the removeIf is it allows to manage easily
(startsWith/endsWith) groups of keys (startsWith("app.database.")).
Hope it makes sense
> 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
> 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
(v6.4.14#64029)
[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=16080333#comment-16080333
]
Romain Manni-Bucau commented on DELTASPIKE-1277:
Hi Alexander,
yes this map would be a good entry point. We can't use a cdi bean yet because
1. it must work in extensions themself so no bean yet, 2. there are some
workarounds for ears and some containers so even if less elegant the map is
more reliable for now. The type resolvers always being contextual you should be
able to use this map to get the "current" tracker/storage. ConfigResolver has
the role of storage today, I'm not sure it fully fit the perf requirements
since you can get a slow config source but adding a light cache with eviction
on top of it would be easy. In term of internal refactoring it would just
require to store a ConfigContext per classloader instead of just
sources/converters etc to be able to add more contextual data to it IMO. I'm
sure there are other solution but I don't see any blocker to do it.
wdyt?
> 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
> Attachments: 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
(v6.4.14#64029)
[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=16066657#comment-16066657
]
Romain Manni-Bucau commented on DELTASPIKE-1277:
Hi Alexander,
patch looks good to me (just wonder if signature should ve TypeResolver
refresh() instead of void forceRefresh() but we are really at the detail level)
Now I have to admit i like the other propose and even more if wired to a
deltaspike service (understand a CDI bean) since it would allow for instance to
have a /evict endpoint not requiring to track all resolver instances which
pollutes (today) the code for a technical concern. We already have a storage
"by application" for the sources/config so it seems not hard to have a cache
storage mapped on it. Only trick will be to have a nice key preventing conflict
between resolver (string key doesnt work right?) but nothing we can't solve.
Hope it helps a bit to move forward
Romain
> 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
> Attachments: 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
(v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1238) Make EnvironmentAwareTransactionStrategy the default
[ https://issues.apache.org/jira/browse/DELTASPIKE-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897656#comment-15897656 ] Romain Manni-Bucau commented on DELTASPIKE-1238: -1 in current form, the jta detection is super slow cause of the exception, if we integrate it smoother with other parts like JPA module which has the info then we can probably revise this but today it is not an option at runtime I fear. > Make EnvironmentAwareTransactionStrategy the default > > > Key: DELTASPIKE-1238 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1238 > Project: DeltaSpike > Issue Type: Improvement >Reporter: John D. Ament >Assignee: John D. Ament > > Make EnvironmentAwareTransactionStrategy the default transaction strategy, > since it properly looks up container managed, resource local without > requiring the user to do anything. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (DELTASPIKE-1219) Support configuration proxies
Romain Manni-Bucau created DELTASPIKE-1219:
--
Summary: Support configuration proxies
Key: DELTASPIKE-1219
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1219
Project: DeltaSpike
Issue Type: New Feature
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
Fix For: 1.8.0
Idea is to wire the deltapsike configuration to interfaces:
{code}
@Configuration(prefix = "prefix.")
public interface PrefixedConfigBean {
@ConfigProperty(name = "key")
String value();
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1206) support for CDI 2.0 feature
[ https://issues.apache.org/jira/browse/DELTASPIKE-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15521041#comment-15521041 ] Romain Manni-Bucau commented on DELTASPIKE-1206: @struberg there was no question when i spoke of jaxb :p. This is clearly the case and even if OWB and Weld don't they are not the only ones to read these files (either for CDI itself or even for other things like tools) > support for CDI 2.0 feature > --- > > Key: DELTASPIKE-1206 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1206 > Project: DeltaSpike > Issue Type: Test >Affects Versions: 1.7.1 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.7.2 > > > CDI 2.0 will add support for only picking up beans with an explicit scope > annotation. This reduced the memory footprint while also speeding up the > bootstrapping. > See https://issues.jboss.org/browse/CDI-420 > We should add this annotation to our beans.xml and verify that we still work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1206) support for CDI 2.0 feature
[ https://issues.apache.org/jira/browse/DELTASPIKE-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15520966#comment-15520966 ] Romain Manni-Bucau commented on DELTASPIKE-1206: Will be broken to servers using jaxb to read beans.xml and I can guarantee you some do it ;) > support for CDI 2.0 feature > --- > > Key: DELTASPIKE-1206 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1206 > Project: DeltaSpike > Issue Type: Bug >Affects Versions: 1.7.1 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.7.2 > > > CDI 2.0 will add support for only picking up beans with an explicit scope > annotation. This reduced the memory footprint while also speeding up the > bootstrapping. > See https://issues.jboss.org/browse/CDI-420 > We should add this annotation to our beans.xml and verify that we still work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1129) check portability of context-control
[
https://issues.apache.org/jira/browse/DELTASPIKE-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15316215#comment-15316215
]
Romain Manni-Bucau commented on DELTASPIKE-1129:
point is there is no guarantee such assumption will work. I really think
session is associated to the request - SE or not - by design so I think current
behavior is the good one.
> check portability of context-control
>
>
> Key: DELTASPIKE-1129
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1129
> Project: DeltaSpike
> Issue Type: Task
> Components: CdiControl
>Affects Versions: 1.6.0
> Environment: owb/tomee7
>Reporter: Gerhard Petracek
>Assignee: Mark Struberg
>
> ContextControl#stopContext(RequestScoped.class) also stops the
> session-context (at least in case of the current snapshot of tomee7) which
> requires the following workaround:
> {code}
> contextControl.stopContext(RequestScoped.class);
> contextControl.startContext(RequestScoped.class);
> contextControl.startContext(SessionScoped.class);
> {code}
> however, such a workaround is not portable.
> without the workaround:
> WebBeans context with scope type annotation @SessionScoped does not exist
> within current thread
> at org.junit.Assert.fail(Assert.java:93)
> at
> org.apache.deltaspike.cdise.tck.ContainerCtrlTckTest.testNewRequests(ContainerCtrlTckTest.java:321)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> see e.g.
> https://builds.apache.org/job/DeltaSpike_TomEE_7.0.0-M3/org.apache.deltaspike.cdictrl$deltaspike-cdictrl-openejb/166/testReport/junit/org.apache.deltaspike.cdise.tck/ContainerCtrlTckTest/testNewRequests/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1129) check portability of context-control
[
https://issues.apache.org/jira/browse/DELTASPIKE-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15315957#comment-15315957
]
Romain Manni-Bucau commented on DELTASPIKE-1129:
I think it should be fixed in DS anyway cause tomee 7.0.0 is out + this is a
cdictrl assumption issue and not an impl issue. Could also be a flag on the
controller itself to do it (then impl do noop when not needed)
"requestImplySession" or sthg like that.
> check portability of context-control
>
>
> Key: DELTASPIKE-1129
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1129
> Project: DeltaSpike
> Issue Type: Task
> Components: CdiControl
>Affects Versions: 1.6.0
> Environment: owb/tomee7
>Reporter: Gerhard Petracek
>Assignee: Mark Struberg
>
> ContextControl#stopContext(RequestScoped.class) also stops the
> session-context (at least in case of the current snapshot of tomee7) which
> requires the following workaround:
> {code}
> contextControl.stopContext(RequestScoped.class);
> contextControl.startContext(RequestScoped.class);
> contextControl.startContext(SessionScoped.class);
> {code}
> however, such a workaround is not portable.
> without the workaround:
> WebBeans context with scope type annotation @SessionScoped does not exist
> within current thread
> at org.junit.Assert.fail(Assert.java:93)
> at
> org.apache.deltaspike.cdise.tck.ContainerCtrlTckTest.testNewRequests(ContainerCtrlTckTest.java:321)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> see e.g.
> https://builds.apache.org/job/DeltaSpike_TomEE_7.0.0-M3/org.apache.deltaspike.cdictrl$deltaspike-cdictrl-openejb/166/testReport/junit/org.apache.deltaspike.cdise.tck/ContainerCtrlTckTest/testNewRequests/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1161) [perf] avoid Instance#Select
[ https://issues.apache.org/jira/browse/DELTASPIKE-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15312936#comment-15312936 ] Romain Manni-Bucau commented on DELTASPIKE-1161: [~tandraschko] not so sure about the context but select can be cached (the new Instance until it gets unambiguous) and @Inject can be used with @Dependent relying on Provider. It will require runtime resolution and instantiation but we can ensure we do it cleverly I guess. > [perf] avoid Instance#Select > > > Key: DELTASPIKE-1161 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1161 > Project: DeltaSpike > Issue Type: Improvement > Components: Data-Module >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko > Fix For: 1.6.2 > > > average execution time of 100.000 save calls > - Instance#select: 46119ms > - BeanProvider: 42231ms > - @Inject: 37771ms > @Inject will break dependent-scoped but there is currently not real-world > usecase > We could however introduce a config in the future -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-1138) FutureableTest not compatible with weld v1.x
[ https://issues.apache.org/jira/browse/DELTASPIKE-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved DELTASPIKE-1138. Resolution: Fixed > FutureableTest not compatible with weld v1.x > > > Key: DELTASPIKE-1138 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1138 > Project: DeltaSpike > Issue Type: Bug > Components: Tests >Affects Versions: 1.6.1 >Reporter: Gerhard Petracek >Assignee: Romain Manni-Bucau > Fix For: 1.6.2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1129) check portability of context-control
[
https://issues.apache.org/jira/browse/DELTASPIKE-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15249723#comment-15249723
]
Romain Manni-Bucau commented on DELTASPIKE-1129:
[~johndament] it affects last OWB and tomee (by inheritance) releases. Real
issue is assumptions done about session scope (= portability is fine for not
web scopes)
> check portability of context-control
>
>
> Key: DELTASPIKE-1129
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1129
> Project: DeltaSpike
> Issue Type: Task
> Components: CdiControl
>Affects Versions: 1.6.0
> Environment: owb/tomee7
>Reporter: Gerhard Petracek
>Assignee: Mark Struberg
> Fix For: 1.6.1
>
> Attachments: DELTASPIKE_1129.patch
>
>
> ContextControl#stopContext(RequestScoped.class) also stops the
> session-context (at least in case of the current snapshot of tomee7) which
> requires the following workaround:
> {code}
> contextControl.stopContext(RequestScoped.class);
> contextControl.startContext(RequestScoped.class);
> contextControl.startContext(SessionScoped.class);
> {code}
> however, such a workaround is not portable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1117) add cache(long ms) to ConfigResolver.TypedResolver
[ https://issues.apache.org/jira/browse/DELTASPIKE-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15228363#comment-15228363 ] Romain Manni-Bucau commented on DELTASPIKE-1117: [~struberg] it does since then you need evict(key) and you will likely want this caching at source level too or by key pattern next time. Having a cache SPI will allow to rely on widely used cache implementation and get it for free letting the user design its configuration/keys as he wants (= add Cache SPI in DS and not cache in a map internally if provided but use that cache, this is not doable today or if it is this feature is useless, no?). > add cache(long ms) to ConfigResolver.TypedResolver > -- > > Key: DELTASPIKE-1117 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1117 > Project: DeltaSpike > Issue Type: Bug > Components: Configuration >Affects Versions: 1.6.0 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.6.1 > > > add a method to automatically cache resolved values until for a specific time -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1117) add cache(long ms) to ConfigResolver.TypedResolver
[ https://issues.apache.org/jira/browse/DELTASPIKE-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15228329#comment-15228329 ] Romain Manni-Bucau commented on DELTASPIKE-1117: [~struberg] would it makes sense to not do it in DS but wire it to a Storage then user can use any caching impl he wants instead of redoing it in DS? The SPI would be pretty thin. > add cache(long ms) to ConfigResolver.TypedResolver > -- > > Key: DELTASPIKE-1117 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1117 > Project: DeltaSpike > Issue Type: Bug > Components: Configuration >Affects Versions: 1.6.0 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.6.1 > > > add a method to automatically cache resolved values until for a specific time -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-1099) @Locked: method access controlled by a ReadWriteLock
[ https://issues.apache.org/jira/browse/DELTASPIKE-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved DELTASPIKE-1099. Resolution: Fixed > @Locked: method access controlled by a ReadWriteLock > > > Key: DELTASPIKE-1099 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1099 > Project: DeltaSpike > Issue Type: New Feature >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 1.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DELTASPIKE-1099) @Locked: method access controlled by a ReadWriteLock
Romain Manni-Bucau created DELTASPIKE-1099: -- Summary: @Locked: method access controlled by a ReadWriteLock Key: DELTASPIKE-1099 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1099 Project: DeltaSpike Issue Type: New Feature Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 1.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DELTASPIKE-1093) add @Throttled
Romain Manni-Bucau created DELTASPIKE-1093: -- Summary: add @Throttled Key: DELTASPIKE-1093 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1093 Project: DeltaSpike Issue Type: New Feature Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 1.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1040) ClassDeactivationUtils spams the log in ProjectStages Development and UnitTest
[ https://issues.apache.org/jira/browse/DELTASPIKE-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15047081#comment-15047081 ] Romain Manni-Bucau commented on DELTASPIKE-1040: Also I wouldnt log anything at all in level > FINEST if the deactivation implementation is custom > ClassDeactivationUtils spams the log in ProjectStages Development and UnitTest > -- > > Key: DELTASPIKE-1040 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1040 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 1.5.1 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.5.3 > > > When developing a JSF application DeltaSpike now spams about 20 lines of log > on each request. This is way too much. > We can either switch back the log to debug or at least only log disabled > Extensions as info. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DELTASPIKE-1037) add support for constructor taking a single String parameter or fromString static method for @ConfigProperty
Romain Manni-Bucau created DELTASPIKE-1037: -- Summary: add support for constructor taking a single String parameter or fromString static method for @ConfigProperty Key: DELTASPIKE-1037 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1037 Project: DeltaSpike Issue Type: New Feature Affects Versions: 1.5.1 Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 1.5.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-1037) add support for constructor taking a single String parameter or fromString static method for @ConfigProperty
[ https://issues.apache.org/jira/browse/DELTASPIKE-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated DELTASPIKE-1037: --- Description: Support injection of unknown types if they take a String as parameter or have a static fromString(String) method > add support for constructor taking a single String parameter or fromString > static method for @ConfigProperty > > > Key: DELTASPIKE-1037 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1037 > Project: DeltaSpike > Issue Type: New Feature >Affects Versions: 1.5.1 >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 1.5.2 > > Attachments: DELTASPIKE-generic-config.patch > > > Support injection of unknown types if they take a String as parameter or have > a static fromString(String) method -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-1037) add support for constructor taking a single String parameter or fromString static method for @ConfigProperty
[ https://issues.apache.org/jira/browse/DELTASPIKE-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated DELTASPIKE-1037: --- Attachment: DELTASPIKE-generic-config.patch Attaching a patch with the proposal (inspired from Sabot) I wonder if we can remove all the producers we have in the default config producer class or if we consider them as part of the API/userland (the patch does this assumption) > add support for constructor taking a single String parameter or fromString > static method for @ConfigProperty > > > Key: DELTASPIKE-1037 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1037 > Project: DeltaSpike > Issue Type: New Feature >Affects Versions: 1.5.1 >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 1.5.2 > > Attachments: DELTASPIKE-generic-config.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1018) Automatic RequestScope activation for @MBean invocations
[
https://issues.apache.org/jira/browse/DELTASPIKE-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14992178#comment-14992178
]
Romain Manni-Bucau commented on DELTASPIKE-1018:
[~gpetracek] why not providing such an interceptor in DS:
{code}
@MBean // no change
@CdiContextActivator({RequestScoped.class, MyScoped.class}) // new feature
public class MyMBean {}
{code}
can be in cdictrl module
> Automatic RequestScope activation for @MBean invocations
> -
>
> Key: DELTASPIKE-1018
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1018
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.0.2
>Reporter: Falko Modler
>Priority: Minor
>
> When a {{@JmxManaged}} method is called (via jconsole for instance) on a
> CDI-Bean which has been registered as a MBean via {{@MBean}} annotation, the
> RequestScope is not active.
> It would be handy if RequestScope could be actived automatically, perhaps
> configurable via a new {{@MBean}} attribute and/or
> {{apache-deltaspike.properties}}.
> Workaround: Implement and register an Interceptor which actives/deactivates
> the scope via {{ContextControl}} around the method invocation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1018) Automatic RequestScope activation for @MBean invocations
[
https://issues.apache.org/jira/browse/DELTASPIKE-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14992410#comment-14992410
]
Romain Manni-Bucau commented on DELTASPIKE-1018:
I saw the interceptor often enough to think it can be a built in feature.
> Automatic RequestScope activation for @MBean invocations
> -
>
> Key: DELTASPIKE-1018
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1018
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.0.2
>Reporter: Falko Modler
>Priority: Minor
>
> When a {{@JmxManaged}} method is called (via jconsole for instance) on a
> CDI-Bean which has been registered as a MBean via {{@MBean}} annotation, the
> RequestScope is not active.
> It would be handy if RequestScope could be actived automatically, perhaps
> configurable via a new {{@MBean}} attribute and/or
> {{apache-deltaspike.properties}}.
> Workaround: Implement and register an Interceptor which actives/deactivates
> the scope via {{ContextControl}} around the method invocation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-1008) Introduce @MBean.type() to customize type in JMX bean objectName
[
https://issues.apache.org/jira/browse/DELTASPIKE-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau resolved DELTASPIKE-1008.
Resolution: Fixed
I see, applied
> Introduce @MBean.type() to customize type in JMX bean objectName
>
>
> Key: DELTASPIKE-1008
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1008
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.5.0
>Reporter: Falko Modler
>Assignee: Romain Manni-Bucau
>Priority: Minor
> Fix For: 1.6.0
>
> Attachments: MBean_type_configurable.patch
>
>
> The {{type}} part in a JMX bean's {{objectName}} is the only thing that is
> not yet configurable. The attached patch changes that by introducing
> {{@MBean.type()}} similar to {{@MBean.category()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1008) Introduce @MBean.type() to customize type in JMX bean objectName
[
https://issues.apache.org/jira/browse/DELTASPIKE-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971035#comment-14971035
]
Romain Manni-Bucau commented on DELTASPIKE-1008:
Ok forgot we have objectName() so seems we don't need type()
> Introduce @MBean.type() to customize type in JMX bean objectName
>
>
> Key: DELTASPIKE-1008
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1008
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.5.0
>Reporter: Falko Modler
>Assignee: Romain Manni-Bucau
>Priority: Minor
> Fix For: 1.6.0
>
> Attachments: MBean_type_configurable.patch
>
>
> The {{type}} part in a JMX bean's {{objectName}} is the only thing that is
> not yet configurable. The attached patch changes that by introducing
> {{@MBean.type()}} similar to {{@MBean.category()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (DELTASPIKE-1008) Introduce @MBean.type() to customize type in JMX bean objectName
[
https://issues.apache.org/jira/browse/DELTASPIKE-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971083#comment-14971083
]
Romain Manni-Bucau edited comment on DELTASPIKE-1008 at 10/23/15 2:51 PM:
--
I see, applied
edit: added properties() as well, it can contain type and name without having
to redefine it in the attribute of the same name and if name is set to "" with
a properties() set then it can now be ignored (type is never ignored cause
important in JMX).
was (Author: romain.manni-bucau):
I see, applied
> Introduce @MBean.type() to customize type in JMX bean objectName
>
>
> Key: DELTASPIKE-1008
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1008
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.5.0
>Reporter: Falko Modler
>Assignee: Romain Manni-Bucau
>Priority: Minor
> Fix For: 1.6.0
>
> Attachments: MBean_type_configurable.patch
>
>
> The {{type}} part in a JMX bean's {{objectName}} is the only thing that is
> not yet configurable. The attached patch changes that by introducing
> {{@MBean.type()}} similar to {{@MBean.category()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1008) Introduce @MBean.type() to customize type in JMX bean objectName
[
https://issues.apache.org/jira/browse/DELTASPIKE-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14963966#comment-14963966
]
Romain Manni-Bucau commented on DELTASPIKE-1008:
Hi Falko,
wonder if we shouldnt go for a objectName() method and deprecate category. If
Not we should support properties():
{code}
@MBean(category = "com.company.mbeans", properties = { "type=custom",
"j2eeType=myApp", "name=counter" })
{code}
(I have no big preferences between an array of string following the pattern
key=value or an array of @Property(name=xxx, value=))
wdyt?
> Introduce @MBean.type() to customize type in JMX bean objectName
>
>
> Key: DELTASPIKE-1008
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1008
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.5.0
>Reporter: Falko Modler
>Assignee: Romain Manni-Bucau
>Priority: Minor
> Fix For: 1.6.0
>
> Attachments: MBean_type_configurable.patch
>
>
> The {{type}} part in a JMX bean's {{objectName}} is the only thing that is
> not yet configurable. The attached patch changes that by introducing
> {{@MBean.type()}} similar to {{@MBean.category()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-901) org.apache.deltaspike.data.impl.builder.postprocessor.CountQueryPostProcessor doesn't respect order by
[
https://issues.apache.org/jira/browse/DELTASPIKE-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14546837#comment-14546837
]
Romain Manni-Bucau commented on DELTASPIKE-901:
---
Seems this commit fixed it
https://github.com/apache/deltaspike/commit/81f47b3260a4fffc7883d50ac2fc868001fb4bb7
Few more inputs in my case:
- was using openjpa
- order by was on primary key which was a String
If you have a test with these 2 constraints I'm happy :)
org.apache.deltaspike.data.impl.builder.postprocessor.CountQueryPostProcessor
doesn't respect order by
--
Key: DELTASPIKE-901
URL: https://issues.apache.org/jira/browse/DELTASPIKE-901
Project: DeltaSpike
Issue Type: Bug
Affects Versions: 1.3.0
Reporter: Romain Manni-Bucau
using select p from MyEntity p order by p.someString
and
{code}
@Query(named = MyEntity.findAll)
QueryResultMyEntity all(@FirstResult int start, @MaxResults int
pageSize);
{code}
I get
{code}
org.apache.openjpa.lib.jdbc.ReportingSQLException: expression not in
aggregate or GROUP BY columns: T0.PROPERTY_KEY {SELECT
COUNT(t0.property_key), t0.property_key FROM properties t0} [code=-5574,
state=42574]
{code}
the count post processor doesn't handle the order by correctly.
Wonder if we should add order by parameters in the select clause or just
ignore it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DELTASPIKE-901) org.apache.deltaspike.data.impl.builder.postprocessor.CountQueryPostProcessor doesn't respect order by
Romain Manni-Bucau created DELTASPIKE-901:
-
Summary:
org.apache.deltaspike.data.impl.builder.postprocessor.CountQueryPostProcessor
doesn't respect order by
Key: DELTASPIKE-901
URL: https://issues.apache.org/jira/browse/DELTASPIKE-901
Project: DeltaSpike
Issue Type: Bug
Affects Versions: 1.3.0
Reporter: Romain Manni-Bucau
using select p from MyEntity p order by p.someString
and
{code}
@Query(named = MyEntity.findAll)
QueryResultMyEntity all(@FirstResult int start, @MaxResults int pageSize);
{code}
I get
{code}
org.apache.openjpa.lib.jdbc.ReportingSQLException: expression not in aggregate
or GROUP BY columns: T0.PROPERTY_KEY {SELECT COUNT(t0.property_key),
t0.property_key FROM properties t0} [code=-5574, state=42574]
{code}
the count post processor doesn't handle the order by correctly.
Wonder if we should add order by parameters in the select clause or just ignore
it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-783) Use @WithAnnotations
[
https://issues.apache.org/jira/browse/DELTASPIKE-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217790#comment-14217790
]
Romain Manni-Bucau commented on DELTASPIKE-783:
---
Would mean we break the compatibility with EE 6 containers?
Use @WithAnnotations
Key: DELTASPIKE-783
URL: https://issues.apache.org/jira/browse/DELTASPIKE-783
Project: DeltaSpike
Issue Type: Improvement
Affects Versions: 1.1.0
Reporter: Jozef Hartinger
Make use of CDI's @WithAnnotations feature.
Each extension that does something like:
{code:JAVA}
X void processAnnotatedType(@Observes ProcessAnnotatedTypeX event) {
if (!event.getAnnotatedType().isAnnotationPresent(Foo.class)) {
return;
}
// ...
{code}
can be extended to:
{code:JAVA}
X void processAnnotatedType(@Observes @WithAnnotations(Foo.class)
ProcessAnnotatedTypeX event) {
if (!event.getAnnotatedType().isAnnotationPresent(Foo.class)) {
return;
}
// ...
{code}
This can yield performance boost in CDI 1.1+ environment because:
1) the observer method will be only called for annotated types that have the
annotation, not for all the types in the deployment
2) the container may not event need to load the annotated type and its class
at all if there are no observers requesting the type and the type does not
represent a bean.
In addition, this works nice in CDI 1.0 environment where the class
definition for the annotation is not be found and is ignored.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-783) Use @WithAnnotations
[
https://issues.apache.org/jira/browse/DELTASPIKE-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217824#comment-14217824
]
Romain Manni-Bucau commented on DELTASPIKE-783:
---
Well it will break some EE 6 containers since it is not built in. Then you need
to provide it (which is already a bad idea since DS is built on top of CDI so
API should really be considered provided). Then it means you provide javax.YYY
in a webapp and here troubles can start depending the container.
Use @WithAnnotations
Key: DELTASPIKE-783
URL: https://issues.apache.org/jira/browse/DELTASPIKE-783
Project: DeltaSpike
Issue Type: Improvement
Affects Versions: 1.1.0
Reporter: Jozef Hartinger
Make use of CDI's @WithAnnotations feature.
Each extension that does something like:
{code:JAVA}
X void processAnnotatedType(@Observes ProcessAnnotatedTypeX event) {
if (!event.getAnnotatedType().isAnnotationPresent(Foo.class)) {
return;
}
// ...
{code}
can be extended to:
{code:JAVA}
X void processAnnotatedType(@Observes @WithAnnotations(Foo.class)
ProcessAnnotatedTypeX event) {
if (!event.getAnnotatedType().isAnnotationPresent(Foo.class)) {
return;
}
// ...
{code}
This can yield performance boost in CDI 1.1+ environment because:
1) the observer method will be only called for annotated types that have the
annotation, not for all the types in the deployment
2) the container may not event need to load the annotated type and its class
at all if there are no observers requesting the type and the type does not
represent a bean.
In addition, this works nice in CDI 1.0 environment where the class
definition for the annotation is not be found and is ignored.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-783) Use @WithAnnotations
[
https://issues.apache.org/jira/browse/DELTASPIKE-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217880#comment-14217880
]
Romain Manni-Bucau commented on DELTASPIKE-783:
---
[~jharting] how since WithExtensions is RUNTIME so we'll get a
ClassNotFoundException in the best case and a NoClassDefFoundError in others.
Use @WithAnnotations
Key: DELTASPIKE-783
URL: https://issues.apache.org/jira/browse/DELTASPIKE-783
Project: DeltaSpike
Issue Type: Improvement
Affects Versions: 1.1.0
Reporter: Jozef Hartinger
Make use of CDI's @WithAnnotations feature.
Each extension that does something like:
{code:JAVA}
X void processAnnotatedType(@Observes ProcessAnnotatedTypeX event) {
if (!event.getAnnotatedType().isAnnotationPresent(Foo.class)) {
return;
}
// ...
{code}
can be extended to:
{code:JAVA}
X void processAnnotatedType(@Observes @WithAnnotations(Foo.class)
ProcessAnnotatedTypeX event) {
if (!event.getAnnotatedType().isAnnotationPresent(Foo.class)) {
return;
}
// ...
{code}
This can yield performance boost in CDI 1.1+ environment because:
1) the observer method will be only called for annotated types that have the
annotation, not for all the types in the deployment
2) the container may not event need to load the annotated type and its class
at all if there are no observers requesting the type and the type does not
represent a bean.
In addition, this works nice in CDI 1.0 environment where the class
definition for the annotation is not be found and is ignored.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-783) Use @WithAnnotations
[
https://issues.apache.org/jira/browse/DELTASPIKE-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217897#comment-14217897
]
Romain Manni-Bucau commented on DELTASPIKE-783:
---
[~jharting] I fear it is not portable. You are right using 100% reflection but
using bytecode scanning you can still fail if you don't want to allow it which
is most of the time what you want for user annotations (= avoid wrong
packaging). + IIRC in practise for annotations you get
java.lang.TypeNotPresentException lazily
Use @WithAnnotations
Key: DELTASPIKE-783
URL: https://issues.apache.org/jira/browse/DELTASPIKE-783
Project: DeltaSpike
Issue Type: Improvement
Affects Versions: 1.1.0
Reporter: Jozef Hartinger
Make use of CDI's @WithAnnotations feature.
Each extension that does something like:
{code:JAVA}
X void processAnnotatedType(@Observes ProcessAnnotatedTypeX event) {
if (!event.getAnnotatedType().isAnnotationPresent(Foo.class)) {
return;
}
// ...
{code}
can be extended to:
{code:JAVA}
X void processAnnotatedType(@Observes @WithAnnotations(Foo.class)
ProcessAnnotatedTypeX event) {
if (!event.getAnnotatedType().isAnnotationPresent(Foo.class)) {
return;
}
// ...
{code}
This can yield performance boost in CDI 1.1+ environment because:
1) the observer method will be only called for annotated types that have the
annotation, not for all the types in the deployment
2) the container may not event need to load the annotated type and its class
at all if there are no observers requesting the type and the type does not
represent a bean.
In addition, this works nice in CDI 1.0 environment where the class
definition for the annotation is not be found and is ignored.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-783) Use @WithAnnotations
[
https://issues.apache.org/jira/browse/DELTASPIKE-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217924#comment-14217924
]
Romain Manni-Bucau commented on DELTASPIKE-783:
---
Maybe for TypeNotPresentException but for sure a bytecode scanning tool can see
it and then is it a bug if it throws an exception? for this case yes but if
that's because you forgot to add a dependency or a class then you are happy to
have this feature.
Use @WithAnnotations
Key: DELTASPIKE-783
URL: https://issues.apache.org/jira/browse/DELTASPIKE-783
Project: DeltaSpike
Issue Type: Improvement
Affects Versions: 1.1.0
Reporter: Jozef Hartinger
Make use of CDI's @WithAnnotations feature.
Each extension that does something like:
{code:JAVA}
X void processAnnotatedType(@Observes ProcessAnnotatedTypeX event) {
if (!event.getAnnotatedType().isAnnotationPresent(Foo.class)) {
return;
}
// ...
{code}
can be extended to:
{code:JAVA}
X void processAnnotatedType(@Observes @WithAnnotations(Foo.class)
ProcessAnnotatedTypeX event) {
if (!event.getAnnotatedType().isAnnotationPresent(Foo.class)) {
return;
}
// ...
{code}
This can yield performance boost in CDI 1.1+ environment because:
1) the observer method will be only called for annotated types that have the
annotation, not for all the types in the deployment
2) the container may not event need to load the annotated type and its class
at all if there are no observers requesting the type and the type does not
represent a bean.
In addition, this works nice in CDI 1.0 environment where the class
definition for the annotation is not be found and is ignored.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-783) Use @WithAnnotations
[
https://issues.apache.org/jira/browse/DELTASPIKE-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217957#comment-14217957
]
Romain Manni-Bucau commented on DELTASPIKE-783:
---
I understood (BTW thanks for this I didn't know it :)) but we have to leave
with existing tools and libraries so I'm not very motivated to do it blindly
(ie for a minor).
On another side you create a masked dependency which can lead to later issues
without a real gain as Gerhard said.
Use @WithAnnotations
Key: DELTASPIKE-783
URL: https://issues.apache.org/jira/browse/DELTASPIKE-783
Project: DeltaSpike
Issue Type: Improvement
Affects Versions: 1.1.0
Reporter: Jozef Hartinger
Make use of CDI's @WithAnnotations feature.
Each extension that does something like:
{code:JAVA}
X void processAnnotatedType(@Observes ProcessAnnotatedTypeX event) {
if (!event.getAnnotatedType().isAnnotationPresent(Foo.class)) {
return;
}
// ...
{code}
can be extended to:
{code:JAVA}
X void processAnnotatedType(@Observes @WithAnnotations(Foo.class)
ProcessAnnotatedTypeX event) {
if (!event.getAnnotatedType().isAnnotationPresent(Foo.class)) {
return;
}
// ...
{code}
This can yield performance boost in CDI 1.1+ environment because:
1) the observer method will be only called for annotated types that have the
annotation, not for all the types in the deployment
2) the container may not event need to load the annotated type and its class
at all if there are no observers requesting the type and the type does not
represent a bean.
In addition, this works nice in CDI 1.0 environment where the class
definition for the annotation is not be found and is ignored.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-780) support more advanced cases by extending existing transaction-strategies
[ https://issues.apache.org/jira/browse/DELTASPIKE-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213892#comment-14213892 ] Romain Manni-Bucau commented on DELTASPIKE-780: --- @gerhard: exactly, I'm not convinced we need to make it going further now and think we should freeze it. Now that said you expect inheritance AFAIU where I would have throw an event to make extension easier. support more advanced cases by extending existing transaction-strategies Key: DELTASPIKE-780 URL: https://issues.apache.org/jira/browse/DELTASPIKE-780 Project: DeltaSpike Issue Type: Improvement Components: JPA-Module Affects Versions: 1.1.0 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-782) BeanManager lookup fails when BeanManager created in parent classloader and in SE mode
[ https://issues.apache.org/jira/browse/DELTASPIKE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214033#comment-14214033 ] Romain Manni-Bucau commented on DELTASPIKE-782: --- We should stop trying to make it working and just rely on weld/OWB internals which would work everytime. We know using the classloader is very fragile in several cases (it is also easy to make it green but not doing what is expected with arquillian or junit alone). wdyt? BeanManager lookup fails when BeanManager created in parent classloader and in SE mode -- Key: DELTASPIKE-782 URL: https://issues.apache.org/jira/browse/DELTASPIKE-782 Project: DeltaSpike Issue Type: Bug Components: CdiControl, Core Affects Versions: 1.1.0 Reporter: Shay matasaro Assignee: John D. Ament using embeadded tomcat and CdiServletContextListener attempting to use BeanProvider from within a Servlet fails: ov 16, 2014 8:19:10 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [YourServlet] in context with path [/] threw exception java.lang.IllegalStateException: Unable to find BeanManager. Please ensure that you configured the CDI implementation of your choice properly. at org.apache.deltaspike.core.api.provider.BeanManagerProvider.getBeanManager(BeanManagerProvider.java:201) at org.apache.deltaspike.core.api.provider.BeanProvider.getBeanManager(BeanProvider.java:475) at org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:118) at org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:101) The following code resolves fine in the same location: BeanManager beanManager = CdiContainerLoader.getCdiContainer().getBeanManager(); looks like bmi.loadTimeBm at BeanManagerProvider is not being set properly when using the servlet listener -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-782) BeanManager lookup fails when BeanManager created in parent classloader and in SE mode
[ https://issues.apache.org/jira/browse/DELTASPIKE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214055#comment-14214055 ] Romain Manni-Bucau commented on DELTASPIKE-782: --- There is no portable way to solve it. All solutions are wrong and each fix broke some previously handled cases. That s why specific but localised code is better. Using a cdictlr#getBM would be cleaner IMO for cdi 1.0 containers. BeanManager lookup fails when BeanManager created in parent classloader and in SE mode -- Key: DELTASPIKE-782 URL: https://issues.apache.org/jira/browse/DELTASPIKE-782 Project: DeltaSpike Issue Type: Bug Components: CdiControl, Core Affects Versions: 1.1.0 Reporter: Shay matasaro Assignee: John D. Ament using embeadded tomcat and CdiServletContextListener attempting to use BeanProvider from within a Servlet fails: ov 16, 2014 8:19:10 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [YourServlet] in context with path [/] threw exception java.lang.IllegalStateException: Unable to find BeanManager. Please ensure that you configured the CDI implementation of your choice properly. at org.apache.deltaspike.core.api.provider.BeanManagerProvider.getBeanManager(BeanManagerProvider.java:201) at org.apache.deltaspike.core.api.provider.BeanProvider.getBeanManager(BeanProvider.java:475) at org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:118) at org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:101) The following code resolves fine in the same location: BeanManager beanManager = CdiContainerLoader.getCdiContainer().getBeanManager(); looks like bmi.loadTimeBm at BeanManagerProvider is not being set properly when using the servlet listener -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-782) BeanManager lookup fails when BeanManager created in parent classloader and in SE mode
[ https://issues.apache.org/jira/browse/DELTASPIKE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214064#comment-14214064 ] Romain Manni-Bucau commented on DELTASPIKE-782: --- Last time I looked app loader bm was random in several embedded cas or worse: you get one when there is no app using apploader. CDI and classloaders have no link by spec so we cant assule anything on it. Works often cause it makes sense but on our side that is by luck. Also Im pretty we can break it with scripting language usages where another loader is used. BeanManager lookup fails when BeanManager created in parent classloader and in SE mode -- Key: DELTASPIKE-782 URL: https://issues.apache.org/jira/browse/DELTASPIKE-782 Project: DeltaSpike Issue Type: Bug Components: CdiControl, Core Affects Versions: 1.1.0 Reporter: Shay matasaro Assignee: John D. Ament using embeadded tomcat and CdiServletContextListener attempting to use BeanProvider from within a Servlet fails: ov 16, 2014 8:19:10 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [YourServlet] in context with path [/] threw exception java.lang.IllegalStateException: Unable to find BeanManager. Please ensure that you configured the CDI implementation of your choice properly. at org.apache.deltaspike.core.api.provider.BeanManagerProvider.getBeanManager(BeanManagerProvider.java:201) at org.apache.deltaspike.core.api.provider.BeanProvider.getBeanManager(BeanProvider.java:475) at org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:118) at org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:101) The following code resolves fine in the same location: BeanManager beanManager = CdiContainerLoader.getCdiContainer().getBeanManager(); looks like bmi.loadTimeBm at BeanManagerProvider is not being set properly when using the servlet listener -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-782) BeanManager lookup fails when BeanManager created in parent classloader and in SE mode
[ https://issues.apache.org/jira/browse/DELTASPIKE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214074#comment-14214074 ] Romain Manni-Bucau commented on DELTASPIKE-782: --- Well yes and no. Other libs using classloaders use other lookuo ways AFAIK. DS doesnt have a spi + the fact redeploys leak is just blocking for prod for me...allowing servers or users to override it would be great and a quick win. BeanManager lookup fails when BeanManager created in parent classloader and in SE mode -- Key: DELTASPIKE-782 URL: https://issues.apache.org/jira/browse/DELTASPIKE-782 Project: DeltaSpike Issue Type: Bug Components: CdiControl, Core Affects Versions: 1.1.0 Reporter: Shay matasaro Assignee: John D. Ament using embeadded tomcat and CdiServletContextListener attempting to use BeanProvider from within a Servlet fails: ov 16, 2014 8:19:10 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [YourServlet] in context with path [/] threw exception java.lang.IllegalStateException: Unable to find BeanManager. Please ensure that you configured the CDI implementation of your choice properly. at org.apache.deltaspike.core.api.provider.BeanManagerProvider.getBeanManager(BeanManagerProvider.java:201) at org.apache.deltaspike.core.api.provider.BeanProvider.getBeanManager(BeanProvider.java:475) at org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:118) at org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:101) The following code resolves fine in the same location: BeanManager beanManager = CdiContainerLoader.getCdiContainer().getBeanManager(); looks like bmi.loadTimeBm at BeanManagerProvider is not being set properly when using the servlet listener -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-782) BeanManager lookup fails when BeanManager created in parent classloader and in SE mode
[ https://issues.apache.org/jira/browse/DELTASPIKE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214082#comment-14214082 ] Romain Manni-Bucau commented on DELTASPIKE-782: --- Yes if we dont use a classloader as key it should work. Best way would surely be to associate to the extension all registered classloaders -as attribute- and remove them instead of relying on tccl in BeforeShutdown no? BeanManager lookup fails when BeanManager created in parent classloader and in SE mode -- Key: DELTASPIKE-782 URL: https://issues.apache.org/jira/browse/DELTASPIKE-782 Project: DeltaSpike Issue Type: Bug Components: CdiControl, Core Affects Versions: 1.1.0 Reporter: Shay matasaro Assignee: John D. Ament using embeadded tomcat and CdiServletContextListener attempting to use BeanProvider from within a Servlet fails: ov 16, 2014 8:19:10 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [YourServlet] in context with path [/] threw exception java.lang.IllegalStateException: Unable to find BeanManager. Please ensure that you configured the CDI implementation of your choice properly. at org.apache.deltaspike.core.api.provider.BeanManagerProvider.getBeanManager(BeanManagerProvider.java:201) at org.apache.deltaspike.core.api.provider.BeanProvider.getBeanManager(BeanProvider.java:475) at org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:118) at org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:101) The following code resolves fine in the same location: BeanManager beanManager = CdiContainerLoader.getCdiContainer().getBeanManager(); looks like bmi.loadTimeBm at BeanManagerProvider is not being set properly when using the servlet listener -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-780) support more advanced cases by extending existing transaction-strategies
[ https://issues.apache.org/jira/browse/DELTASPIKE-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213737#comment-14213737 ] Romain Manni-Bucau commented on DELTASPIKE-780: --- @Transactional being standard now do we need it? support more advanced cases by extending existing transaction-strategies Key: DELTASPIKE-780 URL: https://issues.apache.org/jira/browse/DELTASPIKE-780 Project: DeltaSpike Issue Type: Improvement Components: JPA-Module Affects Versions: 1.1.0 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-780) support more advanced cases by extending existing transaction-strategies
[ https://issues.apache.org/jira/browse/DELTASPIKE-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213753#comment-14213753 ] Romain Manni-Bucau commented on DELTASPIKE-780: --- Well for you. For me it always has been very limited compared to ee (jta). What I meant was however different: since there is a standard api we can just use it for advanced cases support more advanced cases by extending existing transaction-strategies Key: DELTASPIKE-780 URL: https://issues.apache.org/jira/browse/DELTASPIKE-780 Project: DeltaSpike Issue Type: Improvement Components: JPA-Module Affects Versions: 1.1.0 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-736) MockAwareInjectionTargetWrapper breaks interceptors in unit tests
[ https://issues.apache.org/jira/browse/DELTASPIKE-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14159070#comment-14159070 ] Romain Manni-Bucau commented on DELTASPIKE-736: --- [~struberg] I fixed it yesterday on OWB 1.5 BTW I agree the wrapper should be added *only* when needed and not everywhere (can use apache-deltaspike.properties or a MockMatcher configurable in apache-deltaspike.properties). This would also make the skip warnings disappear which is quite nice on big apps where these logs are just too long to keep logs useful. wdyt? MockAwareInjectionTargetWrapper breaks interceptors in unit tests - Key: DELTASPIKE-736 URL: https://issues.apache.org/jira/browse/DELTASPIKE-736 Project: DeltaSpike Issue Type: Bug Components: TestControl Affects Versions: 1.0.3 Environment: OpenWebBeans 1.2.6 Reporter: Ronald Steininger The automatic usage of MockAwareInjectionTargetWrapper breaks method-level interceptors under OWB: org.apache.webbeans.config.BeansDeployer#validate creates the interceptor stack of all beans while validating the deployment (Line 474). This code depends on owbBean.getProducer() returning an AbstractProducer (Line 462). TestControl replaces that AbstractProducer in some circumstances with an instance of MockAwareInjectionTargetWrapper, completely deactivating the if-branch which would active the interceptors. It seems that, depending where the interceptor binding is defined on the intercepted bean, interceptors work or don't work: using the annotation on the class level results in getProducer returning a AbstractProducer - interceptors work. Defining interceptors only on methods shows the broken behaviour described here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-736) MockAwareInjectionTargetWrapper breaks interceptors in unit tests
[ https://issues.apache.org/jira/browse/DELTASPIKE-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14159106#comment-14159106 ] Romain Manni-Bucau commented on DELTASPIKE-736: --- well issue for me isnot isStereotypeWithInterceptor/isInterceptedBean. Contract should just be shouldMock(...). No more. The check should be done internally and shouldn't be in the contract finally a bean can be intercepted and mocked. MockAwareInjectionTargetWrapper breaks interceptors in unit tests - Key: DELTASPIKE-736 URL: https://issues.apache.org/jira/browse/DELTASPIKE-736 Project: DeltaSpike Issue Type: Bug Components: TestControl Affects Versions: 1.0.3 Environment: OpenWebBeans 1.2.6 Reporter: Ronald Steininger The automatic usage of MockAwareInjectionTargetWrapper breaks method-level interceptors under OWB: org.apache.webbeans.config.BeansDeployer#validate creates the interceptor stack of all beans while validating the deployment (Line 474). This code depends on owbBean.getProducer() returning an AbstractProducer (Line 462). TestControl replaces that AbstractProducer in some circumstances with an instance of MockAwareInjectionTargetWrapper, completely deactivating the if-branch which would active the interceptors. It seems that, depending where the interceptor binding is defined on the intercepted bean, interceptors work or don't work: using the annotation on the class level results in getProducer returning a AbstractProducer - interceptors work. Defining interceptors only on methods shows the broken behaviour described here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-736) MockAwareInjectionTargetWrapper breaks interceptors in unit tests
[ https://issues.apache.org/jira/browse/DELTASPIKE-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14159124#comment-14159124 ] Romain Manni-Bucau commented on DELTASPIKE-736: --- [~gpetracek] I agree it is black vs white list but since it is something which breaks easily containers and which can't work on most of old ones I'm for white list. Then the log should be rework to not pollute as much as today. Finally last point is it is better to ensure you know you mock something and activate it in this case cause by default you suppose you mock all beans (and mocking is not testing most of the time so it shouldn't be a default). MockAwareInjectionTargetWrapper breaks interceptors in unit tests - Key: DELTASPIKE-736 URL: https://issues.apache.org/jira/browse/DELTASPIKE-736 Project: DeltaSpike Issue Type: Bug Components: TestControl Affects Versions: 1.0.3 Environment: OpenWebBeans 1.2.6 Reporter: Ronald Steininger Attachments: ds-736-demo.tgz The automatic usage of MockAwareInjectionTargetWrapper breaks method-level interceptors under OWB: org.apache.webbeans.config.BeansDeployer#validate creates the interceptor stack of all beans while validating the deployment (Line 474). This code depends on owbBean.getProducer() returning an AbstractProducer (Line 462). TestControl replaces that AbstractProducer in some circumstances with an instance of MockAwareInjectionTargetWrapper, completely deactivating the if-branch which would active the interceptors. It seems that, depending where the interceptor binding is defined on the intercepted bean, interceptors work or don't work: using the annotation on the class level results in getProducer returning a AbstractProducer - interceptors work. Defining interceptors only on methods shows the broken behaviour described here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-707) AbstractMockManager does not support interfaces mocked by mockito
[
https://issues.apache.org/jira/browse/DELTASPIKE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14118602#comment-14118602
]
Romain Manni-Bucau commented on DELTASPIKE-707:
---
CDI mocking with mockito can be done just vetoing what you mock so it should be
supported. Here a test using mockito as CDI bean:
http://svn.apache.org/repos/asf/tomee/tomee/trunk/arquillian/arquillian-openejb-embedded-4/src/test/java/org/apache/openejb/arquillian/openejb/ArquillianAndMockitoTest.java
do you want to provide a patch to support it?
AbstractMockManager does not support interfaces mocked by mockito
-
Key: DELTASPIKE-707
URL: https://issues.apache.org/jira/browse/DELTASPIKE-707
Project: DeltaSpike
Issue Type: Bug
Components: TestControl
Affects Versions: 1.0.2
Environment: Mockito 1.9.5
JDK 1.7u51
Reporter: Falko Modler
Following the
[manual|https://deltaspike.apache.org/test-control.html#mock-frameworks], I
tried to mock {{EntitityManager}} in my test class:
{noformat}
@RunWith(CdiTestRunner.class)
public class SomeTest {
@Inject
private DynamicMockManager mockManager;
@Test
public void mockitoMockAsCdiBean() {
mockManager.addMock(Mockito.mock(EntityManager.class));
[...]
}
}
{noformat}
Unfortunately this doesn't work as {{AbstractMockManager}} fails with:
{noformat}
java.lang.IllegalArgumentException:
$javax.persistence.EntityManager$$EnhancerByMockitoWithCGLIB$$b065dd9c isn't
a supported approach for mocking - please extend from the original class.
at
org.apache.deltaspike.testcontrol.impl.mock.AbstractMockManager.addMock(AbstractMockManager.java:45)
{noformat}
Following (rather ugly) workaound fixes the problem:
{noformat}
@Typed(EntityManager.class)
public static abstract class EntityManagerMockBase implements
EntityManager {
}
{noformat}
{noformat}
mockManager.addMock(Mockito.mock(EntityManagerMockBase.class));
{noformat}
If this problem cannot be solved then the documentation should at least
mention that mocking does not work for interfaces and how to work around that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-647) AppScoped abstract repositories doesn't work
[ https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100363#comment-14100363 ] Romain Manni-Bucau commented on DELTASPIKE-647: --- we should enhance and use commons-proxy imho since we own the code and don't need any license check AppScoped abstract repositories doesn't work Key: DELTASPIKE-647 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647 Project: DeltaSpike Issue Type: Bug Components: Data-Module Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: 0001-Failing-PartialBeans-test.patch, DELTASPIKE-647.patch, DS-647.7z -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-647) AppScoped abstract repositories doesn't work
[ https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101007#comment-14101007 ] Romain Manni-Bucau commented on DELTASPIKE-647: --- @Gerhard: do we shade javassist today? I'm -1 to shade it since we'll depend on [proxy] API but not the impl (asm, javassist, cglib...). This will be up to the user (and one advantage is to not import 10 proxying libs!). asm code is pretty much the same as OWB one (actually the same as openejb). -1000 to reimplement it again in DS which is not the place to get proxies (once again [proxy] is the place - if it is not enough for DS need we can enhance it pretty quickly) AppScoped abstract repositories doesn't work Key: DELTASPIKE-647 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647 Project: DeltaSpike Issue Type: Bug Components: Data-Module Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: 0001-Failing-PartialBeans-test.patch, DELTASPIKE-647.patch, DS-647.7z -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-647) AppScoped abstract repositories doesn't work
[ https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101084#comment-14101084 ] Romain Manni-Bucau commented on DELTASPIKE-647: --- cause that's not the only solution (cglib should work) and cause this feature is blur enough to work in most cases and be enough for some part of users. AppScoped abstract repositories doesn't work Key: DELTASPIKE-647 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647 Project: DeltaSpike Issue Type: Bug Components: Data-Module Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: 0001-Failing-PartialBeans-test.patch, DELTASPIKE-647.patch, DS-647.7z -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-591) Add a ProjectStage aware resource Servlet
[ https://issues.apache.org/jira/browse/DELTASPIKE-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13997565#comment-13997565 ] Romain Manni-Bucau commented on DELTASPIKE-591: --- Yep + we can surely activate it by default with a ServletContainerInitializer (deactivable with an init param in the context) since it will be chrooted in a subcontext. Add a ProjectStage aware resource Servlet - Key: DELTASPIKE-591 URL: https://issues.apache.org/jira/browse/DELTASPIKE-591 Project: DeltaSpike Issue Type: New Feature Components: Servlet-Module Reporter: Daniel Sachse Assignee: Christian Kaltepoth Attachments: DELTASPIKE-591.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-591) Add a ProjectStage aware resource Servlet
[ https://issues.apache.org/jira/browse/DELTASPIKE-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13996302#comment-13996302 ] Romain Manni-Bucau commented on DELTASPIKE-591: --- Hi I'd go for a servlet and not a filter to be able to intercept it easily. I'd get the project stage in init() and not by request to be more deterministic regarding the whole app (we can think to allow overriding by url but then project stage wouldn't make much sense) Add a ProjectStage aware resource Servlet - Key: DELTASPIKE-591 URL: https://issues.apache.org/jira/browse/DELTASPIKE-591 Project: DeltaSpike Issue Type: New Feature Components: Servlet-Module Reporter: Daniel Sachse Assignee: Christian Kaltepoth Attachments: DELTASPIKE-591.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-404) BeanManagerProvider leaks in case of undeploy/redeploy
[ https://issues.apache.org/jira/browse/DELTASPIKE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975625#comment-13975625 ] Romain Manni-Bucau commented on DELTASPIKE-404: --- the issue is it is broken by default then excepted if we detect the container automatically BeanManagerProvider leaks in case of undeploy/redeploy -- Key: DELTASPIKE-404 URL: https://issues.apache.org/jira/browse/DELTASPIKE-404 Project: DeltaSpike Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Gerhard Petracek Attachments: patch.diff -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (DELTASPIKE-404) BeanManagerProvider leaks in case of undeploy/redeploy
[ https://issues.apache.org/jira/browse/DELTASPIKE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975625#comment-13975625 ] Romain Manni-Bucau edited comment on DELTASPIKE-404 at 4/21/14 3:19 PM: the issue is it is broken by default then excepted if we detect the container automatically edit: not sure about others but tomee doesn't need a particular spi, it has its own event for that was (Author: romain.manni-bucau): the issue is it is broken by default then excepted if we detect the container automatically BeanManagerProvider leaks in case of undeploy/redeploy -- Key: DELTASPIKE-404 URL: https://issues.apache.org/jira/browse/DELTASPIKE-404 Project: DeltaSpike Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Gerhard Petracek Attachments: patch.diff -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-577) Test-control: Add delegation of container boot
[
https://issues.apache.org/jira/browse/DELTASPIKE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975073#comment-13975073
]
Romain Manni-Bucau commented on DELTASPIKE-577:
---
${openejb.home}/conf. Depend surefire config but by default:
${project.basedir}/conf
Note: when ignored you have in logs:
{code}
Cannot find the configuration file [conf/openejb.xml]. Will attempt to create
one for the beans deployed.
{code}
and home is logged too:
{code}
INFO - openejb.home = /xxx/yyy
{code}
Test-control: Add delegation of container boot
--
Key: DELTASPIKE-577
URL: https://issues.apache.org/jira/browse/DELTASPIKE-577
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl, TestControl
Affects Versions: 0.7
Reporter: Karl Kildén
Priority: Minor
container.boot(); is used by Test-Control.
This is nice for simple tests with cdictrl-openejb but I think it would be
nice to have the possibility to target the boot(Map?, ? properties) that is
available for the openejb container. I want Test-Control to delegate to me so
I can boot myself.
I am thinking something like:
@TestControl(bootDelegate = PropertyAwareEjbBootDelegate.class)
public interface BootDelegate {
public void boot(CdiContainer cdiContainer);
}
That way tests could be way more dynamic and end users could boot the
container in any way they want.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (DELTASPIKE-577) Test-control: Add delegation of container boot
[
https://issues.apache.org/jira/browse/DELTASPIKE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975073#comment-13975073
]
Romain Manni-Bucau edited comment on DELTASPIKE-577 at 4/20/14 7:38 AM:
{code}
${openejb.home}/conf
{code}
Depend surefire config but by default:
{code}
${project.basedir}/conf
{code}
Note: when ignored you have in logs:
{code}
Cannot find the configuration file [conf/openejb.xml]. Will attempt to create
one for the beans deployed.
{code}
and home is logged too:
{code}
INFO - openejb.home = /xxx/yyy
{code}
was (Author: romain.manni-bucau):
${openejb.home}/conf. Depend surefire config but by default:
${project.basedir}/conf
Note: when ignored you have in logs:
{code}
Cannot find the configuration file [conf/openejb.xml]. Will attempt to create
one for the beans deployed.
{code}
and home is logged too:
{code}
INFO - openejb.home = /xxx/yyy
{code}
Test-control: Add delegation of container boot
--
Key: DELTASPIKE-577
URL: https://issues.apache.org/jira/browse/DELTASPIKE-577
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl, TestControl
Affects Versions: 0.7
Reporter: Karl Kildén
Priority: Minor
container.boot(); is used by Test-Control.
This is nice for simple tests with cdictrl-openejb but I think it would be
nice to have the possibility to target the boot(Map?, ? properties) that is
available for the openejb container. I want Test-Control to delegate to me so
I can boot myself.
I am thinking something like:
@TestControl(bootDelegate = PropertyAwareEjbBootDelegate.class)
public interface BootDelegate {
public void boot(CdiContainer cdiContainer);
}
That way tests could be way more dynamic and end users could boot the
container in any way they want.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DELTASPIKE-577) Test-control: Add delegation of container boot
[
https://issues.apache.org/jira/browse/DELTASPIKE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975106#comment-13975106
]
Romain Manni-Bucau commented on DELTASPIKE-577:
---
wherever it is, it should be before the container is started
Test-control: Add delegation of container boot
--
Key: DELTASPIKE-577
URL: https://issues.apache.org/jira/browse/DELTASPIKE-577
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl, TestControl
Affects Versions: 0.7
Reporter: Karl Kildén
Priority: Minor
container.boot(); is used by Test-Control.
This is nice for simple tests with cdictrl-openejb but I think it would be
nice to have the possibility to target the boot(Map?, ? properties) that is
available for the openejb container. I want Test-Control to delegate to me so
I can boot myself.
I am thinking something like:
@TestControl(bootDelegate = PropertyAwareEjbBootDelegate.class)
public interface BootDelegate {
public void boot(CdiContainer cdiContainer);
}
That way tests could be way more dynamic and end users could boot the
container in any way they want.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DELTASPIKE-580) @InvocationMonitored
[ https://issues.apache.org/jira/browse/DELTASPIKE-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975171#comment-13975171 ] Romain Manni-Bucau commented on DELTASPIKE-580: --- Just for memories we can investigate later the integration ith sirona which has dynamic interception and advanced monitoring. Event feature is interesting btw. @InvocationMonitored Key: DELTASPIKE-580 URL: https://issues.apache.org/jira/browse/DELTASPIKE-580 Project: DeltaSpike Issue Type: New Feature Components: Core Reporter: Gerhard Petracek use-cases to support: - exception monitoring - performance monitoring (via execution time) - auditing (with or without parameter values) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-577) Test-control: Add delegation of container boot
[
https://issues.apache.org/jira/browse/DELTASPIKE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974794#comment-13974794
]
Romain Manni-Bucau commented on DELTASPIKE-577:
---
No
-Dopenejb.configuration=/path/to/openejb.xml would work or just create a conf/
folder with openejb.xml inside.
You can also use system properties to declare resources
Test-control: Add delegation of container boot
--
Key: DELTASPIKE-577
URL: https://issues.apache.org/jira/browse/DELTASPIKE-577
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl, TestControl
Affects Versions: 0.7
Reporter: Karl Kildén
Priority: Minor
container.boot(); is used by Test-Control.
This is nice for simple tests with cdictrl-openejb but I think it would be
nice to have the possibility to target the boot(Map?, ? properties) that is
available for the openejb container. I want Test-Control to delegate to me so
I can boot myself.
I am thinking something like:
@TestControl(bootDelegate = PropertyAwareEjbBootDelegate.class)
public interface BootDelegate {
public void boot(CdiContainer cdiContainer);
}
That way tests could be way more dynamic and end users could boot the
container in any way they want.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DELTASPIKE-577) Test-control: Add delegation of container boot
[
https://issues.apache.org/jira/browse/DELTASPIKE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974833#comment-13974833
]
Romain Manni-Bucau commented on DELTASPIKE-577:
---
@Gerhard:
#1 owb should have (owb.properties)
#2 agree
#3 doesn't change the fact you *need* to start/stop by class otherwise you are
broken if you dont use it for all tests which is pretty sure today
#4 ok
The point for me is either we integrate it with boot(Map) or we drop boot(Map)
from the API but we need to stay consistent everywhere IMHO.
Test-control: Add delegation of container boot
--
Key: DELTASPIKE-577
URL: https://issues.apache.org/jira/browse/DELTASPIKE-577
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl, TestControl
Affects Versions: 0.7
Reporter: Karl Kildén
Priority: Minor
container.boot(); is used by Test-Control.
This is nice for simple tests with cdictrl-openejb but I think it would be
nice to have the possibility to target the boot(Map?, ? properties) that is
available for the openejb container. I want Test-Control to delegate to me so
I can boot myself.
I am thinking something like:
@TestControl(bootDelegate = PropertyAwareEjbBootDelegate.class)
public interface BootDelegate {
public void boot(CdiContainer cdiContainer);
}
That way tests could be way more dynamic and end users could boot the
container in any way they want.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (DELTASPIKE-577) Test-control: Add delegation of container boot
[
https://issues.apache.org/jira/browse/DELTASPIKE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau reassigned DELTASPIKE-577:
-
Assignee: Romain Manni-Bucau
Test-control: Add delegation of container boot
--
Key: DELTASPIKE-577
URL: https://issues.apache.org/jira/browse/DELTASPIKE-577
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl, TestControl
Affects Versions: 0.7
Reporter: Karl Kildén
Assignee: Romain Manni-Bucau
Priority: Minor
container.boot(); is used by Test-Control.
This is nice for simple tests with cdictrl-openejb but I think it would be
nice to have the possibility to target the boot(Map?, ? properties) that is
available for the openejb container. I want Test-Control to delegate to me so
I can boot myself.
I am thinking something like:
@TestControl(bootDelegate = PropertyAwareEjbBootDelegate.class)
public interface BootDelegate {
public void boot(CdiContainer cdiContainer);
}
That way tests could be way more dynamic and end users could boot the
container in any way they want.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DELTASPIKE-577) Test-control: Add delegation of container boot
[
https://issues.apache.org/jira/browse/DELTASPIKE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974852#comment-13974852
]
Romain Manni-Bucau commented on DELTASPIKE-577:
---
well it is portable but values are not.
I'm +1 to remove it btw if we don't integrate it with cdi runner. Just make it
highly inconsistent for me.
For me cdi runner should just be a CdiRule to help to handle scopes. Boot is
generally
Test-control: Add delegation of container boot
--
Key: DELTASPIKE-577
URL: https://issues.apache.org/jira/browse/DELTASPIKE-577
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl, TestControl
Affects Versions: 0.7
Reporter: Karl Kildén
Priority: Minor
container.boot(); is used by Test-Control.
This is nice for simple tests with cdictrl-openejb but I think it would be
nice to have the possibility to target the boot(Map?, ? properties) that is
available for the openejb container. I want Test-Control to delegate to me so
I can boot myself.
I am thinking something like:
@TestControl(bootDelegate = PropertyAwareEjbBootDelegate.class)
public interface BootDelegate {
public void boot(CdiContainer cdiContainer);
}
That way tests could be way more dynamic and end users could boot the
container in any way they want.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
