[jira] [Commented] (DELTASPIKE-1282) DeltaSpikeFacesContextWrapper leaks on TomEE

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on DELTASPIKE-1282:
-

Commit 77fa4b8653c525d631e462d148c3af5b368f8361 in deltaspike's branch 
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=77fa4b8 ]

DELTASPIKE-1282 support variables 4 String default


> DeltaSpikeFacesContextWrapper leaks on TomEE
> 
>
> Key: DELTASPIKE-1282
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1282
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JSF-Module
>Affects Versions: 1.8.0
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
> 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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on DELTASPIKE-1296:
-

Commit f0d56be8f4867908c39c1937fdf25fa8d8524c07 in deltaspike's branch 
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=f0d56be ]

DELTASPIKE-1296 move ConfigSource registration

we now register PropertyFileConfig ConfigSources
already in AfterBeanDiscovery and not in AfterDeploymentValidation.
As requested by Romain


> 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-1278) PropertyFileConfig does not respect optional on external resources

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on DELTASPIKE-1278:
-

Commit 717771b275f406ce7ce43cd528be44d6053b7d2b in deltaspike's branch 
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=717771b ]

DELTASPIKE-1278 avoid signature change

previously we did not throw the URISyntaxException which
is a checked Exception. So this change did require to catch
that exception in user code.
Now handling this issue internally.


> PropertyFileConfig does not respect optional on external resources
> --
>
> Key: DELTASPIKE-1278
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1278
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.8.0
>Reporter: Dennis Rippinger
>Assignee: John D. Ament
> Fix For: 1.8.1
>
>
> Adding a property file from an external location (e.g. local file system) 
> marked as optional is not respected by {{PropertyFileUtils}}. It creates a 
> list of possible resource URLs, but does not check for their existence in all 
> branches of its logic. This results in a list of possible nonexistent 
> resources which could be optional, leading to an IllegalStateException.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: propertyfileconfig and lifecycle

[Romain Manni-Bucau]

works for me, thks Mark

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn


2017-11-27 15:51 GMT+01:00 Mark Struberg :
> We can move it from AfterDeploymentValidation to AfterBeanDiscovery.
> My argument was about why we _not_ do it immediately in ProcessAnnotatedType.
>
> Will go ahead.
>
> LieGrue,
> strub
>
>> Am 27.11.2017 um 14:32 schrieb Romain Manni-Bucau :
>>
>> Hi guys,
>>
>> I would like to discuss DELTASPIKE-1296 (and avoid jira noise ;))
>>
>> Issue is AfterDeploymentValidation order of extensions is not
>> deterministic and therefore we can end up in cases where our
>> extensions are not usable in between them cause of that. it is
>> typically the case for the config extension which is used by all other
>> ones.
>>
>> To solve it - keeping the deterministic behavior we have - we can:
>>
>> 1. register earlier the PropertyFileConfig (AfterBeanDiscovery?)
>> 2. have a single AfterDeploymentValidation observer in all our
>> codebase and be able to sort extensions here (@Priority or a custom
>> @Order). Note we can apply it to [Before|After]BeanDiscovery too.
>> 3. surely others
>>
>> Goal is to ensure the mainstream programming model we have works in
>> most cases and there is no arbitrary reason to not have it working.
>>
>> wdyt? Personally I'm tempted to say 2. is not a bad compromise and
>> would bring a lot of value by itself even if not 100% aligned on CDI
>> programming model.
>>
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>

Re: propertyfileconfig and lifecycle

[Mark Struberg]

We can move it from AfterDeploymentValidation to AfterBeanDiscovery.
My argument was about why we _not_ do it immediately in ProcessAnnotatedType.

Will go ahead.

LieGrue,
strub

