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
