Configuring RIFE in Spring

[Freddy D.]

Dear fellow RIFERS,

Just wanted to run this idea by you and get your comments. I hope this
is the correct place to do so.

I'd like to present to you a simple idea to add a configuration
option to RIFE.

If you're already groaning (oh no, not YET another configuration
option!), please know that I don't think there is anything wrong
with the available options. In fact I like the XML files myself.

To save you time, though, I'll tell you right now not to read this
post if you don't care for Spring (or similar DI containers) or for
another configuration option in RIFE.

Now, if you're still here..

Just like what happened with the template syntax, it may be good to
provide options which could appeal to certain developers, in hopes of
increasing the number of RIFE users. (By the way, while at first,
like many, I didn't like the original template syntax, after working
with RIFE for a while, I actually find the original syntax to be the
best, it's very easy to highlight differently in VIM and it stands
out from the rest of the template. For what it's worth.. I'm one of
those who do like the original syntax :)

So about the different configuration options, it was in fact
recently discussed here:

http://www.theserverside.com/news/thread.tss?thread_id=39731

My proposal is to add an option that enables you to configure your
RIFE site and elements in Spring (or possibly another DI container.)
This may appeal to fans of Spring, to be able to define their RIFE
components in a Spring XML file with the rest of their beans, and
this may bring such developers to 'get' RIFE as a framework that lets
you assemble your web apps with RIFE components and connect them with
flow links and data links. Being able to integrate the configuration
of RIFE components along with the rest of the program, instead of
having another separate set of config files, could be appealing to
Spring users.

To do so would be simple: define Spring-friendly configuration
classes, and use them to build your site.

I've included a (very) simple example as a 'proof of concept'. It
includes 3 config options: original RIFE XML files, Java code, and
Spring. Simply by changing the commenting out in rep/participants.xml
you can switch between each. The Spring config is in
applicationContext.xml. To run the example, you have to add
the RIFE jar and spring.jar in WEB-INF/lib.

Of course, this option is considerably MORE verbose than original
RIFE XML files. As I mentioned earlier, I DO prefer the original
config myself. But, it can't hurt to make a Spring config option
available....can it?

By the way, my implementation is most probably not optimal, so if you
have any suggestions about this, I'd like to learn. Especially on the
configuration of the participants.. right now I have a property to
tell what is the name of the SpringWeb participant, and a parameter
to tell what is the name of the root bean that contains the site
config. If there is a better way to achieve this, by all means, please
let me know.

Of course, additional *Cfg classes and their properties would be
needed, I just wrote a small subset to start.

It's also possible that this is already possible with RIFE and I
didn't know.. if so please enlighten me!

So I'd appreciate your thoughts..
Thanks in advance for your feedback!

Frederic
--
 
  xf2697@...



_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

[Geert Bevin]

Hi Frederic,

actually the XML site declaration is just a wrapper around an existing
Java builder API. You should be able to use that directly inside Spring
and provide the reference to the Site from a participant, similar to
your ParticipantSpringCfg. You can find more information about this
here:
http://rifers.org/wiki/display/RIFE/Site+structure+and+element+declaration+without+XML

I'm not a Spring user, so I can't anticipate if this API will work, but
I don't see a reason why it shouldn't.

Can you try it out with the SiteBuilder API and see if it work?

Thanks and good idea!

Best regards,

Geert

xf2697@... wrote:

> Dear fellow RIFERS,
>
> Just wanted to run this idea by you and get your comments. I hope this
> is the correct place to do so.
>
> I'd like to present to you a simple idea to add a configuration
> option to RIFE.
>
> If you're already groaning (oh no, not YET another configuration
> option!), please know that I don't think there is anything wrong
> with the available options. In fact I like the XML files myself.
>
> To save you time, though, I'll tell you right now not to read this
> post if you don't care for Spring (or similar DI containers) or for
> another configuration option in RIFE.
>
> Now, if you're still here..
>
> Just like what happened with the template syntax, it may be good to
> provide options which could appeal to certain developers, in hopes of
> increasing the number of RIFE users. (By the way, while at first,
> like many, I didn't like the original template syntax, after working
> with RIFE for a while, I actually find the original syntax to be the
> best, it's very easy to highlight differently in VIM and it stands
> out from the rest of the template. For what it's worth.. I'm one of
> those who do like the original syntax :)
>
> So about the different configuration options, it was in fact
> recently discussed here:
>
> http://www.theserverside.com/news/thread.tss?thread_id=39731
>
> My proposal is to add an option that enables you to configure your
> RIFE site and elements in Spring (or possibly another DI container.)
> This may appeal to fans of Spring, to be able to define their RIFE
> components in a Spring XML file with the rest of their beans, and
> this may bring such developers to 'get' RIFE as a framework that lets
> you assemble your web apps with RIFE components and connect them with
> flow links and data links. Being able to integrate the configuration
> of RIFE components along with the rest of the program, instead of
> having another separate set of config files, could be appealing to
> Spring users.
>
> To do so would be simple: define Spring-friendly configuration
> classes, and use them to build your site.
>
> I've included a (very) simple example as a 'proof of concept'. It
> includes 3 config options: original RIFE XML files, Java code, and
> Spring. Simply by changing the commenting out in rep/participants.xml
> you can switch between each. The Spring config is in
> applicationContext.xml. To run the example, you have to add
> the RIFE jar and spring.jar in WEB-INF/lib.
>
> Of course, this option is considerably MORE verbose than original
> RIFE XML files. As I mentioned earlier, I DO prefer the original
> config myself. But, it can't hurt to make a Spring config option
> available....can it?
>
> By the way, my implementation is most probably not optimal, so if you
> have any suggestions about this, I'd like to learn. Especially on the
> configuration of the participants.. right now I have a property to
> tell what is the name of the SpringWeb participant, and a parameter
> to tell what is the name of the root bean that contains the site
> config. If there is a better way to achieve this, by all means, please
> let me know.
>
> Of course, additional *Cfg classes and their properties would be
> needed, I just wrote a small subset to start.
>
> It's also possible that this is already possible with RIFE and I
> didn't know.. if so please enlighten me!
>
> So I'd appreciate your thoughts..
> Thanks in advance for your feedback!
>
> Frederic
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel

--
Geert Bevin             Uwyn bvba               GTalk: gbevin@...
"Use what you need"     Avenue de Scailmont 34  Skype: gbevin
http://www.uwyn.com     7170 Manage, Belgium      AIM: geertbevin
gbevin at uwyn dot com  Tel: [phone]   Mobile: [phone]

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net
_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

[Freddy D.]

Hi Geert,

> I'm not a Spring user, so I can't anticipate if this API will work, but
> I don't see a reason why it shouldn't.
>
> Can you try it out with the SiteBuilder API and see if it work?
>
> Thanks and good idea!
>
> Best regards,
>
> Geert

Thanks for considering this possibility. I got my example to work by building
a 'bridge' between Spring and the SiteBuilder API in the form of simple beans
and a 'worker class' (the ParticipantSpringCfg), as you saw in my code.

At first thought, I don't think it's possible (or if it is, it would be
difficult/tedious) to get Spring to work directly with the SiteBuilder API.
I could be wrong, but consider that Spring basically instantiates beans, either
with default or parametrized constructor, and then calls setters to establish
the bean's properties.

This does not fit well with something like:

builder
  .setArrival("START")
           
  .enterElement("START")
    .setImplementation("tutorial.numberguess.Start")
    .addInput("gameid")
    .addFlowLink("started", "GUESS")
  .leaveElement()
  .enterElement("GUESS")
    .setImplementation("tutorial.numberguess.Guess")
    .enterSubmission("perform_guess")
      .addParameter("guess")
    .leaveSubmission()

because you are not only calling setters, but also other methods (addXXX,
enter XXX), and not only that, but calling methods on the returned objects
(nested elements, submissions, etc.) and then calling leaveXXX() to continue
working with the parent object.

Maybe it's possible with Spring but as I said I think it would be difficult,
or at the very least it would be less natural than declaring beans such as
in my example, which is structured more like this:

"here is element X":
  -set a property
  -set another property

"here is element Y":
  -set a property

"here is my site":
  "here are its elements":
    -element X
    -element Y

etc.

Here only plain setters on beans are called.

I'll investigate more on this, but I'd like to know what you think?

Thanks again,

Frederic


_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

[David Medinets]

I like the Fluent API style of setting values (ie, setters returning a
value to allow chaining). And I like Spring. Putting the two together
seems like a good idea.

To this end, I now have a customized version of
org.springframework.beans.BeanWrapperImpl.java and
java.beans.PropertyDescriptor.java which allows me to use the
following setter and *still* configure the bean using Spring.

    public Person setName(String _name) {
        this.name = _name;
        return this;
    }

If anyone is interested in this work, I'd be happy to share the files.
And if a few people are serious about usage, I'd see if I could avoid
changing PropertyDescriptor.java since it is an official part of Java
(ie, part of rt.jar).

-david
_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

[Geert Bevin]

Hi David,

it might be a good idea to add this to the wiki and attach the files.  
If you want, I can open up a Subversion repository for you to put the  
source code in.

Best regards,

Geert

On 08 Apr 2006, at 06:07, David Medinets wrote:

> I like the Fluent API style of setting values (ie, setters returning a
> value to allow chaining). And I like Spring. Putting the two together
> seems like a good idea.
>
> To this end, I now have a customized version of
> org.springframework.beans.BeanWrapperImpl.java and
> java.beans.PropertyDescriptor.java which allows me to use the
> following setter and *still* configure the bean using Spring.
>
>     public Person setName(String _name) {
>         this.name = _name;
>         return this;
>     }
>
> If anyone is interested in this work, I'd be happy to share the files.
> And if a few people are serious about usage, I'd see if I could avoid
> changing PropertyDescriptor.java since it is an official part of Java
> (ie, part of rt.jar).
>
> -david
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>

--
Geert Bevin             Uwyn bvba               GTalk: gbevin@...
"Use what you need"     Avenue de Scailmont 34  Skype: gbevin
http://www.uwyn.com     7170 Manage, Belgium      AIM: geertbevin
gbevin at uwyn dot com  Tel: [phone]   Mobile: [phone]

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net


_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

[David Medinets]

I have refined my change to just a single file as detailed in

http://opensource.atlassian.com/projects/spring/browse/SPR-1871

I don't know which page on the RIFE wiki should be updated to reflect
this issue.

-david

On 4/8/06, Geert Bevin <gbevin@...> wrote:

> Hi David,
>
> it might be a good idea to add this to the wiki and attach the files.
> If you want, I can open up a Subversion repository for you to put the
> source code in.
>
> Best regards,
>
> Geert
>
> On 08 Apr 2006, at 06:07, David Medinets wrote:
>
> > I like the Fluent API style of setting values (ie, setters returning a
> > value to allow chaining). And I like Spring. Putting the two together
> > seems like a good idea.
> >
> > To this end, I now have a customized version of
> > org.springframework.beans.BeanWrapperImpl.java and
> > java.beans.PropertyDescriptor.java which allows me to use the
> > following setter and *still* configure the bean using Spring.
> >
> >     public Person setName(String _name) {
> >         this.name = _name;
> >         return this;
> >     }
> >
> > If anyone is interested in this work, I'd be happy to share the files.
> > And if a few people are serious about usage, I'd see if I could avoid
> > changing PropertyDescriptor.java since it is an official part of Java
> > (ie, part of rt.jar).
> >
> > -david
> > _______________________________________________
> > Rife-devel mailing list
> > Rife-devel@...
> > http://lists.uwyn.com/mailman/listinfo/rife-devel
> >
>
> --
> Geert Bevin             Uwyn bvba               GTalk: gbevin@...
> "Use what you need"     Avenue de Scailmont 34  Skype: gbevin
> http://www.uwyn.com     7170 Manage, Belgium      AIM: geertbevin
> gbevin at uwyn dot com  Tel: [phone]   Mobile: [phone]
>
> PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
> Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net
>
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>

_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

[Raoul Pierre]

Geert,

1- I have commited changes to rife-i18n

2- May I suggest to add a new RifeConfig.Tool parameter,
L10N_DEFAULT_RESOURCEBUNDLE_LIST, to get a list of  default basenames.

The L10N_DEFAULT_RESOURCEBUNDLE parmeter will be kept and if present,
then added with highest priority in the above list.

Regards

Pierre


_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

[Geert Bevin]

Hi David,

I briefly read over the code that you posted there.

While it should definitely work, it misses an important part of the  
JDK Introspector class. Th is class caches all the introspections for  
subsequent executions. This makes bean-based reflection very fast.  
You version however scans all the methods in the bean for every  
property obtained, every time. I can see this as being a major  
performance hog.

Best regards,

Geert

On 08 Apr 2006, at 23:08, David Medinets wrote:

> I have refined my change to just a single file as detailed in
>
> http://opensource.atlassian.com/projects/spring/browse/SPR-1871
>
> I don't know which page on the RIFE wiki should be updated to reflect
> this issue.
>
> -david
>
> On 4/8/06, Geert Bevin <gbevin@...> wrote:
>> Hi David,
>>
>> it might be a good idea to add this to the wiki and attach the files.
>> If you want, I can open up a Subversion repository for you to put the
>> source code in.
>>
>> Best regards,
>>
>> Geert
>>
>> On 08 Apr 2006, at 06:07, David Medinets wrote:
>>
>>> I like the Fluent API style of setting values (ie, setters  
>>> returning a
>>> value to allow chaining). And I like Spring. Putting the two  
>>> together
>>> seems like a good idea.
>>>
>>> To this end, I now have a customized version of
>>> org.springframework.beans.BeanWrapperImpl.java and
>>> java.beans.PropertyDescriptor.java which allows me to use the
>>> following setter and *still* configure the bean using Spring.
>>>
>>>     public Person setName(String _name) {
>>>         this.name = _name;
>>>         return this;
>>>     }
>>>
>>> If anyone is interested in this work, I'd be happy to share the  
>>> files.
>>> And if a few people are serious about usage, I'd see if I could  
>>> avoid
>>> changing PropertyDescriptor.java since it is an official part of  
>>> Java
>>> (ie, part of rt.jar).
>>>
>>> -david
>>> _______________________________________________
>>> Rife-devel mailing list
>>> Rife-devel@...
>>> http://lists.uwyn.com/mailman/listinfo/rife-devel
>>>
>>
>> --
>> Geert Bevin             Uwyn bvba               GTalk:  
>> gbevin@...
>> "Use what you need"     Avenue de Scailmont 34  Skype: gbevin
>> http://www.uwyn.com     7170 Manage, Belgium      AIM: geertbevin
>> gbevin at uwyn dot com  Tel: [phone]   Mobile: [phone]  
>> 599
>>
>> PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
>> Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net
>>
>>
>> _______________________________________________
>> Rife-devel mailing list
>> Rife-devel@...
>> http://lists.uwyn.com/mailman/listinfo/rife-devel
>>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>

