retrieve StripesFilter configuration outside of an Stripes request

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

retrieve StripesFilter configuration outside of an Stripes request

Juan Pablo Santos Rodríguez
Hi,

we're currently developing some MBeans for some administrative tasks and we would like to expose all registered ActionBeans URLs through JMX. Obtaining them is easy, if you have a request routed through StripesFilter:

    Map< String, Object > stripesUrlBindings() {
        final Map< String, Object > stripesUrlBindings = new HashMap<>();
        if( StripesFilter.getConfiguration() != null && StripesFilter.getConfiguration().getActionResolver() instanceof AnnotatedClassActionResolver ) {
            final AnnotatedClassActionResolver acar = ( AnnotatedClassActionResolver )StripesFilter.getConfiguration().getActionResolver();
            final Map< String, Class< ? extends ActionBean > > stripesOriginalUrlBindings = acar.getUrlBindingFactory().getPathMap();
            for( final Map.Entry< String, Class< ? extends ActionBean > > entry : stripesOriginalUrlBindings.entrySet() ) {
                final Map< String, String > map = new LinkedHashMap<>();
                map.put( "actionbean", entry.getValue().getCanonicalName() );
                stripesUrlBindings.put( "{[" + entry.getKey() + "],methods=[*]}", map );
            }
        }
        return stripesUrlBindings;
    }

However, a JMX call is not going to be routed through the StripesFilter so StripesFilter.getConfiguration() yields null, and an error stating that the request hasn't been routed through Stripes is logged.

any ideas on how to proceed?


thanks in advance,
juan pablo

------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: retrieve StripesFilter configuration outside of an Stripes request

VANKEISBELCK Remi
Hi Juan Pablo,

Maybe keep the configuration it as a static field of a @ConfigurableComponent ?

Note that it'll work only if you have one config. Stripes config allows to do lots of fancy stuff that I personally never used, but who knows, that door is open :P

Cheers

Rémi



2016-07-28 14:27 GMT+02:00 Juan Pablo Santos Rodríguez <[hidden email]>:
Hi,

we're currently developing some MBeans for some administrative tasks and we would like to expose all registered ActionBeans URLs through JMX. Obtaining them is easy, if you have a request routed through StripesFilter:

    Map< String, Object > stripesUrlBindings() {
        final Map< String, Object > stripesUrlBindings = new HashMap<>();
        if( StripesFilter.getConfiguration() != null && StripesFilter.getConfiguration().getActionResolver() instanceof AnnotatedClassActionResolver ) {
            final AnnotatedClassActionResolver acar = ( AnnotatedClassActionResolver )StripesFilter.getConfiguration().getActionResolver();
            final Map< String, Class< ? extends ActionBean > > stripesOriginalUrlBindings = acar.getUrlBindingFactory().getPathMap();
            for( final Map.Entry< String, Class< ? extends ActionBean > > entry : stripesOriginalUrlBindings.entrySet() ) {
                final Map< String, String > map = new LinkedHashMap<>();
                map.put( "actionbean", entry.getValue().getCanonicalName() );
                stripesUrlBindings.put( "{[" + entry.getKey() + "],methods=[*]}", map );
            }
        }
        return stripesUrlBindings;
    }

However, a JMX call is not going to be routed through the StripesFilter so StripesFilter.getConfiguration() yields null, and an error stating that the request hasn't been routed through Stripes is logged.

any ideas on how to proceed?


thanks in advance,
juan pablo

------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: retrieve StripesFilter configuration outside of an Stripes request

Juan Pablo Santos Rodríguez
Hi Remi,

quite there, but still not sure if there is a better way to do this.

ConfigurableComponent is used on two separate places:
- to instantiate core parts of Stripes (i.e. object factory, action bean resolver, property binder, context factory, etc.). Stripes only allows to have on of each one of those parts, so if I want to access there Stripes' configuration I have to replace one of those core, default classes with a custom one. Not very appealing. Also, at that stage, Stripes Configuration hasn't finished, so depending on which part you substitute, you may not have all the information you need from Stripes configuration.

- to initialize Interceptors which also implement ConfigurableComponent. I went this way, hoping that I could declare an Interceptor without annotating it with @Intercepts (so it would be called only when initializated), but if the Interceptor isn't annotated, then it gets ignored. So I've ended up with an empty intercepts() method which get's called on every request, but at least I'm able to get the required configuration at init() time. Not the cleanest thing, but it gets things done. I also looked at ObjectPostProcessors, but they're instantiated too early to be able to have a look at url bindings.

Ideally, to support this kind of use cases, it would be nice to have some sort of CustomConfigurableComponent (empty interface extending ConfigurableComponent) which Stripes could use to initialize all classes implementing it after it's done with the other ConfigurableComponents. Thoughts?

Finally, just out of curiosity, regarding multiple configs: I've come accross some comments on StripesFilter saying that it's possible, is there any more documentation about this feature? I've had a quick look at StripesFilter code, so most probably are more comments or javadocs elsewhere.


thanks in advance,
juan pablo



On Thu, Jul 28, 2016 at 3:09 PM, VANKEISBELCK Remi <[hidden email]> wrote:
Hi Juan Pablo,

Maybe keep the configuration it as a static field of a @ConfigurableComponent ?

Note that it'll work only if you have one config. Stripes config allows to do lots of fancy stuff that I personally never used, but who knows, that door is open :P

Cheers

Rémi



2016-07-28 14:27 GMT+02:00 Juan Pablo Santos Rodríguez <[hidden email]>:
Hi,

we're currently developing some MBeans for some administrative tasks and we would like to expose all registered ActionBeans URLs through JMX. Obtaining them is easy, if you have a request routed through StripesFilter:

    Map< String, Object > stripesUrlBindings() {
        final Map< String, Object > stripesUrlBindings = new HashMap<>();
        if( StripesFilter.getConfiguration() != null && StripesFilter.getConfiguration().getActionResolver() instanceof AnnotatedClassActionResolver ) {
            final AnnotatedClassActionResolver acar = ( AnnotatedClassActionResolver )StripesFilter.getConfiguration().getActionResolver();
            final Map< String, Class< ? extends ActionBean > > stripesOriginalUrlBindings = acar.getUrlBindingFactory().getPathMap();
            for( final Map.Entry< String, Class< ? extends ActionBean > > entry : stripesOriginalUrlBindings.entrySet() ) {
                final Map< String, String > map = new LinkedHashMap<>();
                map.put( "actionbean", entry.getValue().getCanonicalName() );
                stripesUrlBindings.put( "{[" + entry.getKey() + "],methods=[*]}", map );
            }
        }
        return stripesUrlBindings;
    }

However, a JMX call is not going to be routed through the StripesFilter so StripesFilter.getConfiguration() yields null, and an error stating that the request hasn't been routed through Stripes is logged.

any ideas on how to proceed?


thanks in advance,
juan pablo

------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: retrieve StripesFilter configuration outside of an Stripes request

VANKEISBELCK Remi
Hi again,

Ok, seems too complicated. 

Another way maybe : use the StripesFilter instance that is bound to the ServletContext. In net.sourceforge.stripes.controller.StripesFilter#init :
this.servletContext.setAttribute(StripesFilter.class.getName(), this);

So I guess that you can retrieve the filter's configuration by :

StripesFilter sf = (StripesFilter)servletContext.getAttribute(StripesFilter.class.getName())
Configuration c = sf.getInstanceConfiguration();

Now for the multiple configs, I'm not aware of any docs, users, or even use cases for the feature. 
I don't see the need for a webapp with multiple runtime configs, especially in Stripes which does everything once at startup time... I think it's a relic from ancient ages where containers were not managing classloader isolation very well... 
If you find any use for this, please tell me, I'd like to know :P

HTH

Rémi

2016-08-01 19:03 GMT+02:00 Juan Pablo Santos Rodríguez <[hidden email]>:
Hi Remi,

quite there, but still not sure if there is a better way to do this.

ConfigurableComponent is used on two separate places:
- to instantiate core parts of Stripes (i.e. object factory, action bean resolver, property binder, context factory, etc.). Stripes only allows to have on of each one of those parts, so if I want to access there Stripes' configuration I have to replace one of those core, default classes with a custom one. Not very appealing. Also, at that stage, Stripes Configuration hasn't finished, so depending on which part you substitute, you may not have all the information you need from Stripes configuration.

- to initialize Interceptors which also implement ConfigurableComponent. I went this way, hoping that I could declare an Interceptor without annotating it with @Intercepts (so it would be called only when initializated), but if the Interceptor isn't annotated, then it gets ignored. So I've ended up with an empty intercepts() method which get's called on every request, but at least I'm able to get the required configuration at init() time. Not the cleanest thing, but it gets things done. I also looked at ObjectPostProcessors, but they're instantiated too early to be able to have a look at url bindings.

Ideally, to support this kind of use cases, it would be nice to have some sort of CustomConfigurableComponent (empty interface extending ConfigurableComponent) which Stripes could use to initialize all classes implementing it after it's done with the other ConfigurableComponents. Thoughts?

Finally, just out of curiosity, regarding multiple configs: I've come accross some comments on StripesFilter saying that it's possible, is there any more documentation about this feature? I've had a quick look at StripesFilter code, so most probably are more comments or javadocs elsewhere.


thanks in advance,
juan pablo



On Thu, Jul 28, 2016 at 3:09 PM, VANKEISBELCK Remi <[hidden email]> wrote:
Hi Juan Pablo,

Maybe keep the configuration it as a static field of a @ConfigurableComponent ?

Note that it'll work only if you have one config. Stripes config allows to do lots of fancy stuff that I personally never used, but who knows, that door is open :P

Cheers

Rémi



2016-07-28 14:27 GMT+02:00 Juan Pablo Santos Rodríguez <[hidden email]>:
Hi,

we're currently developing some MBeans for some administrative tasks and we would like to expose all registered ActionBeans URLs through JMX. Obtaining them is easy, if you have a request routed through StripesFilter:

    Map< String, Object > stripesUrlBindings() {
        final Map< String, Object > stripesUrlBindings = new HashMap<>();
        if( StripesFilter.getConfiguration() != null && StripesFilter.getConfiguration().getActionResolver() instanceof AnnotatedClassActionResolver ) {
            final AnnotatedClassActionResolver acar = ( AnnotatedClassActionResolver )StripesFilter.getConfiguration().getActionResolver();
            final Map< String, Class< ? extends ActionBean > > stripesOriginalUrlBindings = acar.getUrlBindingFactory().getPathMap();
            for( final Map.Entry< String, Class< ? extends ActionBean > > entry : stripesOriginalUrlBindings.entrySet() ) {
                final Map< String, String > map = new LinkedHashMap<>();
                map.put( "actionbean", entry.getValue().getCanonicalName() );
                stripesUrlBindings.put( "{[" + entry.getKey() + "],methods=[*]}", map );
            }
        }
        return stripesUrlBindings;
    }

However, a JMX call is not going to be routed through the StripesFilter so StripesFilter.getConfiguration() yields null, and an error stating that the request hasn't been routed through Stripes is logged.

any ideas on how to proceed?


thanks in advance,
juan pablo

------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users




------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: retrieve StripesFilter configuration outside of an Stripes request

Juan Pablo Santos Rodríguez
Hi Rémi,

thanks for the tip! :-) Although my JMX MBean doesn't have access to the servlet context, it's also a Spring managed bean, so I've also made it ServletContextAware, which solves the access to the servletContext from the MBean.

At the time of servletContext injection, the Stripes Filter hasn't initialized yet, so I just grab the reference to the servletContext there, and ended up with an action method in the lines of:

    public Map< String, Object > bindings() {
        if( !scannedConfiguration && servletContext != null ) {
            final StripesFilter sf = ( StripesFilter )servletContext.getAttribute( StripesFilter.class.getName() );
            if ( sf != null ) {
                grabUrlBindingsFrom( sf.getInstanceConfiguration() );
                scannedConfiguration = true;
                LOG.info( "Stripes Filter configuration readed" );
            } else {
                LOG.warn( "Stripes Filter not yet initialized" );
            }
        }
        return stripesUrlBindings;
    }


best regards,
juan pablo


On Mon, Aug 1, 2016 at 7:21 PM, VANKEISBELCK Remi <[hidden email]> wrote:
Hi again,

Ok, seems too complicated. 

Another way maybe : use the StripesFilter instance that is bound to the ServletContext. In net.sourceforge.stripes.controller.StripesFilter#init :
this.servletContext.setAttribute(StripesFilter.class.getName(), this);

So I guess that you can retrieve the filter's configuration by :

StripesFilter sf = (StripesFilter)servletContext.getAttribute(StripesFilter.class.getName())
Configuration c = sf.getInstanceConfiguration();

Now for the multiple configs, I'm not aware of any docs, users, or even use cases for the feature. 
I don't see the need for a webapp with multiple runtime configs, especially in Stripes which does everything once at startup time... I think it's a relic from ancient ages where containers were not managing classloader isolation very well... 
If you find any use for this, please tell me, I'd like to know :P

HTH

Rémi

2016-08-01 19:03 GMT+02:00 Juan Pablo Santos Rodríguez <[hidden email]>:
Hi Remi,

quite there, but still not sure if there is a better way to do this.

ConfigurableComponent is used on two separate places:
- to instantiate core parts of Stripes (i.e. object factory, action bean resolver, property binder, context factory, etc.). Stripes only allows to have on of each one of those parts, so if I want to access there Stripes' configuration I have to replace one of those core, default classes with a custom one. Not very appealing. Also, at that stage, Stripes Configuration hasn't finished, so depending on which part you substitute, you may not have all the information you need from Stripes configuration.

- to initialize Interceptors which also implement ConfigurableComponent. I went this way, hoping that I could declare an Interceptor without annotating it with @Intercepts (so it would be called only when initializated), but if the Interceptor isn't annotated, then it gets ignored. So I've ended up with an empty intercepts() method which get's called on every request, but at least I'm able to get the required configuration at init() time. Not the cleanest thing, but it gets things done. I also looked at ObjectPostProcessors, but they're instantiated too early to be able to have a look at url bindings.

Ideally, to support this kind of use cases, it would be nice to have some sort of CustomConfigurableComponent (empty interface extending ConfigurableComponent) which Stripes could use to initialize all classes implementing it after it's done with the other ConfigurableComponents. Thoughts?

Finally, just out of curiosity, regarding multiple configs: I've come accross some comments on StripesFilter saying that it's possible, is there any more documentation about this feature? I've had a quick look at StripesFilter code, so most probably are more comments or javadocs elsewhere.


thanks in advance,
juan pablo



On Thu, Jul 28, 2016 at 3:09 PM, VANKEISBELCK Remi <[hidden email]> wrote:
Hi Juan Pablo,

Maybe keep the configuration it as a static field of a @ConfigurableComponent ?

Note that it'll work only if you have one config. Stripes config allows to do lots of fancy stuff that I personally never used, but who knows, that door is open :P

Cheers

Rémi



2016-07-28 14:27 GMT+02:00 Juan Pablo Santos Rodríguez <[hidden email]>:
Hi,

we're currently developing some MBeans for some administrative tasks and we would like to expose all registered ActionBeans URLs through JMX. Obtaining them is easy, if you have a request routed through StripesFilter:

    Map< String, Object > stripesUrlBindings() {
        final Map< String, Object > stripesUrlBindings = new HashMap<>();
        if( StripesFilter.getConfiguration() != null && StripesFilter.getConfiguration().getActionResolver() instanceof AnnotatedClassActionResolver ) {
            final AnnotatedClassActionResolver acar = ( AnnotatedClassActionResolver )StripesFilter.getConfiguration().getActionResolver();
            final Map< String, Class< ? extends ActionBean > > stripesOriginalUrlBindings = acar.getUrlBindingFactory().getPathMap();
            for( final Map.Entry< String, Class< ? extends ActionBean > > entry : stripesOriginalUrlBindings.entrySet() ) {
                final Map< String, String > map = new LinkedHashMap<>();
                map.put( "actionbean", entry.getValue().getCanonicalName() );
                stripesUrlBindings.put( "{[" + entry.getKey() + "],methods=[*]}", map );
            }
        }
        return stripesUrlBindings;
    }

However, a JMX call is not going to be routed through the StripesFilter so StripesFilter.getConfiguration() yields null, and an error stating that the request hasn't been routed through Stripes is logged.

any ideas on how to proceed?


thanks in advance,
juan pablo

------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users





------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: retrieve StripesFilter configuration outside of an Stripes request

VANKEISBELCK Remi
Hi again Juan Pablo,

Cool ! Glad to know it works.

Indeed, you still have a "init sequence" problem, but I guess that those url bindings are irrelevant until the filter is up.
I mean, you get the actual result by invoking the MBean : it returns an empty list of bindings if the filter is not ready yet.

There are probably other ways to do this without "polling", which you will eventually do if you need to *wait* for those bindings in order to trigger some other processing. 
Stuff like the @CustomConfigurableComponent you talked about : some kind of Stripes "ServletContextListener" equivalent, that could invoke another service to do whatever needed on startup/destroy. 
I also needed this in most of my apps, and I ended up using the JEE base API, which feels mush less "integrated" and has some lifecycle issues...

Feel free to propose an enhancement :)

Cheers

Rémi


2016-08-02 12:47 GMT+02:00 Juan Pablo Santos Rodríguez <[hidden email]>:
Hi Rémi,

thanks for the tip! :-) Although my JMX MBean doesn't have access to the servlet context, it's also a Spring managed bean, so I've also made it ServletContextAware, which solves the access to the servletContext from the MBean.

At the time of servletContext injection, the Stripes Filter hasn't initialized yet, so I just grab the reference to the servletContext there, and ended up with an action method in the lines of:

    public Map< String, Object > bindings() {
        if( !scannedConfiguration && servletContext != null ) {
            final StripesFilter sf = ( StripesFilter )servletContext.getAttribute( StripesFilter.class.getName() );
            if ( sf != null ) {
                grabUrlBindingsFrom( sf.getInstanceConfiguration() );
                scannedConfiguration = true;
                LOG.info( "Stripes Filter configuration readed" );
            } else {
                LOG.warn( "Stripes Filter not yet initialized" );
            }
        }
        return stripesUrlBindings;
    }


best regards,
juan pablo


On Mon, Aug 1, 2016 at 7:21 PM, VANKEISBELCK Remi <[hidden email]> wrote:
Hi again,

Ok, seems too complicated. 

Another way maybe : use the StripesFilter instance that is bound to the ServletContext. In net.sourceforge.stripes.controller.StripesFilter#init :
this.servletContext.setAttribute(StripesFilter.class.getName(), this);

So I guess that you can retrieve the filter's configuration by :

StripesFilter sf = (StripesFilter)servletContext.getAttribute(StripesFilter.class.getName())
Configuration c = sf.getInstanceConfiguration();

Now for the multiple configs, I'm not aware of any docs, users, or even use cases for the feature. 
I don't see the need for a webapp with multiple runtime configs, especially in Stripes which does everything once at startup time... I think it's a relic from ancient ages where containers were not managing classloader isolation very well... 
If you find any use for this, please tell me, I'd like to know :P

HTH

Rémi

2016-08-01 19:03 GMT+02:00 Juan Pablo Santos Rodríguez <[hidden email]>:
Hi Remi,

quite there, but still not sure if there is a better way to do this.

ConfigurableComponent is used on two separate places:
- to instantiate core parts of Stripes (i.e. object factory, action bean resolver, property binder, context factory, etc.). Stripes only allows to have on of each one of those parts, so if I want to access there Stripes' configuration I have to replace one of those core, default classes with a custom one. Not very appealing. Also, at that stage, Stripes Configuration hasn't finished, so depending on which part you substitute, you may not have all the information you need from Stripes configuration.

- to initialize Interceptors which also implement ConfigurableComponent. I went this way, hoping that I could declare an Interceptor without annotating it with @Intercepts (so it would be called only when initializated), but if the Interceptor isn't annotated, then it gets ignored. So I've ended up with an empty intercepts() method which get's called on every request, but at least I'm able to get the required configuration at init() time. Not the cleanest thing, but it gets things done. I also looked at ObjectPostProcessors, but they're instantiated too early to be able to have a look at url bindings.

Ideally, to support this kind of use cases, it would be nice to have some sort of CustomConfigurableComponent (empty interface extending ConfigurableComponent) which Stripes could use to initialize all classes implementing it after it's done with the other ConfigurableComponents. Thoughts?

Finally, just out of curiosity, regarding multiple configs: I've come accross some comments on StripesFilter saying that it's possible, is there any more documentation about this feature? I've had a quick look at StripesFilter code, so most probably are more comments or javadocs elsewhere.


thanks in advance,
juan pablo



On Thu, Jul 28, 2016 at 3:09 PM, VANKEISBELCK Remi <[hidden email]> wrote:
Hi Juan Pablo,

Maybe keep the configuration it as a static field of a @ConfigurableComponent ?

Note that it'll work only if you have one config. Stripes config allows to do lots of fancy stuff that I personally never used, but who knows, that door is open :P

Cheers

Rémi



2016-07-28 14:27 GMT+02:00 Juan Pablo Santos Rodríguez <[hidden email]>:
Hi,

we're currently developing some MBeans for some administrative tasks and we would like to expose all registered ActionBeans URLs through JMX. Obtaining them is easy, if you have a request routed through StripesFilter:

    Map< String, Object > stripesUrlBindings() {
        final Map< String, Object > stripesUrlBindings = new HashMap<>();
        if( StripesFilter.getConfiguration() != null && StripesFilter.getConfiguration().getActionResolver() instanceof AnnotatedClassActionResolver ) {
            final AnnotatedClassActionResolver acar = ( AnnotatedClassActionResolver )StripesFilter.getConfiguration().getActionResolver();
            final Map< String, Class< ? extends ActionBean > > stripesOriginalUrlBindings = acar.getUrlBindingFactory().getPathMap();
            for( final Map.Entry< String, Class< ? extends ActionBean > > entry : stripesOriginalUrlBindings.entrySet() ) {
                final Map< String, String > map = new LinkedHashMap<>();
                map.put( "actionbean", entry.getValue().getCanonicalName() );
                stripesUrlBindings.put( "{[" + entry.getKey() + "],methods=[*]}", map );
            }
        }
        return stripesUrlBindings;
    }

However, a JMX call is not going to be routed through the StripesFilter so StripesFilter.getConfiguration() yields null, and an error stating that the request hasn't been routed through Stripes is logged.

any ideas on how to proceed?


thanks in advance,
juan pablo

------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users






------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: retrieve StripesFilter configuration outside of an Stripes request

Juan Pablo Santos Rodríguez
Hi Rémi,

indeed the init sequence problem is there, but the mbean is going to be called much fewer times than a regular intercepted URL. It doesn't matter too much if the mbean returns an empty map (people using the mbean would know the application is starting). Besides, at the time the MBean is going to be called most probably Stripes Filter has finished initializing anyways.

The problem with the ServletContextListener equivalent is that you're not going to be sure if StripesFilter is configured/present or not at context init time. For instance, it is not on Stripes http test support classes and who knows on any given container. This same lifecycle problem also happens implementing ServletContextAware, so right now I've to check every time if the urlbindings have been grabbed or not. The CustomConfigurableComponent approach would allow solving this issue, and also allow further custom extensions of Stripes, by allowing one-off set-up tasks.

By what I've seen from Stripes source code, it shouldn't be too complicated, after all the initialization is done, scan classes implementing that interface and calling their init(Configuration) methods. I can send a PR, but I fear I won't be able at least until mid-september (current workload + holidays).



br,
juan pablo

On Tue, Aug 2, 2016 at 2:44 PM, VANKEISBELCK Remi <[hidden email]> wrote:
Hi again Juan Pablo,

Cool ! Glad to know it works.

Indeed, you still have a "init sequence" problem, but I guess that those url bindings are irrelevant until the filter is up.
I mean, you get the actual result by invoking the MBean : it returns an empty list of bindings if the filter is not ready yet.

There are probably other ways to do this without "polling", which you will eventually do if you need to *wait* for those bindings in order to trigger some other processing. 
Stuff like the @CustomConfigurableComponent you talked about : some kind of Stripes "ServletContextListener" equivalent, that could invoke another service to do whatever needed on startup/destroy. 
I also needed this in most of my apps, and I ended up using the JEE base API, which feels mush less "integrated" and has some lifecycle issues...

Feel free to propose an enhancement :)

Cheers

Rémi


2016-08-02 12:47 GMT+02:00 Juan Pablo Santos Rodríguez <[hidden email]>:
Hi Rémi,

thanks for the tip! :-) Although my JMX MBean doesn't have access to the servlet context, it's also a Spring managed bean, so I've also made it ServletContextAware, which solves the access to the servletContext from the MBean.

At the time of servletContext injection, the Stripes Filter hasn't initialized yet, so I just grab the reference to the servletContext there, and ended up with an action method in the lines of:

    public Map< String, Object > bindings() {
        if( !scannedConfiguration && servletContext != null ) {
            final StripesFilter sf = ( StripesFilter )servletContext.getAttribute( StripesFilter.class.getName() );
            if ( sf != null ) {
                grabUrlBindingsFrom( sf.getInstanceConfiguration() );
                scannedConfiguration = true;
                LOG.info( "Stripes Filter configuration readed" );
            } else {
                LOG.warn( "Stripes Filter not yet initialized" );
            }
        }
        return stripesUrlBindings;
    }


best regards,
juan pablo


On Mon, Aug 1, 2016 at 7:21 PM, VANKEISBELCK Remi <[hidden email]> wrote:
Hi again,

Ok, seems too complicated. 

Another way maybe : use the StripesFilter instance that is bound to the ServletContext. In net.sourceforge.stripes.controller.StripesFilter#init :
this.servletContext.setAttribute(StripesFilter.class.getName(), this);

So I guess that you can retrieve the filter's configuration by :

StripesFilter sf = (StripesFilter)servletContext.getAttribute(StripesFilter.class.getName())
Configuration c = sf.getInstanceConfiguration();

Now for the multiple configs, I'm not aware of any docs, users, or even use cases for the feature. 
I don't see the need for a webapp with multiple runtime configs, especially in Stripes which does everything once at startup time... I think it's a relic from ancient ages where containers were not managing classloader isolation very well... 
If you find any use for this, please tell me, I'd like to know :P

HTH

Rémi

2016-08-01 19:03 GMT+02:00 Juan Pablo Santos Rodríguez <[hidden email]>:
Hi Remi,

quite there, but still not sure if there is a better way to do this.

ConfigurableComponent is used on two separate places:
- to instantiate core parts of Stripes (i.e. object factory, action bean resolver, property binder, context factory, etc.). Stripes only allows to have on of each one of those parts, so if I want to access there Stripes' configuration I have to replace one of those core, default classes with a custom one. Not very appealing. Also, at that stage, Stripes Configuration hasn't finished, so depending on which part you substitute, you may not have all the information you need from Stripes configuration.

- to initialize Interceptors which also implement ConfigurableComponent. I went this way, hoping that I could declare an Interceptor without annotating it with @Intercepts (so it would be called only when initializated), but if the Interceptor isn't annotated, then it gets ignored. So I've ended up with an empty intercepts() method which get's called on every request, but at least I'm able to get the required configuration at init() time. Not the cleanest thing, but it gets things done. I also looked at ObjectPostProcessors, but they're instantiated too early to be able to have a look at url bindings.

Ideally, to support this kind of use cases, it would be nice to have some sort of CustomConfigurableComponent (empty interface extending ConfigurableComponent) which Stripes could use to initialize all classes implementing it after it's done with the other ConfigurableComponents. Thoughts?

Finally, just out of curiosity, regarding multiple configs: I've come accross some comments on StripesFilter saying that it's possible, is there any more documentation about this feature? I've had a quick look at StripesFilter code, so most probably are more comments or javadocs elsewhere.


thanks in advance,
juan pablo



On Thu, Jul 28, 2016 at 3:09 PM, VANKEISBELCK Remi <[hidden email]> wrote:
Hi Juan Pablo,

Maybe keep the configuration it as a static field of a @ConfigurableComponent ?

Note that it'll work only if you have one config. Stripes config allows to do lots of fancy stuff that I personally never used, but who knows, that door is open :P

Cheers

Rémi



2016-07-28 14:27 GMT+02:00 Juan Pablo Santos Rodríguez <[hidden email]>:
Hi,

we're currently developing some MBeans for some administrative tasks and we would like to expose all registered ActionBeans URLs through JMX. Obtaining them is easy, if you have a request routed through StripesFilter:

    Map< String, Object > stripesUrlBindings() {
        final Map< String, Object > stripesUrlBindings = new HashMap<>();
        if( StripesFilter.getConfiguration() != null && StripesFilter.getConfiguration().getActionResolver() instanceof AnnotatedClassActionResolver ) {
            final AnnotatedClassActionResolver acar = ( AnnotatedClassActionResolver )StripesFilter.getConfiguration().getActionResolver();
            final Map< String, Class< ? extends ActionBean > > stripesOriginalUrlBindings = acar.getUrlBindingFactory().getPathMap();
            for( final Map.Entry< String, Class< ? extends ActionBean > > entry : stripesOriginalUrlBindings.entrySet() ) {
                final Map< String, String > map = new LinkedHashMap<>();
                map.put( "actionbean", entry.getValue().getCanonicalName() );
                stripesUrlBindings.put( "{[" + entry.getKey() + "],methods=[*]}", map );
            }
        }
        return stripesUrlBindings;
    }

However, a JMX call is not going to be routed through the StripesFilter so StripesFilter.getConfiguration() yields null, and an error stating that the request hasn't been routed through Stripes is logged.

any ideas on how to proceed?


thanks in advance,
juan pablo

------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users







------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: retrieve StripesFilter configuration outside of an Stripes request

VANKEISBELCK Remi
Yes ServletContextAware suffers the same problem. 

I think the best option right now, with the current codebase, is to subclass StripesFilter and do whatever you need in init(). This way you are quite sure the filter is there :P

A more "Stripey" way to handle this would be a proper initializer component, like :

@StartupListener
class MyStartupListener implements StripesStartupListener {
  onStripesAppStarted(...);
  onStripesAppStopped(...);
}

Stripes could scan for such component(s) and call it (them). 

Cheers

Rémi


2016-08-02 15:09 GMT+02:00 Juan Pablo Santos Rodríguez <[hidden email]>:
Hi Rémi,

indeed the init sequence problem is there, but the mbean is going to be called much fewer times than a regular intercepted URL. It doesn't matter too much if the mbean returns an empty map (people using the mbean would know the application is starting). Besides, at the time the MBean is going to be called most probably Stripes Filter has finished initializing anyways.

The problem with the ServletContextListener equivalent is that you're not going to be sure if StripesFilter is configured/present or not at context init time. For instance, it is not on Stripes http test support classes and who knows on any given container. This same lifecycle problem also happens implementing ServletContextAware, so right now I've to check every time if the urlbindings have been grabbed or not. The CustomConfigurableComponent approach would allow solving this issue, and also allow further custom extensions of Stripes, by allowing one-off set-up tasks.

By what I've seen from Stripes source code, it shouldn't be too complicated, after all the initialization is done, scan classes implementing that interface and calling their init(Configuration) methods. I can send a PR, but I fear I won't be able at least until mid-september (current workload + holidays).



br,
juan pablo

On Tue, Aug 2, 2016 at 2:44 PM, VANKEISBELCK Remi <[hidden email]> wrote:
Hi again Juan Pablo,

Cool ! Glad to know it works.

Indeed, you still have a "init sequence" problem, but I guess that those url bindings are irrelevant until the filter is up.
I mean, you get the actual result by invoking the MBean : it returns an empty list of bindings if the filter is not ready yet.

There are probably other ways to do this without "polling", which you will eventually do if you need to *wait* for those bindings in order to trigger some other processing. 
Stuff like the @CustomConfigurableComponent you talked about : some kind of Stripes "ServletContextListener" equivalent, that could invoke another service to do whatever needed on startup/destroy. 
I also needed this in most of my apps, and I ended up using the JEE base API, which feels mush less "integrated" and has some lifecycle issues...

Feel free to propose an enhancement :)

Cheers

Rémi


2016-08-02 12:47 GMT+02:00 Juan Pablo Santos Rodríguez <[hidden email]>:
Hi Rémi,

thanks for the tip! :-) Although my JMX MBean doesn't have access to the servlet context, it's also a Spring managed bean, so I've also made it ServletContextAware, which solves the access to the servletContext from the MBean.

At the time of servletContext injection, the Stripes Filter hasn't initialized yet, so I just grab the reference to the servletContext there, and ended up with an action method in the lines of:

    public Map< String, Object > bindings() {
        if( !scannedConfiguration && servletContext != null ) {
            final StripesFilter sf = ( StripesFilter )servletContext.getAttribute( StripesFilter.class.getName() );
            if ( sf != null ) {
                grabUrlBindingsFrom( sf.getInstanceConfiguration() );
                scannedConfiguration = true;
                LOG.info( "Stripes Filter configuration readed" );
            } else {
                LOG.warn( "Stripes Filter not yet initialized" );
            }
        }
        return stripesUrlBindings;
    }


best regards,
juan pablo


On Mon, Aug 1, 2016 at 7:21 PM, VANKEISBELCK Remi <[hidden email]> wrote:
Hi again,

Ok, seems too complicated. 

Another way maybe : use the StripesFilter instance that is bound to the ServletContext. In net.sourceforge.stripes.controller.StripesFilter#init :
this.servletContext.setAttribute(StripesFilter.class.getName(), this);

So I guess that you can retrieve the filter's configuration by :

StripesFilter sf = (StripesFilter)servletContext.getAttribute(StripesFilter.class.getName())
Configuration c = sf.getInstanceConfiguration();

Now for the multiple configs, I'm not aware of any docs, users, or even use cases for the feature. 
I don't see the need for a webapp with multiple runtime configs, especially in Stripes which does everything once at startup time... I think it's a relic from ancient ages where containers were not managing classloader isolation very well... 
If you find any use for this, please tell me, I'd like to know :P

HTH

Rémi

2016-08-01 19:03 GMT+02:00 Juan Pablo Santos Rodríguez <[hidden email]>:
Hi Remi,

quite there, but still not sure if there is a better way to do this.

ConfigurableComponent is used on two separate places:
- to instantiate core parts of Stripes (i.e. object factory, action bean resolver, property binder, context factory, etc.). Stripes only allows to have on of each one of those parts, so if I want to access there Stripes' configuration I have to replace one of those core, default classes with a custom one. Not very appealing. Also, at that stage, Stripes Configuration hasn't finished, so depending on which part you substitute, you may not have all the information you need from Stripes configuration.

- to initialize Interceptors which also implement ConfigurableComponent. I went this way, hoping that I could declare an Interceptor without annotating it with @Intercepts (so it would be called only when initializated), but if the Interceptor isn't annotated, then it gets ignored. So I've ended up with an empty intercepts() method which get's called on every request, but at least I'm able to get the required configuration at init() time. Not the cleanest thing, but it gets things done. I also looked at ObjectPostProcessors, but they're instantiated too early to be able to have a look at url bindings.

Ideally, to support this kind of use cases, it would be nice to have some sort of CustomConfigurableComponent (empty interface extending ConfigurableComponent) which Stripes could use to initialize all classes implementing it after it's done with the other ConfigurableComponents. Thoughts?

Finally, just out of curiosity, regarding multiple configs: I've come accross some comments on StripesFilter saying that it's possible, is there any more documentation about this feature? I've had a quick look at StripesFilter code, so most probably are more comments or javadocs elsewhere.


thanks in advance,
juan pablo



On Thu, Jul 28, 2016 at 3:09 PM, VANKEISBELCK Remi <[hidden email]> wrote:
Hi Juan Pablo,

Maybe keep the configuration it as a static field of a @ConfigurableComponent ?

Note that it'll work only if you have one config. Stripes config allows to do lots of fancy stuff that I personally never used, but who knows, that door is open :P

Cheers

Rémi



2016-07-28 14:27 GMT+02:00 Juan Pablo Santos Rodríguez <[hidden email]>:
Hi,

we're currently developing some MBeans for some administrative tasks and we would like to expose all registered ActionBeans URLs through JMX. Obtaining them is easy, if you have a request routed through StripesFilter:

    Map< String, Object > stripesUrlBindings() {
        final Map< String, Object > stripesUrlBindings = new HashMap<>();
        if( StripesFilter.getConfiguration() != null && StripesFilter.getConfiguration().getActionResolver() instanceof AnnotatedClassActionResolver ) {
            final AnnotatedClassActionResolver acar = ( AnnotatedClassActionResolver )StripesFilter.getConfiguration().getActionResolver();
            final Map< String, Class< ? extends ActionBean > > stripesOriginalUrlBindings = acar.getUrlBindingFactory().getPathMap();
            for( final Map.Entry< String, Class< ? extends ActionBean > > entry : stripesOriginalUrlBindings.entrySet() ) {
                final Map< String, String > map = new LinkedHashMap<>();
                map.put( "actionbean", entry.getValue().getCanonicalName() );
                stripesUrlBindings.put( "{[" + entry.getKey() + "],methods=[*]}", map );
            }
        }
        return stripesUrlBindings;
    }

However, a JMX call is not going to be routed through the StripesFilter so StripesFilter.getConfiguration() yields null, and an error stating that the request hasn't been routed through Stripes is logged.

any ideas on how to proceed?


thanks in advance,
juan pablo

------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users







------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users