Hi Rudy,

That's a very good remark, indeed that should be specified.

There's several options. If we evaluate it when the bean is created, it's once per application (most beans are application scoped), but it's at a time when CDI is fully available.

E.g. in this code:

        optionalDBStore.ifPresent(dataBaseIdentityStoreDefinition -> {

            logActivatedIdentityStore(DataBaseIdentityStoreDefinition.class, beanClass);

            identityStoreBeans.add(new CdiProducer<IdentityStore>()

                    .scope(ApplicationScoped.class)

                    .beanClass(IdentityStore.class)

                    .types(Object.class, IdentityStore.class, DataBaseIdentityStore.class)

                    .addToId(DataBaseIdentityStoreDefinition.class)

                    .create(e -> new DataBaseIdentityStore(dataBaseIdentityStoreDefinition))

            );

        });

That would mean in the constructor, which is executed when the lambda is called, which is when the bean is created for the given scope.

Alternative, indeed, just simply every time the value is needed. The latter may be the most flexible thing indeed.

Kind regards,

Arjan Tijms

On Fri, Jul 7, 2017 at 8:52 AM, Rudy De Busscher <rdebusscher@...> wrote:

Arjan, Will,

Maybe an important aspect of this proposal we forgot:

When is the Expression evaluated, at deploy time or when the IdentityStores is called by the IdentityStoreHandler? (and reevaluated each time)

Probably need to add this for clarity.

At deploy time it will be easier and more consistent, but when IdentityStore is used offers more flexibility.

My preference: When Identity store is called.

Best regards

Rudy

On 7 July 2017 at 08:49, Rudy De Busscher <rdebusscher@...> wrote:

Hi,

Container specific features are discouraged as we want to maximize the portability.

But as Arjan explained, any container is allowed to use a custom mechanism IN ADDITION TO the standard defined one.

Since expressions will be resolved by the EL processor, those rule will be applied. So in practice, the easiest solution is to use @Named beans.

Best regards

Rudy

On 7 July 2017 at 08:31, Arjan Tijms <arjan.tijms@...> wrote:

Hi,

On Fri, Jul 7, 2017 at 7:50 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:

Hi,

Glad to see this issue solved, although it's sad that it will probably result in duplication when the Configuration spec is in place.

I just have some questions:
- How will the user register beans for this expressions? Will it just take every @Named beans?

Indeed, it's roughly like the Javadoc of RemembeMe.isRememberMeExpression already specifies. 

The ELProcessor that processes these exceptions is basically created via;

 ELProcessor elProcessor = new ELProcessor();

 elProcessor.getELManager().addELResolver(beanManager.getELResolver());

 

- Did you talk about integration with container specific expressions? GlassFish/Payara password aliases for example. Could they be used where expressions are allowed? I think that should be easy if the spec just mandates to evaluate #{} expressions but leaves the door open to other kind of expressions been accepted (with unspecified behavior).

People can always put something else into a string attribute, and an attribute processor (could even be a CDI extension perhaps) can transform that into anything else before the spec compliant processing code seeing it.

E.g.

@DataBaseIdentityStoreDefinition(

    dataSourceLookup="@@my very own expression @@", 

    callerQuery="#{someBean.callerQuery}",

    groupsQuery="#{someBean.groupQuery}"

)

If the container or a user CDI extension processes this and changes it any either a plain string or another EL expression, I guess it would not interfere.

Kind regards,

Arjan

 

Regards,

Guillermo González de Agüero

On Fri, Jul 7, 2017 at 1:17 AM, Arjan Tijms <arjan.tijms@...> wrote:

Hi,

After the last EG call it was decided that this issue is critical enough to address one way or the other.

The options provided above still all stand, but for now the option with the EL enabled attributes for Strings and 2nd parallel String attributes for non-String types seemed to have the most support.

When a value is provided for this second attribute, it takes precedence over the non-expression based one.

E.g.

The RememberMe annotation now has an integer attribute, several boolean attributes and a string attribute that's already EL enabled:

@RememberMe(

    cookieMaxAgeSeconds = 3600,

    cookieHttpOnly = false,

    cookieSecureOnly = false,

    isRememberMeExpression ="self.isRememberMe(httpMessageContext)"

)

With the proposal implemented that could become:

@RememberMe(
    cookieMaxAgeSecondsExpression="#{someBean.config.cookieAge}"
    cookieHttpOnlyExpression="#{someOtherBean.httpOnly}"

    cookieSecureOnly = false,

    isRememberMeExpression ="#{self.isRememberMe(httpMessageContext)}"

)

Note that the #{} is not strictly needed for the EL 3.0 processor, but is for consistency with attributes that also take normal (constant) strings, e.g.

@DataBaseIdentityStoreDefinition(

    dataSourceLookup="java:global/MyDS", 

    callerQuery="select password from caller where name = ?",

    groupsQuery="select group_name from caller_groups where caller_name = ?"

)

Which could become:

@DataBaseIdentityStoreDefinition(

    dataSourceLookup="#{someBean.dataSource}", 

    callerQuery="#{someBean.callerQuery}",

    groupsQuery="#{someBean.groupQuery}"

)

ACTION: Please let me know if this is ok by end of day 

Sunday 9 July 2017 CEST.  If I don't hear anything, I'll assume this is ok.

Kind regards,
Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

El vie., 7 de julio de 2017 8:32, Arjan Tijms <arjan.tijms@...> escribió:

Hi,

On Fri, Jul 7, 2017 at 7:50 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:

Hi,

Glad to see this issue solved, although it's sad that it will probably result in duplication when the Configuration spec is in place.

I just have some questions:
- How will the user register beans for this expressions? Will it just take every @Named beans?

Indeed, it's roughly like the Javadoc of RemembeMe.isRememberMeExpression already specifies. 

The ELProcessor that processes these exceptions is basically created via;

 ELProcessor elProcessor = new ELProcessor();

 elProcessor.getELManager().addELResolver(beanManager.getELResolver());

 

- Did you talk about integration with container specific expressions? GlassFish/Payara password aliases for example. Could they be used where expressions are allowed? I think that should be easy if the spec just mandates to evaluate #{} expressions but leaves the door open to other kind of expressions been accepted (with unspecified behavior).

People can always put something else into a string attribute, and an attribute processor (could even be a CDI extension perhaps) can transform that into anything else before the spec compliant processing code seeing it.

E.g.

@DataBaseIdentityStoreDefinition(

    dataSourceLookup="@@my very own expression @@", 

    callerQuery="#{someBean.callerQuery}",

    groupsQuery="#{someBean.groupQuery}"

)

If the container or a user CDI extension processes this and changes it any either a plain string or another EL expression, I guess it would not interfere.

That's maybe true, but the user CDI extension can't change the annotation values, it just can wrap the AnnotatedType.

That forces JSR375 implementations to also parse it via a CDI extension. And if we want expressions to be evaluated each time the authentication is used, that means storing the effective AnnotatedType (I don't know if it can be retrieved at runtime).

Kind regards,

Arjan

 

Regards,

Guillermo González de Agüero

On Fri, Jul 7, 2017 at 1:17 AM, Arjan Tijms <arjan.tijms@...> wrote:

Hi,

After the last EG call it was decided that this issue is critical enough to address one way or the other.

The options provided above still all stand, but for now the option with the EL enabled attributes for Strings and 2nd parallel String attributes for non-String types seemed to have the most support.

When a value is provided for this second attribute, it takes precedence over the non-expression based one.

E.g.

The RememberMe annotation now has an integer attribute, several boolean attributes and a string attribute that's already EL enabled:

@RememberMe(

    cookieMaxAgeSeconds = 3600,

    cookieHttpOnly = false,

    cookieSecureOnly = false,

    isRememberMeExpression ="self.isRememberMe(httpMessageContext)"

)

With the proposal implemented that could become:

@RememberMe(
    cookieMaxAgeSecondsExpression="#{someBean.config.cookieAge}"
    cookieHttpOnlyExpression="#{someOtherBean.httpOnly}"

    cookieSecureOnly = false,

    isRememberMeExpression ="#{self.isRememberMe(httpMessageContext)}"

)

Note that the #{} is not strictly needed for the EL 3.0 processor, but is for consistency with attributes that also take normal (constant) strings, e.g.

@DataBaseIdentityStoreDefinition(

    dataSourceLookup="java:global/MyDS", 

    callerQuery="select password from caller where name = ?",

    groupsQuery="select group_name from caller_groups where caller_name = ?"

)

Which could become:

@DataBaseIdentityStoreDefinition(

    dataSourceLookup="#{someBean.dataSource}", 

    callerQuery="#{someBean.callerQuery}",

    groupsQuery="#{someBean.groupQuery}"

)

ACTION: Please let me know if this is ok by end of day 

Sunday 9 July 2017 CEST.  If I don't hear anything, I'll assume this is ok.

Kind regards,
Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

Hi,

Indeed, but by default users can put them in say an @ApplicationScoped bean and only do the actual lookup (i.e. read from a file) in its @PostConstruct. Just evaluating the EL expression and fetching the value from a simple getter in that @ApplicationScoped bean should be fast enough.

Anyone else has any idea about this?

On Fri, Jul 7, 2017 at 6:09 PM, Will Hopkins <will.hopkins@...> wrote:

Aren't these parameters going to be pretty static most of the time? It seems like a waste of processing power looking up every configuration value on each invocation for an IdentityStore. An LDAP URL isn't likely to ever change.

On 07/07/2017 11:41 AM, Arjan Tijms wrote:

Hi Rudy,

That's a very good remark, indeed that should be specified.

There's several options. If we evaluate it when the bean is created, it's once per application (most beans are application scoped), but it's at a time when CDI is fully available.

E.g. in this code:

        optionalDBStore.ifPresent(dataBaseIdentityStoreDefinition -> {

            logActivatedIdentityStore(DataBaseIdentityStoreDefinition.class, beanClass);

            identityStoreBeans.add(new CdiProducer<IdentityStore>()

                    .scope(ApplicationScoped.class)

                    .beanClass(IdentityStore.class)

                    .types(Object.class, IdentityStore.class, DataBaseIdentityStore.class)

                    .addToId(DataBaseIdentityStoreDefinition.class)

                    .create(e -> new DataBaseIdentityStore(dataBaseIdentityStoreDefinition))

            );

        });

That would mean in the constructor, which is executed when the lambda is called, which is when the bean is created for the given scope.

Alternative, indeed, just simply every time the value is needed. The latter may be the most flexible thing indeed.

Kind regards,

Arjan Tijms

On Fri, Jul 7, 2017 at 8:52 AM, Rudy De Busscher <rdebusscher@...> wrote:

Arjan, Will,

Maybe an important aspect of this proposal we forgot:

When is the Expression evaluated, at deploy time or when the IdentityStores is called by the IdentityStoreHandler? (and reevaluated each time)

Probably need to add this for clarity.

At deploy time it will be easier and more consistent, but when IdentityStore is used offers more flexibility.

My preference: When Identity store is called.

Best regards

Rudy

On 7 July 2017 at 08:49, Rudy De Busscher <rdebusscher@...> wrote:

Hi,

Container specific features are discouraged as we want to maximize the portability.

But as Arjan explained, any container is allowed to use a custom mechanism IN ADDITION TO the standard defined one.

Since expressions will be resolved by the EL processor, those rule will be applied. So in practice, the easiest solution is to use @Named beans.

Best regards

Rudy

On 7 July 2017 at 08:31, Arjan Tijms <arjan.tijms@...> wrote:

Hi,

On Fri, Jul 7, 2017 at 7:50 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:

Hi,

Glad to see this issue solved, although it's sad that it will probably result in duplication when the Configuration spec is in place.

I just have some questions:
- How will the user register beans for this expressions? Will it just take every @Named beans?

Indeed, it's roughly like the Javadoc of RemembeMe.isRememberMeExpression already specifies. 

The ELProcessor that processes these exceptions is basically created via;

 ELProcessor elProcessor = new ELProcessor();

 elProcessor.getELManager().addELResolver(beanManager.getELResolver());

 

- Did you talk about integration with container specific expressions? GlassFish/Payara password aliases for example. Could they be used where expressions are allowed? I think that should be easy if the spec just mandates to evaluate #{} expressions but leaves the door open to other kind of expressions been accepted (with unspecified behavior).

People can always put something else into a string attribute, and an attribute processor (could even be a CDI extension perhaps) can transform that into anything else before the spec compliant processing code seeing it.

E.g.

@DataBaseIdentityStoreDefinition(

    dataSourceLookup="@@my very own expression @@", 

    callerQuery="#{someBean.callerQuery}",

    groupsQuery="#{someBean.groupQuery}"

)

If the container or a user CDI extension processes this and changes it any either a plain string or another EL expression, I guess it would not interfere.

Kind regards,

Arjan

 

Regards,

Guillermo González de Agüero

On Fri, Jul 7, 2017 at 1:17 AM, Arjan Tijms <arjan.tijms@...> wrote:

Hi,

After the last EG call it was decided that this issue is critical enough to address one way or the other.

The options provided above still all stand, but for now the option with the EL enabled attributes for Strings and 2nd parallel String attributes for non-String types seemed to have the most support.

When a value is provided for this second attribute, it takes precedence over the non-expression based one.

E.g.

The RememberMe annotation now has an integer attribute, several boolean attributes and a string attribute that's already EL enabled:

@RememberMe(

    cookieMaxAgeSeconds = 3600,

    cookieHttpOnly = false,

    cookieSecureOnly = false,

    isRememberMeExpression ="self.isRememberMe(httpMessageContext)"

)

With the proposal implemented that could become:

@RememberMe(
    cookieMaxAgeSecondsExpression="#{someBean.config.cookieAge}"
    cookieHttpOnlyExpression="#{someOtherBean.httpOnly}"

    cookieSecureOnly = false,

    isRememberMeExpression ="#{self.isRememberMe(httpMessageContext)}"

)

Note that the #{} is not strictly needed for the EL 3.0 processor, but is for consistency with attributes that also take normal (constant) strings, e.g.

@DataBaseIdentityStoreDefinition(

    dataSourceLookup="java:global/MyDS", 

    callerQuery="select password from caller where name = ?",

    groupsQuery="select group_name from caller_groups where caller_name = ?"

)

Which could become:

@DataBaseIdentityStoreDefinition(

    dataSourceLookup="#{someBean.dataSource}", 

    callerQuery="#{someBean.callerQuery}",

    groupsQuery="#{someBean.groupQuery}"

)

ACTION: Please let me know if this is ok by end of day 

Sunday 9 July 2017 CEST.  If I don't hear anything, I'll assume this is ok.

Kind regards,
Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

What about a multitenant setup? Every tenant may potentially connect to different servers. I'm not saying this is the way to handle that case. Just a thought.

Apart from that, I'm with you Will in that most attributes should be fairly static. Annotations are a static way of defining settings. For really dynamic configurations I'd go for plain Java code instead. Given the time constraints, that would go into Soteria for this version.

Regards,

Guillermo González de Agüero.

On Fri, Jul 7, 2017 at 6:09 PM, Will Hopkins <will.hopkins@...> wrote:

Aren't these parameters going to be pretty static most of the time? It seems like a waste of processing power looking up every configuration value on each invocation for an IdentityStore. An LDAP URL isn't likely to ever change.

On 07/07/2017 11:41 AM, Arjan Tijms wrote:

Hi Rudy,

That's a very good remark, indeed that should be specified.

There's several options. If we evaluate it when the bean is created, it's once per application (most beans are application scoped), but it's at a time when CDI is fully available.

E.g. in this code:

        optionalDBStore.ifPresent(dataBaseIdentityStoreDefinition -> {

            logActivatedIdentityStore(DataBaseIdentityStoreDefinition.class, beanClass);

            identityStoreBeans.add(new CdiProducer<IdentityStore>()

                    .scope(ApplicationScoped.class)

                    .beanClass(IdentityStore.class)

                    .types(Object.class, IdentityStore.class, DataBaseIdentityStore.class)

                    .addToId(DataBaseIdentityStoreDefinition.class)

                    .create(e -> new DataBaseIdentityStore(dataBaseIdentityStoreDefinition))

            );

        });

That would mean in the constructor, which is executed when the lambda is called, which is when the bean is created for the given scope.

Alternative, indeed, just simply every time the value is needed. The latter may be the most flexible thing indeed.

Kind regards,

Arjan Tijms

On Fri, Jul 7, 2017 at 8:52 AM, Rudy De Busscher <rdebusscher@...> wrote:

Arjan, Will,

Maybe an important aspect of this proposal we forgot:

When is the Expression evaluated, at deploy time or when the IdentityStores is called by the IdentityStoreHandler? (and reevaluated each time)

Probably need to add this for clarity.

At deploy time it will be easier and more consistent, but when IdentityStore is used offers more flexibility.

My preference: When Identity store is called.

Best regards

Rudy

On 7 July 2017 at 08:49, Rudy De Busscher <rdebusscher@...> wrote:

Hi,

Container specific features are discouraged as we want to maximize the portability.

But as Arjan explained, any container is allowed to use a custom mechanism IN ADDITION TO the standard defined one.

Since expressions will be resolved by the EL processor, those rule will be applied. So in practice, the easiest solution is to use @Named beans.

Best regards

Rudy

On 7 July 2017 at 08:31, Arjan Tijms <arjan.tijms@...> wrote:

Hi,

On Fri, Jul 7, 2017 at 7:50 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:

Hi,

Glad to see this issue solved, although it's sad that it will probably result in duplication when the Configuration spec is in place.

I just have some questions:
- How will the user register beans for this expressions? Will it just take every @Named beans?

Indeed, it's roughly like the Javadoc of RemembeMe.isRememberMeExpression already specifies. 

The ELProcessor that processes these exceptions is basically created via;

 ELProcessor elProcessor = new ELProcessor();

 elProcessor.getELManager().addELResolver(beanManager.getELResolver());

 

- Did you talk about integration with container specific expressions? GlassFish/Payara password aliases for example. Could they be used where expressions are allowed? I think that should be easy if the spec just mandates to evaluate #{} expressions but leaves the door open to other kind of expressions been accepted (with unspecified behavior).

People can always put something else into a string attribute, and an attribute processor (could even be a CDI extension perhaps) can transform that into anything else before the spec compliant processing code seeing it.

E.g.

@DataBaseIdentityStoreDefinition(

    dataSourceLookup="@@my very own expression @@", 

    callerQuery="#{someBean.callerQuery}",

    groupsQuery="#{someBean.groupQuery}"

)

If the container or a user CDI extension processes this and changes it any either a plain string or another EL expression, I guess it would not interfere.

Kind regards,

Arjan

 

Regards,

Guillermo González de Agüero

On Fri, Jul 7, 2017 at 1:17 AM, Arjan Tijms <arjan.tijms@...> wrote:

Hi,

After the last EG call it was decided that this issue is critical enough to address one way or the other.

The options provided above still all stand, but for now the option with the EL enabled attributes for Strings and 2nd parallel String attributes for non-String types seemed to have the most support.

When a value is provided for this second attribute, it takes precedence over the non-expression based one.

E.g.

The RememberMe annotation now has an integer attribute, several boolean attributes and a string attribute that's already EL enabled:

@RememberMe(

    cookieMaxAgeSeconds = 3600,

    cookieHttpOnly = false,

    cookieSecureOnly = false,

    isRememberMeExpression ="self.isRememberMe(httpMessageContext)"

)

With the proposal implemented that could become:

@RememberMe(
    cookieMaxAgeSecondsExpression="#{someBean.config.cookieAge}"
    cookieHttpOnlyExpression="#{someOtherBean.httpOnly}"

    cookieSecureOnly = false,

    isRememberMeExpression ="#{self.isRememberMe(httpMessageContext)}"

)

Note that the #{} is not strictly needed for the EL 3.0 processor, but is for consistency with attributes that also take normal (constant) strings, e.g.

@DataBaseIdentityStoreDefinition(

    dataSourceLookup="java:global/MyDS", 

    callerQuery="select password from caller where name = ?",

    groupsQuery="select group_name from caller_groups where caller_name = ?"

)

Which could become:

@DataBaseIdentityStoreDefinition(

    dataSourceLookup="#{someBean.dataSource}", 

    callerQuery="#{someBean.callerQuery}",

    groupsQuery="#{someBean.groupQuery}"

)

ACTION: Please let me know if this is ok by end of day 

Sunday 9 July 2017 CEST.  If I don't hear anything, I'll assume this is ok.

Kind regards,
Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803