runParent parameter on plugin tags

[jarthel]

I am in the process of putting my application to its own module called
frontend. Since the dashboard is implemented as module, I decided to
have a look at its config. and I found "runParent" in its plugin tag.

What does this do and how do I use it?

I checked the wiki entry for plugins and there was no mentioned of the
parameter. Searching this google group came out empty as well.

Thank you :)

[Peter J. Farrell]

Using this hasn't been documented very well. Since Modules inherit from
their parent, so do your plugins. In some situations you want your
parent plugins to run *before* for the plugins defined in your module,
sometimes you want your parent plugins to run *after* your module
plugins and lastly you may never want any of your parent plugins to run
when in a module.

The valid options (if you define this attribute) are:

* after
* before
* none

This attribute has no affect for base applications (i.e. not in a module).

Best,
.Peter

P.s. I'm going to update the XML Quick Reference wiki page with this
information which is the best place to look up XML syntax:

http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/wiki/ConfigFileExplained

jarthel said the following on 09/10/2009 10:07 PM:

[jarthel]

thank you :)

On Sep 12, 12:24 am, "Peter J. Farrell" <pe...@mach-ii.com> wrote:
> Using this hasn't been documented very well.  Since Modules inherit from
> their parent, so do your plugins.  In some situations you want your
> parent plugins to run *before* for the plugins defined in your module,
> sometimes you want your parent plugins to run *after* your module
> plugins and lastly you may never want any of your parent plugins to run
> when in a module.
>
> The valid options (if you define this attribute) are:
>
> * after
> * before
> * none
>
> This attribute has no affect for base applications (i.e. not in a module).
>
> Best,
> .Peter
>
> P.s.  I'm going to update the XML Quick Reference wiki page with this
> information which is the best place to look up XML syntax:
>

> http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/wiki/ConfigFileExpla...

>
> jarthel said the following on 09/10/2009 10:07 PM:
>
>
>
> > I am in the process of putting my application to its own module called
> > frontend. Since the dashboard is implemented as module, I decided to
> > have a look at its config. and I found "runParent" in its plugin tag.
>
> > What does this do and how do I use it?
>
> > I checked the wiki entry for plugins and there was no mentioned of the
> > parameter. Searching this google group came out empty as well.
>

> > Thank you :)- Hide quoted text -
>
> - Show quoted text -

[Sumit Verma]

Hi Peter,

Is there a way to set runParent attribute to individual plugin? 

Here is a simple use case:

• A web application firewall set up as a base plugin should by default process each request, even inside modules.

• A session handling plugin should only run on the base application (front end).

