You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Musachy Barroso <mu...@gmail.com> on 2008/12/10 15:44:43 UTC
xwork ConfigurationProvider
Is there anyway to register a new ConfigurationProvider? I thought
that just defining a bean with that type, it would get picked by the
framework and registered. It seems like ConfigurationProviders get
added to the ConfigurationManager "by hand" by Dispatcher. I want to
watch class files from the convention plugin, and reload the
configuration automatically when they change, but I can't do this,
without registering a ConfigurationProvider.
regards
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: xwork ConfigurationProvider
Posted by Blake Byrnes <bl...@gmail.com>.
sorry, meant "the configuration kept by the configuration manager"
On Mon, Dec 22, 2008 at 10:43 AM, Blake Byrnes <bl...@gmail.com>wrote:
> Well, the problem was all the actionPackage configs are stored in the
> configuration manager. In order to "overwrite" the config, i needed to take
> out checks in several levels that prevent duplicate configs from being
> inserted. It was just turning into too much code to do in Javassist, since
> it doesn't belong in the deploye code. You're right though, just adding the
> method to code behind would have been a lot easier :) I'll probably go that
> route instead.
>
>
> On Mon, Dec 22, 2008 at 10:37 AM, Musachy Barroso <mu...@gmail.com>wrote:
>
>> yes, you are right on that, once a change is detected, the whole
>> config is thrown away and reloaded. It wouldn't be too hard to change
>> it, to just reload the package manager that needs a reload.
>>
>> musachy
>>
>> On Mon, Dec 22, 2008 at 10:27 AM, Blake Byrnes <bl...@gmail.com>
>> wrote:
>> > Javarebel actually provides all the JVM reloading tools to you. It's a
>> > pretty neat framework that goes a lot further than hotswapping in the
>> JVM.
>> > The problem I was having was actually that CodeBehind doesn't provide
>> > methods to overwrite the configs for a single changed action. It only
>> > allows the full configuration reload. It doesn't look like Convention
>> has
>> > that either, from what I can tell.
>> >
>> > Ideally, I'd like to be able to code like on Rails, where changes happen
>> > immediately. In JavaRebel, right now, I've got Spring migrating
>> individual
>> > bean/dependency changes, java code reloading, and Struts doing a full
>> > configuration reload. That works pretty well, I was just trying to get
>> rid
>> > of the 4 seconds it takes to rebuild all of struts configs.
>> >
>> > BTW - the JavaRebel plugin uses an OGNL cache clearer. You need that or
>> > added variables to your actions won't get recognized in the view anyway
>> > (sort of defeating the purpose of configuration reloads for java).
>> >
>> > On Sun, Dec 21, 2008 at 1:33 PM, Musachy Barroso <mu...@gmail.com>
>> wrote:
>> >
>> >> I committed my changes, rv#728469. To enable auto reloading set:
>> >>
>> >> <constant name="struts.devMode" value="true"/>
>> >> <constant name="struts.convention.classes.reload" value="true" />
>> >>
>> >> @Blake: take a look at the changes, I think you might be able to do
>> >> the same thing with CodeBehind, also the ClassLoader classes that I
>> >> took from JCI are self contained (after a few mods), so you can lift
>> >> them also.
>> >>
>> >> musachy
>> >>
>> >> On Sun, Dec 21, 2008 at 11:42 AM, Blake Byrnes <bl...@gmail.com>
>> >> wrote:
>> >> > Cool stuff. I've been playing with the Struts 2 javarebel plugin to
>> try
>> >> to
>> >> > get it to load individual configuration changes using codebehind.
>> It's
>> >> > nearly impossible to weave into the current setup, so you have to
>> just
>> >> > reload the whole configuration.
>> >> > The framework will load anything registered as a PackageProvider, but
>> I
>> >> > couldn't get it to load Configuration Providers.
>> >> >
>> >> > On Sun, Dec 21, 2008 at 11:34 AM, Musachy Barroso <musachy@gmail.com
>> >
>> >> wrote:
>> >> >
>> >> >> just for reference, the only way I found to register a
>> >> >> ConfigurationProvider in a plugin was registering a Dispatcher
>> >> >> Listener, and then adding the ConfigurationProvider to the
>> >> >> Configuration manager instace in the dispatcher, not very elegant,
>> but
>> >> >> that's all I got. As a side note, I used this plus a ClassLoader
>> that
>> >> >> I borrowed from Apache JCI, and now the convention plugin will have
>> a
>> >> >> setting:
>> >> >>
>> >> >> struts.convention.classes.reload
>> >> >>
>> >> >> which, when set to true, will reload the configuration when a class
>> >> >> that has actions change. Like xwork does with the xmls, so the
>> >> >> container doesn't need to be restarted when in devMode.
>> >> >>
>> >> >> musachy
>> >> >>
>> >> >> On Wed, Dec 10, 2008 at 9:44 AM, Musachy Barroso <musachy@gmail.com
>> >
>> >> >> wrote:
>> >> >> > Is there anyway to register a new ConfigurationProvider? I thought
>> >> >> > that just defining a bean with that type, it would get picked by
>> the
>> >> >> > framework and registered. It seems like ConfigurationProviders get
>> >> >> > added to the ConfigurationManager "by hand" by Dispatcher. I want
>> to
>> >> >> > watch class files from the convention plugin, and reload the
>> >> >> > configuration automatically when they change, but I can't do this,
>> >> >> > without registering a ConfigurationProvider.
>> >> >> >
>> >> >> > regards
>> >> >> > musachy
>> >> >> > --
>> >> >> > "Hey you! Would you help me to carry the stone?" Pink Floyd
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
Re: xwork ConfigurationProvider
Posted by Musachy Barroso <mu...@gmail.com>.
if you are trying to reload just the specific configuration that
changed, that 's a real challenge. The changes to reload just a
specific PackageProvider would go in DefaultConfiguration. Instead of
clearing the whole packageContexts map, we would need to just remove
the one that needs reloading, and ask the package provider to reload.
Either way, reloading the whole config is so fast that I am not
terrible motivated to do it :)
On Mon, Dec 22, 2008 at 10:43 AM, Blake Byrnes <bl...@gmail.com> wrote:
> Well, the problem was all the actionPackage configs are stored in the
> configuration manager. In order to "overwrite" the config, i needed to take
> out checks in several levels that prevent duplicate configs from being
> inserted. It was just turning into too much code to do in Javassist, since
> it doesn't belong in the deploye code. You're right though, just adding the
> method to code behind would have been a lot easier :) I'll probably go that
> route instead.
>
> On Mon, Dec 22, 2008 at 10:37 AM, Musachy Barroso <mu...@gmail.com> wrote:
>
>> yes, you are right on that, once a change is detected, the whole
>> config is thrown away and reloaded. It wouldn't be too hard to change
>> it, to just reload the package manager that needs a reload.
>>
>> musachy
>>
>> On Mon, Dec 22, 2008 at 10:27 AM, Blake Byrnes <bl...@gmail.com>
>> wrote:
>> > Javarebel actually provides all the JVM reloading tools to you. It's a
>> > pretty neat framework that goes a lot further than hotswapping in the
>> JVM.
>> > The problem I was having was actually that CodeBehind doesn't provide
>> > methods to overwrite the configs for a single changed action. It only
>> > allows the full configuration reload. It doesn't look like Convention
>> has
>> > that either, from what I can tell.
>> >
>> > Ideally, I'd like to be able to code like on Rails, where changes happen
>> > immediately. In JavaRebel, right now, I've got Spring migrating
>> individual
>> > bean/dependency changes, java code reloading, and Struts doing a full
>> > configuration reload. That works pretty well, I was just trying to get
>> rid
>> > of the 4 seconds it takes to rebuild all of struts configs.
>> >
>> > BTW - the JavaRebel plugin uses an OGNL cache clearer. You need that or
>> > added variables to your actions won't get recognized in the view anyway
>> > (sort of defeating the purpose of configuration reloads for java).
>> >
>> > On Sun, Dec 21, 2008 at 1:33 PM, Musachy Barroso <mu...@gmail.com>
>> wrote:
>> >
>> >> I committed my changes, rv#728469. To enable auto reloading set:
>> >>
>> >> <constant name="struts.devMode" value="true"/>
>> >> <constant name="struts.convention.classes.reload" value="true" />
>> >>
>> >> @Blake: take a look at the changes, I think you might be able to do
>> >> the same thing with CodeBehind, also the ClassLoader classes that I
>> >> took from JCI are self contained (after a few mods), so you can lift
>> >> them also.
>> >>
>> >> musachy
>> >>
>> >> On Sun, Dec 21, 2008 at 11:42 AM, Blake Byrnes <bl...@gmail.com>
>> >> wrote:
>> >> > Cool stuff. I've been playing with the Struts 2 javarebel plugin to
>> try
>> >> to
>> >> > get it to load individual configuration changes using codebehind.
>> It's
>> >> > nearly impossible to weave into the current setup, so you have to just
>> >> > reload the whole configuration.
>> >> > The framework will load anything registered as a PackageProvider, but
>> I
>> >> > couldn't get it to load Configuration Providers.
>> >> >
>> >> > On Sun, Dec 21, 2008 at 11:34 AM, Musachy Barroso <mu...@gmail.com>
>> >> wrote:
>> >> >
>> >> >> just for reference, the only way I found to register a
>> >> >> ConfigurationProvider in a plugin was registering a Dispatcher
>> >> >> Listener, and then adding the ConfigurationProvider to the
>> >> >> Configuration manager instace in the dispatcher, not very elegant,
>> but
>> >> >> that's all I got. As a side note, I used this plus a ClassLoader that
>> >> >> I borrowed from Apache JCI, and now the convention plugin will have a
>> >> >> setting:
>> >> >>
>> >> >> struts.convention.classes.reload
>> >> >>
>> >> >> which, when set to true, will reload the configuration when a class
>> >> >> that has actions change. Like xwork does with the xmls, so the
>> >> >> container doesn't need to be restarted when in devMode.
>> >> >>
>> >> >> musachy
>> >> >>
>> >> >> On Wed, Dec 10, 2008 at 9:44 AM, Musachy Barroso <mu...@gmail.com>
>> >> >> wrote:
>> >> >> > Is there anyway to register a new ConfigurationProvider? I thought
>> >> >> > that just defining a bean with that type, it would get picked by
>> the
>> >> >> > framework and registered. It seems like ConfigurationProviders get
>> >> >> > added to the ConfigurationManager "by hand" by Dispatcher. I want
>> to
>> >> >> > watch class files from the convention plugin, and reload the
>> >> >> > configuration automatically when they change, but I can't do this,
>> >> >> > without registering a ConfigurationProvider.
>> >> >> >
>> >> >> > regards
>> >> >> > musachy
>> >> >> > --
>> >> >> > "Hey you! Would you help me to carry the stone?" Pink Floyd
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: xwork ConfigurationProvider
Posted by Blake Byrnes <bl...@gmail.com>.
Well, the problem was all the actionPackage configs are stored in the
configuration manager. In order to "overwrite" the config, i needed to take
out checks in several levels that prevent duplicate configs from being
inserted. It was just turning into too much code to do in Javassist, since
it doesn't belong in the deploye code. You're right though, just adding the
method to code behind would have been a lot easier :) I'll probably go that
route instead.
On Mon, Dec 22, 2008 at 10:37 AM, Musachy Barroso <mu...@gmail.com> wrote:
> yes, you are right on that, once a change is detected, the whole
> config is thrown away and reloaded. It wouldn't be too hard to change
> it, to just reload the package manager that needs a reload.
>
> musachy
>
> On Mon, Dec 22, 2008 at 10:27 AM, Blake Byrnes <bl...@gmail.com>
> wrote:
> > Javarebel actually provides all the JVM reloading tools to you. It's a
> > pretty neat framework that goes a lot further than hotswapping in the
> JVM.
> > The problem I was having was actually that CodeBehind doesn't provide
> > methods to overwrite the configs for a single changed action. It only
> > allows the full configuration reload. It doesn't look like Convention
> has
> > that either, from what I can tell.
> >
> > Ideally, I'd like to be able to code like on Rails, where changes happen
> > immediately. In JavaRebel, right now, I've got Spring migrating
> individual
> > bean/dependency changes, java code reloading, and Struts doing a full
> > configuration reload. That works pretty well, I was just trying to get
> rid
> > of the 4 seconds it takes to rebuild all of struts configs.
> >
> > BTW - the JavaRebel plugin uses an OGNL cache clearer. You need that or
> > added variables to your actions won't get recognized in the view anyway
> > (sort of defeating the purpose of configuration reloads for java).
> >
> > On Sun, Dec 21, 2008 at 1:33 PM, Musachy Barroso <mu...@gmail.com>
> wrote:
> >
> >> I committed my changes, rv#728469. To enable auto reloading set:
> >>
> >> <constant name="struts.devMode" value="true"/>
> >> <constant name="struts.convention.classes.reload" value="true" />
> >>
> >> @Blake: take a look at the changes, I think you might be able to do
> >> the same thing with CodeBehind, also the ClassLoader classes that I
> >> took from JCI are self contained (after a few mods), so you can lift
> >> them also.
> >>
> >> musachy
> >>
> >> On Sun, Dec 21, 2008 at 11:42 AM, Blake Byrnes <bl...@gmail.com>
> >> wrote:
> >> > Cool stuff. I've been playing with the Struts 2 javarebel plugin to
> try
> >> to
> >> > get it to load individual configuration changes using codebehind.
> It's
> >> > nearly impossible to weave into the current setup, so you have to just
> >> > reload the whole configuration.
> >> > The framework will load anything registered as a PackageProvider, but
> I
> >> > couldn't get it to load Configuration Providers.
> >> >
> >> > On Sun, Dec 21, 2008 at 11:34 AM, Musachy Barroso <mu...@gmail.com>
> >> wrote:
> >> >
> >> >> just for reference, the only way I found to register a
> >> >> ConfigurationProvider in a plugin was registering a Dispatcher
> >> >> Listener, and then adding the ConfigurationProvider to the
> >> >> Configuration manager instace in the dispatcher, not very elegant,
> but
> >> >> that's all I got. As a side note, I used this plus a ClassLoader that
> >> >> I borrowed from Apache JCI, and now the convention plugin will have a
> >> >> setting:
> >> >>
> >> >> struts.convention.classes.reload
> >> >>
> >> >> which, when set to true, will reload the configuration when a class
> >> >> that has actions change. Like xwork does with the xmls, so the
> >> >> container doesn't need to be restarted when in devMode.
> >> >>
> >> >> musachy
> >> >>
> >> >> On Wed, Dec 10, 2008 at 9:44 AM, Musachy Barroso <mu...@gmail.com>
> >> >> wrote:
> >> >> > Is there anyway to register a new ConfigurationProvider? I thought
> >> >> > that just defining a bean with that type, it would get picked by
> the
> >> >> > framework and registered. It seems like ConfigurationProviders get
> >> >> > added to the ConfigurationManager "by hand" by Dispatcher. I want
> to
> >> >> > watch class files from the convention plugin, and reload the
> >> >> > configuration automatically when they change, but I can't do this,
> >> >> > without registering a ConfigurationProvider.
> >> >> >
> >> >> > regards
> >> >> > musachy
> >> >> > --
> >> >> > "Hey you! Would you help me to carry the stone?" Pink Floyd
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> For additional commands, e-mail: dev-help@struts.apache.org
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >> --
> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: xwork ConfigurationProvider
Posted by Musachy Barroso <mu...@gmail.com>.
yes, you are right on that, once a change is detected, the whole
config is thrown away and reloaded. It wouldn't be too hard to change
it, to just reload the package manager that needs a reload.
musachy
On Mon, Dec 22, 2008 at 10:27 AM, Blake Byrnes <bl...@gmail.com> wrote:
> Javarebel actually provides all the JVM reloading tools to you. It's a
> pretty neat framework that goes a lot further than hotswapping in the JVM.
> The problem I was having was actually that CodeBehind doesn't provide
> methods to overwrite the configs for a single changed action. It only
> allows the full configuration reload. It doesn't look like Convention has
> that either, from what I can tell.
>
> Ideally, I'd like to be able to code like on Rails, where changes happen
> immediately. In JavaRebel, right now, I've got Spring migrating individual
> bean/dependency changes, java code reloading, and Struts doing a full
> configuration reload. That works pretty well, I was just trying to get rid
> of the 4 seconds it takes to rebuild all of struts configs.
>
> BTW - the JavaRebel plugin uses an OGNL cache clearer. You need that or
> added variables to your actions won't get recognized in the view anyway
> (sort of defeating the purpose of configuration reloads for java).
>
> On Sun, Dec 21, 2008 at 1:33 PM, Musachy Barroso <mu...@gmail.com> wrote:
>
>> I committed my changes, rv#728469. To enable auto reloading set:
>>
>> <constant name="struts.devMode" value="true"/>
>> <constant name="struts.convention.classes.reload" value="true" />
>>
>> @Blake: take a look at the changes, I think you might be able to do
>> the same thing with CodeBehind, also the ClassLoader classes that I
>> took from JCI are self contained (after a few mods), so you can lift
>> them also.
>>
>> musachy
>>
>> On Sun, Dec 21, 2008 at 11:42 AM, Blake Byrnes <bl...@gmail.com>
>> wrote:
>> > Cool stuff. I've been playing with the Struts 2 javarebel plugin to try
>> to
>> > get it to load individual configuration changes using codebehind. It's
>> > nearly impossible to weave into the current setup, so you have to just
>> > reload the whole configuration.
>> > The framework will load anything registered as a PackageProvider, but I
>> > couldn't get it to load Configuration Providers.
>> >
>> > On Sun, Dec 21, 2008 at 11:34 AM, Musachy Barroso <mu...@gmail.com>
>> wrote:
>> >
>> >> just for reference, the only way I found to register a
>> >> ConfigurationProvider in a plugin was registering a Dispatcher
>> >> Listener, and then adding the ConfigurationProvider to the
>> >> Configuration manager instace in the dispatcher, not very elegant, but
>> >> that's all I got. As a side note, I used this plus a ClassLoader that
>> >> I borrowed from Apache JCI, and now the convention plugin will have a
>> >> setting:
>> >>
>> >> struts.convention.classes.reload
>> >>
>> >> which, when set to true, will reload the configuration when a class
>> >> that has actions change. Like xwork does with the xmls, so the
>> >> container doesn't need to be restarted when in devMode.
>> >>
>> >> musachy
>> >>
>> >> On Wed, Dec 10, 2008 at 9:44 AM, Musachy Barroso <mu...@gmail.com>
>> >> wrote:
>> >> > Is there anyway to register a new ConfigurationProvider? I thought
>> >> > that just defining a bean with that type, it would get picked by the
>> >> > framework and registered. It seems like ConfigurationProviders get
>> >> > added to the ConfigurationManager "by hand" by Dispatcher. I want to
>> >> > watch class files from the convention plugin, and reload the
>> >> > configuration automatically when they change, but I can't do this,
>> >> > without registering a ConfigurationProvider.
>> >> >
>> >> > regards
>> >> > musachy
>> >> > --
>> >> > "Hey you! Would you help me to carry the stone?" Pink Floyd
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: xwork ConfigurationProvider
Posted by Blake Byrnes <bl...@gmail.com>.
Javarebel actually provides all the JVM reloading tools to you. It's a
pretty neat framework that goes a lot further than hotswapping in the JVM.
The problem I was having was actually that CodeBehind doesn't provide
methods to overwrite the configs for a single changed action. It only
allows the full configuration reload. It doesn't look like Convention has
that either, from what I can tell.
Ideally, I'd like to be able to code like on Rails, where changes happen
immediately. In JavaRebel, right now, I've got Spring migrating individual
bean/dependency changes, java code reloading, and Struts doing a full
configuration reload. That works pretty well, I was just trying to get rid
of the 4 seconds it takes to rebuild all of struts configs.
BTW - the JavaRebel plugin uses an OGNL cache clearer. You need that or
added variables to your actions won't get recognized in the view anyway
(sort of defeating the purpose of configuration reloads for java).
On Sun, Dec 21, 2008 at 1:33 PM, Musachy Barroso <mu...@gmail.com> wrote:
> I committed my changes, rv#728469. To enable auto reloading set:
>
> <constant name="struts.devMode" value="true"/>
> <constant name="struts.convention.classes.reload" value="true" />
>
> @Blake: take a look at the changes, I think you might be able to do
> the same thing with CodeBehind, also the ClassLoader classes that I
> took from JCI are self contained (after a few mods), so you can lift
> them also.
>
> musachy
>
> On Sun, Dec 21, 2008 at 11:42 AM, Blake Byrnes <bl...@gmail.com>
> wrote:
> > Cool stuff. I've been playing with the Struts 2 javarebel plugin to try
> to
> > get it to load individual configuration changes using codebehind. It's
> > nearly impossible to weave into the current setup, so you have to just
> > reload the whole configuration.
> > The framework will load anything registered as a PackageProvider, but I
> > couldn't get it to load Configuration Providers.
> >
> > On Sun, Dec 21, 2008 at 11:34 AM, Musachy Barroso <mu...@gmail.com>
> wrote:
> >
> >> just for reference, the only way I found to register a
> >> ConfigurationProvider in a plugin was registering a Dispatcher
> >> Listener, and then adding the ConfigurationProvider to the
> >> Configuration manager instace in the dispatcher, not very elegant, but
> >> that's all I got. As a side note, I used this plus a ClassLoader that
> >> I borrowed from Apache JCI, and now the convention plugin will have a
> >> setting:
> >>
> >> struts.convention.classes.reload
> >>
> >> which, when set to true, will reload the configuration when a class
> >> that has actions change. Like xwork does with the xmls, so the
> >> container doesn't need to be restarted when in devMode.
> >>
> >> musachy
> >>
> >> On Wed, Dec 10, 2008 at 9:44 AM, Musachy Barroso <mu...@gmail.com>
> >> wrote:
> >> > Is there anyway to register a new ConfigurationProvider? I thought
> >> > that just defining a bean with that type, it would get picked by the
> >> > framework and registered. It seems like ConfigurationProviders get
> >> > added to the ConfigurationManager "by hand" by Dispatcher. I want to
> >> > watch class files from the convention plugin, and reload the
> >> > configuration automatically when they change, but I can't do this,
> >> > without registering a ConfigurationProvider.
> >> >
> >> > regards
> >> > musachy
> >> > --
> >> > "Hey you! Would you help me to carry the stone?" Pink Floyd
> >> >
> >>
> >>
> >>
> >> --
> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: xwork ConfigurationProvider
Posted by Musachy Barroso <mu...@gmail.com>.
I committed my changes, rv#728469. To enable auto reloading set:
<constant name="struts.devMode" value="true"/>
<constant name="struts.convention.classes.reload" value="true" />
@Blake: take a look at the changes, I think you might be able to do
the same thing with CodeBehind, also the ClassLoader classes that I
took from JCI are self contained (after a few mods), so you can lift
them also.
musachy
On Sun, Dec 21, 2008 at 11:42 AM, Blake Byrnes <bl...@gmail.com> wrote:
> Cool stuff. I've been playing with the Struts 2 javarebel plugin to try to
> get it to load individual configuration changes using codebehind. It's
> nearly impossible to weave into the current setup, so you have to just
> reload the whole configuration.
> The framework will load anything registered as a PackageProvider, but I
> couldn't get it to load Configuration Providers.
>
> On Sun, Dec 21, 2008 at 11:34 AM, Musachy Barroso <mu...@gmail.com> wrote:
>
>> just for reference, the only way I found to register a
>> ConfigurationProvider in a plugin was registering a Dispatcher
>> Listener, and then adding the ConfigurationProvider to the
>> Configuration manager instace in the dispatcher, not very elegant, but
>> that's all I got. As a side note, I used this plus a ClassLoader that
>> I borrowed from Apache JCI, and now the convention plugin will have a
>> setting:
>>
>> struts.convention.classes.reload
>>
>> which, when set to true, will reload the configuration when a class
>> that has actions change. Like xwork does with the xmls, so the
>> container doesn't need to be restarted when in devMode.
>>
>> musachy
>>
>> On Wed, Dec 10, 2008 at 9:44 AM, Musachy Barroso <mu...@gmail.com>
>> wrote:
>> > Is there anyway to register a new ConfigurationProvider? I thought
>> > that just defining a bean with that type, it would get picked by the
>> > framework and registered. It seems like ConfigurationProviders get
>> > added to the ConfigurationManager "by hand" by Dispatcher. I want to
>> > watch class files from the convention plugin, and reload the
>> > configuration automatically when they change, but I can't do this,
>> > without registering a ConfigurationProvider.
>> >
>> > regards
>> > musachy
>> > --
>> > "Hey you! Would you help me to carry the stone?" Pink Floyd
>> >
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: xwork ConfigurationProvider
Posted by Blake Byrnes <bl...@gmail.com>.
Cool stuff. I've been playing with the Struts 2 javarebel plugin to try to
get it to load individual configuration changes using codebehind. It's
nearly impossible to weave into the current setup, so you have to just
reload the whole configuration.
The framework will load anything registered as a PackageProvider, but I
couldn't get it to load Configuration Providers.
On Sun, Dec 21, 2008 at 11:34 AM, Musachy Barroso <mu...@gmail.com> wrote:
> just for reference, the only way I found to register a
> ConfigurationProvider in a plugin was registering a Dispatcher
> Listener, and then adding the ConfigurationProvider to the
> Configuration manager instace in the dispatcher, not very elegant, but
> that's all I got. As a side note, I used this plus a ClassLoader that
> I borrowed from Apache JCI, and now the convention plugin will have a
> setting:
>
> struts.convention.classes.reload
>
> which, when set to true, will reload the configuration when a class
> that has actions change. Like xwork does with the xmls, so the
> container doesn't need to be restarted when in devMode.
>
> musachy
>
> On Wed, Dec 10, 2008 at 9:44 AM, Musachy Barroso <mu...@gmail.com>
> wrote:
> > Is there anyway to register a new ConfigurationProvider? I thought
> > that just defining a bean with that type, it would get picked by the
> > framework and registered. It seems like ConfigurationProviders get
> > added to the ConfigurationManager "by hand" by Dispatcher. I want to
> > watch class files from the convention plugin, and reload the
> > configuration automatically when they change, but I can't do this,
> > without registering a ConfigurationProvider.
> >
> > regards
> > musachy
> > --
> > "Hey you! Would you help me to carry the stone?" Pink Floyd
> >
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: xwork ConfigurationProvider
Posted by Musachy Barroso <mu...@gmail.com>.
just for reference, the only way I found to register a
ConfigurationProvider in a plugin was registering a Dispatcher
Listener, and then adding the ConfigurationProvider to the
Configuration manager instace in the dispatcher, not very elegant, but
that's all I got. As a side note, I used this plus a ClassLoader that
I borrowed from Apache JCI, and now the convention plugin will have a
setting:
struts.convention.classes.reload
which, when set to true, will reload the configuration when a class
that has actions change. Like xwork does with the xmls, so the
container doesn't need to be restarted when in devMode.
musachy
On Wed, Dec 10, 2008 at 9:44 AM, Musachy Barroso <mu...@gmail.com> wrote:
> Is there anyway to register a new ConfigurationProvider? I thought
> that just defining a bean with that type, it would get picked by the
> framework and registered. It seems like ConfigurationProviders get
> added to the ConfigurationManager "by hand" by Dispatcher. I want to
> watch class files from the convention plugin, and reload the
> configuration automatically when they change, but I can't do this,
> without registering a ConfigurationProvider.
>
> regards
> musachy
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org