--
Geert Bevin             Uwyn bvba               GTalk: gbevin@...
"Use what you need"     Avenue de Scailmont 34  Skype: gbevin
http://www.uwyn.com     7170 Manage, Belgium      AIM: geertbevin
gbevin at uwyn dot com  Tel: [phone]   Mobile: [phone]

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net


_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

[Geert Bevin]

Hi Frederic,

> Here only plain setters on beans are called.
>
> I'll investigate more on this, but I'd like to know what you think?

I can see your point. I'm not a Spring user myself, but having a pure  
JavaBeans API towards site-building looks like it would indeed be  
better suited for Spring.

Best regards,

Geert

--
Geert Bevin             Uwyn bvba               GTalk: gbevin@...
"Use what you need"     Avenue de Scailmont 34  Skype: gbevin
http://www.uwyn.com     7170 Manage, Belgium      AIM: geertbevin
gbevin at uwyn dot com  Tel: [phone]   Mobile: [phone]

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net


_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

[Geert Bevin]

Hi Pierre,

I don't have time the coming days to look at it in detail, but at a  
quick glance it looks nice. I'll give more feedback or merge it into  
the main repository soon.

Thanks for your contributions!

Best regards,

Geert

On 09 Apr 2006, at 22:04, Raoul Pierre wrote:

> Geert,
>
> 1- I have commited changes to rife-i18n
>
> 2- May I suggest to add a new RifeConfig.Tool parameter,  
> L10N_DEFAULT_RESOURCEBUNDLE_LIST, to get a list of  default basenames.
>
> The L10N_DEFAULT_RESOURCEBUNDLE parmeter will be kept and if  
> present, then added with highest priority in the above list.
>
> Regards
>
> Pierre
>
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>

--
Geert Bevin             Uwyn bvba               GTalk: gbevin@...
"Use what you need"     Avenue de Scailmont 34  Skype: gbevin
http://www.uwyn.com     7170 Manage, Belgium      AIM: geertbevin
gbevin at uwyn dot com  Tel: [phone]   Mobile: [phone]

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net


_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

[David Medinets]

One last note on this topic, perhaps. It is possible to create a
BeanInfo class to tell the Reflection api about your Fuent-style
setters. An example can be found at
http://affy.blogspot.com/2006/04/spring-fluent-apis-and-beaninfo.html.

On 4/10/06, Geert Bevin <gbevin@...> wrote:
> I can see your point. I'm not a Spring user myself, but having a pure
> JavaBeans API towards site-building looks like it would indeed be
> better suited for Spring.
_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

[Raoul Pierre]

Geert,

Unless you tell me otherwise, I have no more changes to commit to
rife-i18n. At least at the moment ;-)

Other point : may I suggest to add a new RifeConfig.Tool parameter,
L10N_DEFAULT_RESOURCEBUNDLE_LIST, to get a list of  default basenames.

The L10N_DEFAULT_RESOURCEBUNDLE parmeter will be kept and if present,
then added with highest priority in the above list.

Regards

Pierre


_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

[Geert Bevin]

Hi Pierre,

> Unless you tell me otherwise, I have no more changes to commit to  
> rife-i18n. At least at the moment ;-)

Sadly I haven't been able to read over the current state yet. I hope  
to do so next week.

> Other point : may I suggest to add a new RifeConfig.Tool parameter,  
> L10N_DEFAULT_RESOURCEBUNDLE_LIST, to get a list of  default basenames.
>
> The L10N_DEFAULT_RESOURCEBUNDLE parmeter will be kept and if  
> present, then added with highest priority in the above list.

Sure, but I'd name it L10N_DEFAULT_RESOURCEBUNDLES.

Best regards,

Geert

--
Geert Bevin             Uwyn bvba               GTalk: gbevin@...
"Use what you need"     Avenue de Scailmont 34  Skype: gbevin
http://www.uwyn.com     7170 Manage, Belgium      AIM: geertbevin
gbevin at uwyn dot com  Tel: [phone]   Mobile: [phone]

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net


_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel