You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2007/11/03 15:58:18 UTC
DISCUSS: Remove Module autoloading
I've been giving this a bit of thought lately.
It seems to me that a likely scenario is one in which an existing
library, such as tapestry-hibernate, doesn't do quite what a user
needs, but contains a lot of useful code that could be resused.
However, autoloading means that just having the JAR on the classpath
wires it up, without giving an option to use the code but not the
services.
In addition, another common case is to forget to add a module's JAR to
the classpath, and then not understand why things are not working.
The solution to both of these problems is to be more explicit about
bringing in modules. The approach I'm moving towards is to add a
@SubModule annotation to the application's module. With that in place,
a missing dependency is a compile time error.
Thoughts?
--
Howard M. Lewis Ship
Partner and Senior Architect at Feature50
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: DISCUSS: Remove Module autoloading
Posted by Massimo Lusetti <ml...@gmail.com>.
On Nov 3, 2007 3:58 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I've been giving this a bit of thought lately.
>
> It seems to me that a likely scenario is one in which an existing
> library, such as tapestry-hibernate, doesn't do quite what a user
> needs, but contains a lot of useful code that could be resused.
> However, autoloading means that just having the JAR on the classpath
> wires it up, without giving an option to use the code but not the
> services.
>
> In addition, another common case is to forget to add a module's JAR to
> the classpath, and then not understand why things are not working.
>
> The solution to both of these problems is to be more explicit about
> bringing in modules. The approach I'm moving towards is to add a
> @SubModule annotation to the application's module. With that in place,
> a missing dependency is a compile time error.
>
> Thoughts?
Personally the first reason why I've chosen HiveMind first then T5 IoC
was/is the presence of this feature. It's incredibly amazing how easy
it is to switch implementations of add features, just drop the jar, so
i depend on this feature plus it's a distinction from any other
framework.
I can see the point on "use the code without using the services" but
(for me) it's not worth the change. If that is the direction T5 IoC
will take i would like to suggest to make this a user choice with a
default behaviour but not cut it off.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: DISCUSS: Remove Module autoloading
Posted by Howard Lewis Ship <hl...@gmail.com>.
https://issues.apache.org/jira/browse/TAPESTRY-1890
On Nov 8, 2007 6:23 AM, Chris Lewis <ch...@bellsouth.net> wrote:
> I concur. Having a way to selectively filter would be good, but I think
> the default behavior should remain as is (auto loading by default).
>
> chris
>
>
> Ted Steen wrote:
> > It would be nice if there was a way to switch on module autoloading,
> > with annotation or configuration.
> >
> > I say this because our application uses the autoloading to power our
> > plugin-mechanism.
> > And I can imagine that there are others like us, not only using the
> > module autoloading for tapestry-modules.
> >
> > 2007/11/3, lasitha <la...@gmail.com>:
> >
> >> On 11/3/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> >>
> >>> The approach I'm moving towards is to add a @SubModule annotation to the application's module.
> >>>
> >> +1.
> >>
> >> This would also be useful in contexts that need only a subset of my
> >> production modules, such as testing or prototyping. For example i
> >> would like to test my pages via the PageTester without my security
> >> layer (tapestry-acegi) getting in the way. Right now i have to stub
> >> out and alias portions of tapestry-acegi to do so. With @SubModule i
> >> could easily put together just the set of modules needed for different
> >> types of tests.
> >>
> >> Thanks,
> >> lasitha
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >>
> >
> >
> >
>
>
--
Howard M. Lewis Ship
Partner and Senior Architect at Feature50
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: DISCUSS: Remove Module autoloading
Posted by Chris Lewis <ch...@bellsouth.net>.
I concur. Having a way to selectively filter would be good, but I think
the default behavior should remain as is (auto loading by default).
chris
Ted Steen wrote:
> It would be nice if there was a way to switch on module autoloading,
> with annotation or configuration.
>
> I say this because our application uses the autoloading to power our
> plugin-mechanism.
> And I can imagine that there are others like us, not only using the
> module autoloading for tapestry-modules.
>
> 2007/11/3, lasitha <la...@gmail.com>:
>
>> On 11/3/07, Howard Lewis Ship <hl...@gmail.com> wrote:
>>
>>> The approach I'm moving towards is to add a @SubModule annotation to the application's module.
>>>
>> +1.
>>
>> This would also be useful in contexts that need only a subset of my
>> production modules, such as testing or prototyping. For example i
>> would like to test my pages via the PageTester without my security
>> layer (tapestry-acegi) getting in the way. Right now i have to stub
>> out and alias portions of tapestry-acegi to do so. With @SubModule i
>> could easily put together just the set of modules needed for different
>> types of tests.
>>
>> Thanks,
>> lasitha
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>>
>
>
>
Re: DISCUSS: Remove Module autoloading
Posted by Ted Steen <te...@gmail.com>.
It would be nice if there was a way to switch on module autoloading,
with annotation or configuration.
I say this because our application uses the autoloading to power our
plugin-mechanism.
And I can imagine that there are others like us, not only using the
module autoloading for tapestry-modules.
2007/11/3, lasitha <la...@gmail.com>:
> On 11/3/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> > The approach I'm moving towards is to add a @SubModule annotation to the application's module.
>
> +1.
>
> This would also be useful in contexts that need only a subset of my
> production modules, such as testing or prototyping. For example i
> would like to test my pages via the PageTester without my security
> layer (tapestry-acegi) getting in the way. Right now i have to stub
> out and alias portions of tapestry-acegi to do so. With @SubModule i
> could easily put together just the set of modules needed for different
> types of tests.
>
> Thanks,
> lasitha
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
/ted
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: DISCUSS: Remove Module autoloading
Posted by lasitha <la...@gmail.com>.
On 11/3/07, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> The approach I'm moving towards is to add a @SubModule annotation to the application's module.
+1.
This would also be useful in contexts that need only a subset of my
production modules, such as testing or prototyping. For example i
would like to test my pages via the PageTester without my security
layer (tapestry-acegi) getting in the way. Right now i have to stub
out and alias portions of tapestry-acegi to do so. With @SubModule i
could easily put together just the set of modules needed for different
types of tests.
Thanks,
lasitha
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: DISCUSS: Remove Module autoloading
Posted by Davor Hrg <hr...@gmail.com>.
I'm for autoloading, and being able to disable it,...
sth like moduleLocators in hivemind...
While arround the subject...
If I have two modules that have same submodule..
tap-ioc will break, this should just work if we look at
the Submodule as an dependancy.
On Nov 5, 2007 6:15 PM, Filip S. Adamsen <fs...@fsadev.com> wrote:
> +1 to autoloading with finer-grained control.
>
> Robert Zeigler skrev:
> > Howard Lewis Ship wrote:
> >> I've been giving this a bit of thought lately.
> >>
> >> It seems to me that a likely scenario is one in which an existing
> >> library, such as tapestry-hibernate, doesn't do quite what a user
> >> needs, but contains a lot of useful code that could be resused.
> >> However, autoloading means that just having the JAR on the classpath
> >> wires it up, without giving an option to use the code but not the
> >> services.
> >>
> >> In addition, another common case is to forget to add a module's JAR to
> >> the classpath, and then not understand why things are not working.
> >>
> >> The solution to both of these problems is to be more explicit about
> >> bringing in modules. The approach I'm moving towards is to add a
> >> @SubModule annotation to the application's module. With that in place,
> >> a missing dependency is a compile time error.
> >>
> >> Thoughts?
> >>
> >>
> >>
> >
> > I think autoloading has a lot of merits, and would hate to see it ripped
> > out. What I /would/ like to see is finer-grained control over
> > autoloading. For example, a mechanism to specify which modules should
> > /not/ be autoloaded.
> >
> > Robert
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: DISCUSS: Remove Module autoloading
Posted by "Filip S. Adamsen" <fs...@fsadev.com>.
+1 to autoloading with finer-grained control.
Robert Zeigler skrev:
> Howard Lewis Ship wrote:
>> I've been giving this a bit of thought lately.
>>
>> It seems to me that a likely scenario is one in which an existing
>> library, such as tapestry-hibernate, doesn't do quite what a user
>> needs, but contains a lot of useful code that could be resused.
>> However, autoloading means that just having the JAR on the classpath
>> wires it up, without giving an option to use the code but not the
>> services.
>>
>> In addition, another common case is to forget to add a module's JAR to
>> the classpath, and then not understand why things are not working.
>>
>> The solution to both of these problems is to be more explicit about
>> bringing in modules. The approach I'm moving towards is to add a
>> @SubModule annotation to the application's module. With that in place,
>> a missing dependency is a compile time error.
>>
>> Thoughts?
>>
>>
>>
>
> I think autoloading has a lot of merits, and would hate to see it ripped
> out. What I /would/ like to see is finer-grained control over
> autoloading. For example, a mechanism to specify which modules should
> /not/ be autoloaded.
>
> Robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: DISCUSS: Remove Module autoloading
Posted by Nick Westgate <ni...@key-planning.co.jp>.
My initial thoughts too. Looks like a popular consensus so far.
Cheers,
Nick.
Ognen Ivanovski wrote:
>
> On 2007-11-04, at 04:53, Robert Zeigler wrote:
>
>> I think autoloading has a lot of merits, and would hate to see it
>> ripped out. What I /would/ like to see is finer-grained control over
>> autoloading. For example, a mechanism to specify which modules should
>> /not/ be autoloaded.
>
> +1. Just wanted to write this myself.
>
>
> --
> Ognen Ivanovski | ognen.ivanovski@netcetera.com.mk
> phone +389 -2- 30 64 532 | fax +389 -2- 30 79 495
> Netcetera | 1000 Skopje | Macedonia | http://netcetera.com.mk
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: DISCUSS: Remove Module autoloading
Posted by Kristian Marinkovic <kr...@porsche.co.at>.
i've also chosen Hivemind and T5 IoC because of autoloading and
because of contributions/configurations.
finer control is ok for me as long as autoloading is default and as i
don't
have to add a @SubModule annotation referencing a class of another
library introducing more dependencies.
maybe T5 IoC should work on top of OSGi. Along with module handling
(autoload, access control) we could take advantage of OSGis runtime
behaviour. (Eclipse Equinox does support many of the concepts found
in T5 IoC like extension-points and extensions aka. configurations and
features an autoload bundle)
g,
kris
Ognen Ivanovski <og...@netcetera.com.mk>
05.11.2007 09:23
Bitte antworten an
"Tapestry development" <de...@tapestry.apache.org>
An
"Tapestry development" <de...@tapestry.apache.org>
Kopie
Thema
Re: DISCUSS: Remove Module autoloading
On 2007-11-04, at 04:53, Robert Zeigler wrote:
> I think autoloading has a lot of merits, and would hate to see it
> ripped out. What I /would/ like to see is finer-grained control
> over autoloading. For example, a mechanism to specify which
> modules should /not/ be autoloaded.
+1. Just wanted to write this myself.
--
Ognen Ivanovski | ognen.ivanovski@netcetera.com.mk
phone +389 -2- 30 64 532 | fax +389 -2- 30 79 495
Netcetera | 1000 Skopje | Macedonia | http://netcetera.com.mk
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: DISCUSS: Remove Module autoloading
Posted by Ognen Ivanovski <og...@netcetera.com.mk>.
On 2007-11-04, at 04:53, Robert Zeigler wrote:
> I think autoloading has a lot of merits, and would hate to see it
> ripped out. What I /would/ like to see is finer-grained control
> over autoloading. For example, a mechanism to specify which
> modules should /not/ be autoloaded.
+1. Just wanted to write this myself.
--
Ognen Ivanovski | ognen.ivanovski@netcetera.com.mk
phone +389 -2- 30 64 532 | fax +389 -2- 30 79 495
Netcetera | 1000 Skopje | Macedonia | http://netcetera.com.mk
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: DISCUSS: Remove Module autoloading
Posted by Christian Edward Gruber <ch...@gmail.com>.
More than that, I think it's a great way to go, though I did like
someone's suggestion that the addDefaultModules() be altered so you
can do "addModules(String pattern)", and have that definiable in
web.xml. Mui convenient, but I haven't thought through the
difficulties, and also don't know the ioc infrastructure well enough
to know if that's a pain to implement.
Christian.
On 6-Nov-07, at 4:53 PM, Massimo Lusetti wrote:
> On Nov 6, 2007 8:28 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>
>> I think this comes down to whether or not the TapestryFillter (or,
>> really, TapestryAppInitializer) invokes
>> IOCUtilities.addDefaultModules(). If that's turned off (perhaps
>> based
>> on an entry in web.xml), then the AppModule can pick up the slack
>> with
>> explicit SubModule annotations.
>
> So this is a behaviour of tapestry-core not a change in the IoC, by me
> is perfectly acceptable.
>
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: DISCUSS: Remove Module autoloading
Posted by Massimo Lusetti <ml...@gmail.com>.
On Nov 6, 2007 8:28 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I think this comes down to whether or not the TapestryFillter (or,
> really, TapestryAppInitializer) invokes
> IOCUtilities.addDefaultModules(). If that's turned off (perhaps based
> on an entry in web.xml), then the AppModule can pick up the slack with
> explicit SubModule annotations.
So this is a behaviour of tapestry-core not a change in the IoC, by me
is perfectly acceptable.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: DISCUSS: Remove Module autoloading
Posted by Howard Lewis Ship <hl...@gmail.com>.
I think this comes down to whether or not the TapestryFillter (or,
really, TapestryAppInitializer) invokes
IOCUtilities.addDefaultModules(). If that's turned off (perhaps based
on an entry in web.xml), then the AppModule can pick up the slack with
explicit SubModule annotations.
On Nov 5, 2007 3:12 PM, Ben Tomasini <be...@gmail.com> wrote:
> What abound some kind of include / exclude filters like ant? An empty
> set could imply **/*
>
> Ben
>
>
> On Nov 3, 2007 8:53 PM, Robert Zeigler <ro...@scazdl.org> wrote:
> > Howard Lewis Ship wrote:
> > > I've been giving this a bit of thought lately.
> > >
> > > It seems to me that a likely scenario is one in which an existing
> > > library, such as tapestry-hibernate, doesn't do quite what a user
> > > needs, but contains a lot of useful code that could be resused.
> > > However, autoloading means that just having the JAR on the classpath
> > > wires it up, without giving an option to use the code but not the
> > > services.
> > >
> > > In addition, another common case is to forget to add a module's JAR to
> > > the classpath, and then not understand why things are not working.
> > >
> > > The solution to both of these problems is to be more explicit about
> > > bringing in modules. The approach I'm moving towards is to add a
> > > @SubModule annotation to the application's module. With that in place,
> > > a missing dependency is a compile time error.
> > >
> > > Thoughts?
> > >
> > >
> > >
> >
> > I think autoloading has a lot of merits, and would hate to see it ripped
> > out. What I /would/ like to see is finer-grained control over
> > autoloading. For example, a mechanism to specify which modules should
> > /not/ be autoloaded.
> >
> > Robert
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Partner and Senior Architect at Feature50
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: DISCUSS: Remove Module autoloading
Posted by Ben Tomasini <be...@gmail.com>.
What abound some kind of include / exclude filters like ant? An empty
set could imply **/*
Ben
On Nov 3, 2007 8:53 PM, Robert Zeigler <ro...@scazdl.org> wrote:
> Howard Lewis Ship wrote:
> > I've been giving this a bit of thought lately.
> >
> > It seems to me that a likely scenario is one in which an existing
> > library, such as tapestry-hibernate, doesn't do quite what a user
> > needs, but contains a lot of useful code that could be resused.
> > However, autoloading means that just having the JAR on the classpath
> > wires it up, without giving an option to use the code but not the
> > services.
> >
> > In addition, another common case is to forget to add a module's JAR to
> > the classpath, and then not understand why things are not working.
> >
> > The solution to both of these problems is to be more explicit about
> > bringing in modules. The approach I'm moving towards is to add a
> > @SubModule annotation to the application's module. With that in place,
> > a missing dependency is a compile time error.
> >
> > Thoughts?
> >
> >
> >
>
> I think autoloading has a lot of merits, and would hate to see it ripped
> out. What I /would/ like to see is finer-grained control over
> autoloading. For example, a mechanism to specify which modules should
> /not/ be autoloaded.
>
> Robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: DISCUSS: Remove Module autoloading
Posted by Robert Zeigler <ro...@scazdl.org>.
Howard Lewis Ship wrote:
> I've been giving this a bit of thought lately.
>
> It seems to me that a likely scenario is one in which an existing
> library, such as tapestry-hibernate, doesn't do quite what a user
> needs, but contains a lot of useful code that could be resused.
> However, autoloading means that just having the JAR on the classpath
> wires it up, without giving an option to use the code but not the
> services.
>
> In addition, another common case is to forget to add a module's JAR to
> the classpath, and then not understand why things are not working.
>
> The solution to both of these problems is to be more explicit about
> bringing in modules. The approach I'm moving towards is to add a
> @SubModule annotation to the application's module. With that in place,
> a missing dependency is a compile time error.
>
> Thoughts?
>
>
>
I think autoloading has a lot of merits, and would hate to see it ripped
out. What I /would/ like to see is finer-grained control over
autoloading. For example, a mechanism to specify which modules should
/not/ be autoloaded.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org