Re: [Stripes-users] 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 <
juanpablo.san...@gmail.com>:

> 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  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 <
>> juanpablo.san...@gmail.com>:
>>
>>> 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  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 

Re: [Stripes-users] 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  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 <
> juanpablo.san...@gmail.com>:
>
>> 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  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 <
>>> juanpablo.san...@gmail.com>:
>>>
 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 

Re: [Stripes-users] 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 <
juanpablo.san...@gmail.com>:

> 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  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 <
>> juanpablo.san...@gmail.com>:
>>
>>> 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 

Re: [Stripes-users] 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  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 <
> juanpablo.san...@gmail.com>:
>
>> 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  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 <
>>> juanpablo.san...@gmail.com>:
>>>
 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 > 

Re: [Stripes-users] 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 <
juanpablo.san...@gmail.com>:

> 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  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 <
>> juanpablo.san...@gmail.com>:
>>
>>> 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 

Re: [Stripes-users] 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  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 <
> juanpablo.san...@gmail.com>:
>
>> 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
>> Stripes-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>>
>
>
> --
>
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
--
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] 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 <
juanpablo.san...@gmail.com>:

> 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
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
--
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users