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