> Am 27.11.2017 um 14:32 schrieb Romain Manni-Bucau :
> 
> Hi guys,
> 
> I would like to discuss DELTASPIKE-1296 (and avoid jira noise ;))
> 
> Issue is AfterDeploymentValidation order of extensions is not
> deterministic and therefore we can end up in cases where our
> extensions are not usable in between them cause of that. it is
> typically the case for the config extension which is used by all other
> ones.
> 
> To solve it - keeping the deterministic behavior we have - we can:
> 
> 1. register earlier the PropertyFileConfig (AfterBeanDiscovery?)
> 2. have a single AfterDeploymentValidation observer in all our
> codebase and be able to sort extensions here (@Priority or a custom
> @Order). Note we can apply it to [Before|After]BeanDiscovery too.
> 3. surely others
> 
> Goal is to ensure the mainstream programming model we have works in
> most cases and there is no arbitrary reason to not have it working.
> 
> wdyt? Personally I'm tempted to say 2. is not a bad compromise and
> would bring a lot of value by itself even if not 100% aligned on CDI
> programming model.
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn

[jira] [Resolved] (DELTASPIKE-1285) DeltaSpike Dependency Injection using Vaadin-CDI and Payara Micro

[Mark Struberg (JIRA)]

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

Mark Struberg resolved DELTASPIKE-1285.
---
Resolution: Not A Problem
  Assignee: Mark Struberg

Not a bug on our side as an empty beans.xml or beans tag indicates 
bean-discovery-mode 'all' - even in CDI > 1.0


> 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
>Assignee: Mark Struberg
>  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)
>

propertyfileconfig and lifecycle

[Romain Manni-Bucau]

Hi guys,

I would like to discuss DELTASPIKE-1296 (and avoid jira noise ;))

Issue is AfterDeploymentValidation order of extensions is not
deterministic and therefore we can end up in cases where our
extensions are not usable in between them cause of that. it is
typically the case for the config extension which is used by all other
ones.

To solve it - keeping the deterministic behavior we have - we can:

1. register earlier the PropertyFileConfig (AfterBeanDiscovery?)
2. have a single AfterDeploymentValidation observer in all our
codebase and be able to sort extensions here (@Priority or a custom
@Order). Note we can apply it to [Before|After]BeanDiscovery too.
3. surely others

Goal is to ensure the mainstream programming model we have works in
most cases and there is no arbitrary reason to not have it working.

wdyt? Personally I'm tempted to say 2. is not a bad compromise and
would bring a lot of value by itself even if not 100% aligned on CDI
programming model.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn

[jira] [Commented] (DELTASPIKE-1296) PropertyFileConfig doesn't work with internal extensions

[Romain Manni-Bucau (JIRA)]

[ 
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

[Romain Manni-Bucau (JIRA)]

 [ 
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] [Resolved] (DELTASPIKE-1294) Secured Stereotypes are not applied to inherited methods

[Mark Struberg (JIRA)]

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

Mark Struberg resolved DELTASPIKE-1294.
---
   Resolution: Fixed
 Assignee: Mark Struberg
Fix Version/s: 1.8.1

> Secured Stereotypes are not applied to inherited methods
> 
>
> Key: DELTASPIKE-1294
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1294
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Security-Module
>Affects Versions: 1.8.0
>Reporter: Andrew Schmidt
>Assignee: Mark Struberg
> Fix For: 1.8.1
>
>
> I have a @Secured @Stereotype annotation
> {code:java}
> @Retention( RUNTIME )
> @Stereotype
> @Inherited
> @Secured( CustomAccessDecisionVoter.class ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> public @interface Permission {
> }
> {code}
> And my decision voter:
> {code:java}
> @ApplicationScoped
> public class CustomAccessDecisionVoter extends AbstractAccessDecisionVoter {
> @Override
> protected void checkPermission( AccessDecisionVoterContext voterContext, 
> Set violations )
> {
> System.out.println( "Checking permission for " + 
> voterContext. getSource().getMethod().getName() );
> }
> }
> {code}
> And now a bean that inherits from another class
> {code:java}
> public class Animal
> {
> public String getParentName()
> {
> return "parent";
> }
> }
> {code}
> {code:java}
> @Named
> @Permission
> public class Dog extends Animal
> {
> public String getChildName()
> {
> return "dog";
> }
> }
> {code}
> In JSF dogName: 
> {code}#{dog.childName}{code} will invoke the checkPermission whereas   
> {code}#{dog.parentName}{code} will not
> This is in contrast to the @SecurityBindingType 
> {code:java}
> @Retention( value = RetentionPolicy.RUNTIME ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> @Documented 
> @SecurityBindingType
> public @interface UserLoggedIn {
> }
> {code}
> {code:java}
> @ApplicationScoped
> public class LoginAuthorizer
> {
> @Secures
> @UserLoggedIn
> public boolean doSecuredCheck( InvocationContext invocationContext ) 
> throws Exception
> {
> System.out.println( "doSecuredCheck called for: " + 
> invocationContext.getMethod().getName() );
> return true;
> }
> }
> {code}
> Now applying @UserLoggedIn to  the Dog class will cause the doSecuredCheck to 
> fire for both getChildName and getParentName



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (DELTASPIKE-1296) PropertyFileConfig doesn't work with internal extensions

[Mark Struberg (JIRA)]

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

Mark Struberg resolved DELTASPIKE-1296.
---
Resolution: Not A Problem

No Romain, the behaviour is really intentionally. 

We do NOT immediately register any PropertyFileConfig we find in 
ProcessAnnotatedType because that way we would probably introduce random 
behaviour. If any other Extension would require this information in PAT as well 
then you would get different results depending on whether the class with the 
PropertyFileConfig gets scanned first or last.

If one has an Extension which needs the information in this ConfigSource then 
he should use 
META-INF/services/org.apache.deltaspike.core.api.config.PropertyFileConfig to 
register the ConfigSource. See DELTASPIKE-837 for more info

> 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-1294) Secured Stereotypes are not applied to inherited methods

[Mark Struberg (JIRA)]

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

Mark Struberg commented on DELTASPIKE-1294:
---

I've pushed a fix. Can you plz re-test?

> Secured Stereotypes are not applied to inherited methods
> 
>
> Key: DELTASPIKE-1294
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1294
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Security-Module
>Affects Versions: 1.8.0
>Reporter: Andrew Schmidt
>
> I have a @Secured @Stereotype annotation
> {code:java}
> @Retention( RUNTIME )
> @Stereotype
> @Inherited
> @Secured( CustomAccessDecisionVoter.class ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> public @interface Permission {
> }
> {code}
> And my decision voter:
> {code:java}
> @ApplicationScoped
> public class CustomAccessDecisionVoter extends AbstractAccessDecisionVoter {
> @Override
> protected void checkPermission( AccessDecisionVoterContext voterContext, 
> Set violations )
> {
> System.out.println( "Checking permission for " + 
> voterContext. getSource().getMethod().getName() );
> }
> }
> {code}
> And now a bean that inherits from another class
> {code:java}
> public class Animal
> {
> public String getParentName()
> {
> return "parent";
> }
> }
> {code}
> {code:java}
> @Named
> @Permission
> public class Dog extends Animal
> {
> public String getChildName()
> {
> return "dog";
> }
> }
> {code}
> In JSF dogName: 
> {code}#{dog.childName}{code} will invoke the checkPermission whereas   
> {code}#{dog.parentName}{code} will not
> This is in contrast to the @SecurityBindingType 
> {code:java}
> @Retention( value = RetentionPolicy.RUNTIME ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> @Documented 
> @SecurityBindingType
> public @interface UserLoggedIn {
> }
> {code}
> {code:java}
> @ApplicationScoped
> public class LoginAuthorizer
> {
> @Secures
> @UserLoggedIn
> public boolean doSecuredCheck( InvocationContext invocationContext ) 
> throws Exception
> {
> System.out.println( "doSecuredCheck called for: " + 
> invocationContext.getMethod().getName() );
> return true;
> }
> }
> {code}
> Now applying @UserLoggedIn to  the Dog class will cause the doSecuredCheck to 
> fire for both getChildName and getParentName



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1294) Secured Stereotypes are not applied to inherited methods

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on DELTASPIKE-1294:
-

Commit b1903c2b3463dfa368d0fe973c72f2055c838bf6 in deltaspike's branch 
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=b1903c2 ]

DELTASPIKE-1294 fix SecurityBinding extraction


> Secured Stereotypes are not applied to inherited methods
> 
>
> Key: DELTASPIKE-1294
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1294
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Security-Module
>Affects Versions: 1.8.0
>Reporter: Andrew Schmidt
>
> I have a @Secured @Stereotype annotation
> {code:java}
> @Retention( RUNTIME )
> @Stereotype
> @Inherited
> @Secured( CustomAccessDecisionVoter.class ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> public @interface Permission {
> }
> {code}
> And my decision voter:
> {code:java}
> @ApplicationScoped
> public class CustomAccessDecisionVoter extends AbstractAccessDecisionVoter {
> @Override
> protected void checkPermission( AccessDecisionVoterContext voterContext, 
> Set violations )
> {
> System.out.println( "Checking permission for " + 
> voterContext. getSource().getMethod().getName() );
> }
> }
> {code}
> And now a bean that inherits from another class
> {code:java}
> public class Animal
> {
> public String getParentName()
> {
> return "parent";
> }
> }
> {code}
> {code:java}
> @Named
> @Permission
> public class Dog extends Animal
> {
> public String getChildName()
> {
> return "dog";
> }
> }
> {code}
> In JSF dogName: 
> {code}#{dog.childName}{code} will invoke the checkPermission whereas   
> {code}#{dog.parentName}{code} will not
> This is in contrast to the @SecurityBindingType 
> {code:java}
> @Retention( value = RetentionPolicy.RUNTIME ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> @Documented 
> @SecurityBindingType
> public @interface UserLoggedIn {
> }
> {code}
> {code:java}
> @ApplicationScoped
> public class LoginAuthorizer
> {
> @Secures
> @UserLoggedIn
> public boolean doSecuredCheck( InvocationContext invocationContext ) 
> throws Exception
> {
> System.out.println( "doSecuredCheck called for: " + 
> invocationContext.getMethod().getName() );
> return true;
> }
> }
> {code}
> Now applying @UserLoggedIn to  the Dog class will cause the doSecuredCheck to 
> fire for both getChildName and getParentName



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (DELTASPIKE-1294) Secured Stereotypes are not applied to inherited methods

[Gerhard Petracek (JIRA)]

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

Gerhard Petracek edited comment on DELTASPIKE-1294 at 11/27/17 11:54 AM:
-

we could adjust SecuredAnnotationAuthorizer#extractMetadata to get rid of the 
inconsistency, however, we need a way to limit the evaluation to the mode we 
have currently.
as always both approaches have advantages and disadvantages.
i guess the reason for the inconsistency is caused by the origin of both 
annotations.
(@Secures came from seam3 whereas @Secured came from codi)

for now just annotate the base-class as well.
in case that isn't possible, because it is e.g. a class provided by a 3rd party 
library, it should be possible to override the methods (combined with a simple 
delegation to the method of the base class).


was (Author: gpetracek):
we could adjust SecuredAnnotationAuthorizer#extractMetadata to get rid of the 
inconsistency, however, we need a way to limit the evaluation to the mode we 
have currently.

for now just annotate the base-class as well.
in case that isn't possible, because it is e.g. a class provided by a 3rd party 
library, it should be possible to override the methods (combined with a simple 
delegation to the method of the base class).

> Secured Stereotypes are not applied to inherited methods
> 
>
> Key: DELTASPIKE-1294
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1294
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Security-Module
>Affects Versions: 1.8.0
>Reporter: Andrew Schmidt
>
> I have a @Secured @Stereotype annotation
> {code:java}
> @Retention( RUNTIME )
> @Stereotype
> @Inherited
> @Secured( CustomAccessDecisionVoter.class ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> public @interface Permission {
> }
> {code}
> And my decision voter:
> {code:java}
> @ApplicationScoped
> public class CustomAccessDecisionVoter extends AbstractAccessDecisionVoter {
> @Override
> protected void checkPermission( AccessDecisionVoterContext voterContext, 
> Set violations )
> {
> System.out.println( "Checking permission for " + 
> voterContext. getSource().getMethod().getName() );
> }
> }
> {code}
> And now a bean that inherits from another class
> {code:java}
> public class Animal
> {
> public String getParentName()
> {
> return "parent";
> }
> }
> {code}
> {code:java}
> @Named
> @Permission
> public class Dog extends Animal
> {
> public String getChildName()
> {
> return "dog";
> }
> }
> {code}
> In JSF dogName: 
> {code}#{dog.childName}{code} will invoke the checkPermission whereas   
> {code}#{dog.parentName}{code} will not
> This is in contrast to the @SecurityBindingType 
> {code:java}
> @Retention( value = RetentionPolicy.RUNTIME ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> @Documented 
> @SecurityBindingType
> public @interface UserLoggedIn {
> }
> {code}
> {code:java}
> @ApplicationScoped
> public class LoginAuthorizer
> {
> @Secures
> @UserLoggedIn
> public boolean doSecuredCheck( InvocationContext invocationContext ) 
> throws Exception
> {
> System.out.println( "doSecuredCheck called for: " + 
> invocationContext.getMethod().getName() );
> return true;
> }
> }
> {code}
> Now applying @UserLoggedIn to  the Dog class will cause the doSecuredCheck to 
> fire for both getChildName and getParentName



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1294) Secured Stereotypes are not applied to inherited methods

[Gerhard Petracek (JIRA)]

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

Gerhard Petracek commented on DELTASPIKE-1294:
--

we could adjust SecuredAnnotationAuthorizer#extractMetadata to get rid of the 
inconsistency, however, we need a way to limit the evaluation to the mode we 
have currently.

for now just annotate the base-class as well.
in case that isn't possible, because it is e.g. a class provided by a 3rd party 
library, it should be possible to override the methods (combined with a simple 
delegation to the method of the base class).

> Secured Stereotypes are not applied to inherited methods
> 
>
> Key: DELTASPIKE-1294
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1294
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Security-Module
>Affects Versions: 1.8.0
>Reporter: Andrew Schmidt
>
> I have a @Secured @Stereotype annotation
> {code:java}
> @Retention( RUNTIME )
> @Stereotype
> @Inherited
> @Secured( CustomAccessDecisionVoter.class ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> public @interface Permission {
> }
> {code}
> And my decision voter:
> {code:java}
> @ApplicationScoped
> public class CustomAccessDecisionVoter extends AbstractAccessDecisionVoter {
> @Override
> protected void checkPermission( AccessDecisionVoterContext voterContext, 
> Set violations )
> {
> System.out.println( "Checking permission for " + 
> voterContext. getSource().getMethod().getName() );
> }
> }
> {code}
> And now a bean that inherits from another class
> {code:java}
> public class Animal
> {
> public String getParentName()
> {
> return "parent";
> }
> }
> {code}
> {code:java}
> @Named
> @Permission
> public class Dog extends Animal
> {
> public String getChildName()
> {
> return "dog";
> }
> }
> {code}
> In JSF dogName: 
> {code}#{dog.childName}{code} will invoke the checkPermission whereas   
> {code}#{dog.parentName}{code} will not
> This is in contrast to the @SecurityBindingType 
> {code:java}
> @Retention( value = RetentionPolicy.RUNTIME ) 
> @Target( { ElementType.TYPE, ElementType.METHOD } ) 
> @Documented 
> @SecurityBindingType
> public @interface UserLoggedIn {
> }
> {code}
> {code:java}
> @ApplicationScoped
> public class LoginAuthorizer
> {
> @Secures
> @UserLoggedIn
> public boolean doSecuredCheck( InvocationContext invocationContext ) 
> throws Exception
> {
> System.out.println( "doSecuredCheck called for: " + 
> invocationContext.getMethod().getName() );
> return true;
> }
> }
> {code}
> Now applying @UserLoggedIn to  the Dog class will cause the doSecuredCheck to 
> fire for both getChildName and getParentName



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1296) PropertyFileConfig doesn't work with internal extensions

[Romain Manni-Bucau (JIRA)]

[ 
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

[Romain Manni-Bucau (JIRA)]

 [ 
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] [Resolved] (DELTASPIKE-1296) PropertyFileConfig doesn't work with internal extensions

[Mark Struberg (JIRA)]

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

Mark Struberg resolved DELTASPIKE-1296.
---
Resolution: Not A Problem

Hi!

One can register a PropertyFileConfig in 2 ways:
# Automatically let them pick up via ProcessAnnotatedType. In this case it has 
the restriction as you described
# via java.util.ServiceLoader. Just create a 
META-INF/services/org.apache.deltaspike.core.api.config.PropertyFileConfig with 
your fully qualified classname. Don't forget to annotate the class with 
@Exclude to prevent it go get picked up twice ;)

The code where this is done is in DefaultConfigSourceProvider#106

> 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] [Assigned] (DELTASPIKE-1296) PropertyFileConfig doesn't work with internal extensions

[Mark Struberg (JIRA)]

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

Mark Struberg reassigned DELTASPIKE-1296:
-

Assignee: Mark Struberg

> 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

[Mark Struberg (JIRA)]

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

Mark Struberg commented on DELTASPIKE-1302:
---

> i hope we can get rid of short-lived branches

Yes, we should only do short lived branches on private repos and not push them 
to the ASF cannonical repo.


> 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] [Resolved] (DELTASPIKE-1287) asList() getValue() fails with a NPE if no configured value exists

[Mark Struberg (JIRA)]

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

Mark Struberg resolved DELTASPIKE-1287.
---
Resolution: Fixed

applied, txs for the patch!

> asList() getValue() fails with a NPE if no configured value exists
> --
>
> Key: DELTASPIKE-1287
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1287
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.8.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.8.1
>
> Attachments: 0001-DELTASPIKE-1272-1287-make-defaultValues-work.patch
>
>
> We currently blow up with a NullPointerException if a List gets resolved and 
> no value was actually configured.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (DELTASPIKE-1272) ConfigResolver asList breaks if no value is found

[Mark Struberg (JIRA)]

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

Mark Struberg resolved DELTASPIKE-1272.
---
Resolution: Fixed

applied, txs for the patch!

> ConfigResolver asList breaks if no value is found
> -
>
> Key: DELTASPIKE-1272
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1272
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.8.0
>Reporter: Alexander Falb
>Assignee: Mark Struberg
> Fix For: 1.8.1
>
> Attachments: deltaspike.patch
>
>
> When calling 
> {code:java}
> ConfigResolver.resolve("notexisting").as(Integer.class).asList().getValue();
> {code}
> a NullPointerException is thrown:
> {code}
> java.lang.NullPointerException
> at 
> org.apache.deltaspike.core.api.config.ConfigResolver$PropertyBuilder.splitAndConvertListValue(ConfigResolver.java:1020)
> at 
> org.apache.deltaspike.core.api.config.ConfigResolver$PropertyBuilder.getValue(ConfigResolver.java:988)
> {code}
> I created and attached a patch (including a few unit tests) to fix this 
> issue. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1272) ConfigResolver asList breaks if no value is found

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on DELTASPIKE-1272:
-

Commit 1174922e4fa438948bada8c9afe86952933fafc2 in deltaspike's branch 
refs/heads/master from [~elexx]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=1174922 ]

DELTASPIKE-1272 / 1287: make defaultValues work

Signed-off-by: Mark Struberg 


> ConfigResolver asList breaks if no value is found
> -
>
> Key: DELTASPIKE-1272
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1272
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.8.0
>Reporter: Alexander Falb
>Assignee: Mark Struberg
> Fix For: 1.8.1
>
> Attachments: deltaspike.patch
>
>
> When calling 
> {code:java}
> ConfigResolver.resolve("notexisting").as(Integer.class).asList().getValue();
> {code}
> a NullPointerException is thrown:
> {code}
> java.lang.NullPointerException
> at 
> org.apache.deltaspike.core.api.config.ConfigResolver$PropertyBuilder.splitAndConvertListValue(ConfigResolver.java:1020)
> at 
> org.apache.deltaspike.core.api.config.ConfigResolver$PropertyBuilder.getValue(ConfigResolver.java:988)
> {code}
> I created and attached a patch (including a few unit tests) to fix this 
> issue. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (DELTASPIKE-1287) asList() getValue() fails with a NPE if no configured value exists

[Alexander Falb (JIRA)]

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

Alexander Falb updated DELTASPIKE-1287:
---
Attachment: 0001-DELTASPIKE-1272-1287-make-defaultValues-work.patch

Attached 0001-DELTASPIKE-1272-1287-make-defaultValues-work.patch as proposal to 
fix this issue.

> asList() getValue() fails with a NPE if no configured value exists
> --
>
> Key: DELTASPIKE-1287
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1287
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.8.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.8.1
>
> Attachments: 0001-DELTASPIKE-1272-1287-make-defaultValues-work.patch
>
>
> We currently blow up with a NullPointerException if a List gets resolved and 
> no value was actually configured.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)