• An access check / security plugin should run only inside module (let's say when admin is set up as a module).

So, in this case if we set runParent to none inside the admin module, it will disable session handling (good), but it will also disable web app firewall (bad).

I know we can always run the web app firewall in Application.cfc and it will run on each request, but I'm sure there will be other cases where we would like to use the plugin.

I think it might be good to have an attribute called runOnChild="before|after|none|always" that can be set on individual plugin.

Thoughts?

Sumit

[Peter J. Farrell]

Answers inline below.  Would you mind if I used your question and sample use case for entry on the wiki?

Sumit Verma said the following on 09/12/2009 11:12 PM:

Hi Peter,

Is there a way to set runParent attribute to individual plugin?

No, plugins are a cross-cutting concern and it would be imprudent (and really messy) to allow some plugins to run in certain circumstances and not in others.  However, there is a solution to the use case you describe.

Here is a simple use case:

• A web application firewall set up as a base plugin should by default process each request, even inside modules.

• A session handling plugin should only run on the base application (front end).

• An access check / security plugin should run only inside module (let's say when admin is set up as a module).

So, in this case if we set runParent to none inside the admin module, it will disable session handling (good), but it will also disable web app firewall (bad).

I know we can always run the web app firewall in Application.cfc and it will run on each request, but I'm sure there will be other cases where we would like to use the plugin.

I think it might be good to have an attribute called runOnChild="before|after|none|always" that can be set on individual plugin.

First, there is a known defect right now that stopping the solution I will outline below from working:

http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/ticket/194

This will be fixed in Mach-II 1.8 soon (it affects 1.5, 1.6.0 and 1.6.1).

Basically, you will set the runParent="none" and pull in the plugin you want using the overrideAction and/or mapping attribute.  These attributes are documented in the XML Configuration File reference entry on the wiki.

Snip in module:
<plugins runParent="none">
  <plugin name="security" type="MachII.plugins.SimplePlugin />
  ... other plugins...
</plugins>

In parent using override XML when defining the module:
<module name="foo" file="./path/to/mach-ii_foo.xml">
  <mach-ii>
    <plugins>
      <plugin name="security" overrideAction="addFromParent"/>
    </plugins>
  </mach-ii>
</module>

This adds the "security" plugin from the parent into the module with the name of "security".  Remember that plugins are run in the order they are defined, since I want my "security" plugin to be run first -- I added a placeholder in the module to replace.  Otherwise you could do away with that "SimplePlugin" placeholder and the override XML will append the plugin -- therefore the security plugin would be the last plugin to run in the module.  Of course, you still have to have the "security" plugin defined in the base application so you can use the overrideAction to add it to the module.

If you want to use a plugin with different name in the parent, that is fine but you need to use the mapping attribute:

Snip in module:
<plugins runParent="none">
  <plugin name="security" type="MachII.plugins.SimplePlugin />
  ... other plugins...
</plugins>

In parent using override XML:

<module name="foo" file="./path/to/mach-ii_foo.xml">
  <mach-ii>
    <plugins>
      <plugin name="security" overrideAction="addFromParent" mapping="crazyFooBarName" />
    </plugins>
  </mach-ii>
</module>

This pulls in a plugin named "crazyFooBarName" from the parent into the module and replaces "security" plugin placeholder.  Of course, you still have to a plugin named "crazyFooBarName" in the base application (parent).

Again, there is a known ticket right now that stops this from working right now and this will be fixed soon.

Best,
.Peter

[Sumit Verma]

Yes, please feel free to use the content here for the wiki.

So basically, to set a global plugin like web app firewall that needs to run first, when runParent is set to "none" in module, I would create a place holder plugin in the module config. Then, in the base config, during module declaration, "replace/inject" the place holder with a base plugin. 

runOnChild would have been easier, but from your answer I understand it won't work as plugins run in the order they are defined.

I'm new to Mach-II and trying to get my head around the whole project setup and structure. I'm working on creating a sample app with basic setup of a back-end (admin) and front-end. I will e-mail you that in few days for review and if appropriate you can use that for wiki as well.

I have another question about a different issue, but I will send a new message so it's easier to track. 

[Peter J. Farrell]

Cool, pass it along when you can.  Have you checked out AppBooster for Mach-II as a starting point?

.Peter

Sumit Verma said the following on 09/14/2009 06:24 PM:

[Sumit Verma]

Yes, I did go through AppBooster, MachBlog and Dashboard. They were very helpful as starting point. But, I wanted to combine some of the idea's and put together a structure that will take care of some security concern and setup a typical back-end / front-end setup  that will scale nicely.

[Sumit Verma]

Hi Peter,

Attached is a sample app with front-end/back-end setup. I haven't cleaned up the code or documentation but wanted to make sure this is a good flexible/scalable structure. My goal is to create/expand this as a sample app with all the basic features of Mach-II so I can use it as a starting point for all my applications and others can too if they chose to.

One issue I noticed is that I have logging setup in front-end as well as admin module config. But, if I enable it in either of the config it shows up on both, the front-end and the admin module as well. Is it possible to have independent logging configuration by module?

Thanks,

Sumit

[Peter J. Farrell]

Sumit,

Before I forget, thanks for posting this -- I've only had a brief chance to peruse it, but it looks great!  Looks like you spent some time putting it together.

Just to answer your question, logging is a cross-cutting concern in applications and therefore it's application wide.  One reason why we decided to do this is because of inheritance in modules.  If we had separate logging registries between a module and base application and in a module context use an inherited listener -- which logging registry should be used in this context?  This is a good illustration of the why cross-cutting concerns are not easily and cleanly decomposed from each other. This is why we have logging filters so loggers can be configured to listen to certain logging channels.  Improvements to how logging filters can be defined are going to be address in Mach-II 1.9.

Best,
.Peter


Sumit Verma said the following on 10/12/2009 09:05 PM: