Re: VOTE: apply issue WICKET-215 to 1.2.x
-1: change the parameter type. +0: add a new method to the class I doubt this is actually something that needs fixing in 1.2.x though. If someone desperately needs it, it is an easy fix in their own application, and therefore I think that adding a new method will also consist an api break. Martijn On 2/18/07, Eelco Hillenius [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/WICKET-215 is really simple to fix, but requires an API break. However, it's current state can't even be used, so I'm sure this won't actually break any existing clients. I'd like to apply this for 1.2.x. Your votes please? Eelco -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: VOTE: apply issue WICKET-215 to 1.2.x
why are we still arguing about this? just deprecate the damn method already and add the variant -igor On 2/18/07, Martijn Dashorst [EMAIL PROTECTED] wrote: If the break is hypothetical, then why not leave it in there, perhaps using @deprecated? If there is just one user depending on it, they will have an api break. IMO no api breaks means *no* api breaks, only when security or stability is at risk we *might* warrant an api break. Martijn On 2/18/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 2/18/07, Martijn Dashorst [EMAIL PROTECTED] wrote: -1: change the parameter type. +0: add a new method to the class I doubt this is actually something that needs fixing in 1.2.x though. If someone desperately needs it, it is an easy fix in their own application, and therefore I think that adding a new method will also consist an api break. How badly it's needed... probably not as there is a workaround possible. However, I don't get why you would be against removing/ changing something that doesn't work *at all* at the moment. Clients cannot even use it, so the 'break' is purely hypothetical. Eelco -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: VOTE: apply issue WICKET-215 to 1.2.x
On 2/18/07, Igor Vaynberg [EMAIL PROTECTED] wrote: why are we still arguing about this? just deprecate the damn method already and add the variant Because that's a lame 'solution'. Deprecate would be ok if the method did actually return normally but just wouldn't work like expected. In this case, you can't even use the method in the first place, so putting deprecated in there doesn't solve a thing for one user in the whole darn world. Eelco
Re: VOTE: apply issue WICKET-215 to 1.2.x
look this is fixed properly in 1.3 and up. we agreed no api breaks in 1.2.x. you can interpret it one way, martijn interprets it another. for him removing a method, usable or not, is an api break. whatever. who cares? 1.2.x is in maintenance mode. we should concentrate on 1.3 instead of wasting energy on discussions like this. my last 2c. -igor On 2/18/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 2/18/07, Igor Vaynberg [EMAIL PROTECTED] wrote: why are we still arguing about this? just deprecate the damn method already and add the variant Because that's a lame 'solution'. Deprecate would be ok if the method did actually return normally but just wouldn't work like expected. In this case, you can't even use the method in the first place, so putting deprecated in there doesn't solve a thing for one user in the whole darn world. Eelco
Re: VOTE: apply issue WICKET-215 to 1.2.x
On 2/18/07, Igor Vaynberg [EMAIL PROTECTED] wrote: look this is fixed properly in 1.3 and up. we agreed no api breaks in 1.2.x. you can interpret it one way, martijn interprets it another. for him removing a method, usable or not, is an api break. whatever. who cares? 1.2.x is in maintenance mode. we should concentrate on 1.3 instead of wasting energy on discussions like this. my last 2c. I care about it in that a user reported it, as he thought could use it but then found out he couldn't. That wasted his time, and the fix for preventing anyone else wasting his or her time over this in the future takes about 5 seconds to apply. Now because of a ridiculous argument that can only have a theoretical implication BUT NEVER a practical one *we* are wasting our time and has my mood spoiled. Eelco
Questions about SecondLevelCacheSessionStore
Hi Wicket devs, Sorry for jumping in on this list since I'm barely a Wicket user (much less a developer), but I wanted to share some thoughts/ questions regarding your work on the SecondLevelCacheSessionStore. 1) If the main purpose is to move sessions out of RAM and onto disk or a database, aren't you largely duplicating functionality already (and probably more appropriately) provided at the container level (e.g. Tomcat's PersistentManager)? I realize that SecondLevelCacheSessionStore moves only part of a session out of memory rather than the whole thing and so, in effect, keeps the literal session size small. But why is it necessarily better to swap a part of every session in and out of RAM vs swapping entire idle sessions out of RAM and back in only when needed (this is PersistentManager's strategy)? It seems like the PersistentManager approach would be more efficient (less disk writes) and should provide similar RAM savings in the long run. 2) Doesn't the SecondLevelCacheSessionStore create another data repository that must be shared or distributed across clustered application servers? I mean, in addition to normal session clustering wouldn't one also have to cluster whatever gets persisted by SecondLevelCacheSessionStore since it stores data that is essentially an extension of the session? 3) I'm afraid that a file based session store (the default implementation, I believe) will actually perform so badly that it won't be useful in the type of high load environment SecondLevelCacheSessionStore is intended to address. In my experience with a fairly high traffic PHP site, file-based session storage is extremely slow and you have to switch to a database-backed solution to handle any kind of serious load (assuming that you can't hold the sessions in RAM, which is basically not an option anyway with PHP). I know a database implementation of SecondLevelCacheSessionStore has been discussed, but I guess what I'm trying to point out is that the default implementation may actually perform and scale worse than no SecondLevelCacheSessionStore at all would. Furthermore, if a database- backed solution works well, why not just let the container store entire sessions in a database and avoid adding a second layer of session storage that must be managed in a cluster? I apologize if these questions/suggestions are ignorant or come across as rude. I certainly don't mean to disparage anyone's efforts in making Wicket more scalable and I don't pretend to be a scalability guru (although I do have a decent amount of experience in this area that I'll be glad to talk about if that's useful). I was just reading through some of your past discussions about SecondLevelCacheSessionStore and I couldn't help but see a few red flags. Thanks, -Ryan
Re: Questions about SecondLevelCacheSessionStore
Hi Wicket devs, Sorry for jumping in on this list since I'm barely a Wicket user (much less a developer), but I wanted to share some thoughts/ questions regarding your work on the SecondLevelCacheSessionStore. That's always very welcome. I'm about to start a discussion on it myself actually; there's been quite some talk about it on IRC, but it is time now for a larger audience and better history (mailing list). Keep in mind that the SecondLevelCacheSessionStore (SLCSS) is still experimental and that not all of Wicket's committers agree just yet that this is the best default nor that it's current implementation is the best. But we have some working code, which is great for discussion. Also keep in mind that we want to support both mechanisms (the 'old' totally RAM based and this new one) and any mechanisms people use for themselves. 1) If the main purpose is to move sessions out of RAM and onto disk or a database, aren't you largely duplicating functionality already (and probably more appropriately) provided at the container level (e.g. Tomcat's PersistentManager)? The idea of having a custom implementation is that we can (potentially at least) optimize it for just Wicket, and have a mechanism available that should work regardless of the app server you are using (and the bugs that might be in there) I realize that SecondLevelCacheSessionStore moves only part of a session out of memory rather than the whole thing and so, in effect, keeps the literal session size small. But why is it necessarily better to swap a part of every session in and out of RAM vs swapping entire idle sessions out of RAM and back in only when needed (this is PersistentManager's strategy)? It seems like the PersistentManager approach would be more efficient (less disk writes) and should provide similar RAM savings in the long run. More efficient when it comes to disk writes, but not when it comes to using RAM. We can clean up RAM quicker and thus need less RAM per session in the short run. And the short run is better for handling peaks. 2) Doesn't the SecondLevelCacheSessionStore create another data repository that must be shared or distributed across clustered application servers? I mean, in addition to normal session clustering wouldn't one also have to cluster whatever gets persisted by SecondLevelCacheSessionStore since it stores data that is essentially an extension of the session? Yeah. This is something that we are still discussing. For starters, it depends on whether you work with session affinity (aka sticky sessions). If that is the case, this approach works fine. However, if you don't and/ or want a backup without having to use a shared network disk, I believe the file based approach isn't great. 3) I'm afraid that a file based session store (the default implementation, I believe) will actually perform so badly that it won't be useful in the type of high load environment SecondLevelCacheSessionStore is intended to address. Sorry for being a smart ass, but the big mistake people always make in matters like these - Wicket developers included - is make assumptions without actually calculating and testing them. And there also isn't a 'bad' approach by default here, as what works well depends entirely on what the traffic looks like. In my experience with a fairly high traffic PHP site, file-based session storage is extremely slow and you have to switch to a database-backed solution to handle any kind of serious load (assuming that you can't hold the sessions in RAM, which is basically not an option anyway with PHP). Maybe. Keep in mind we're writing in a non-blocking low priority background ground thread (or at least, that is the idea) and we'll only be reading from second level storage if the requested resource (page) isn't available in the first level cache. And as we always hold at least the first the current page in memory, and that is the page that is used to resolve requests from forms and non-bookmarkable link components etc, in practice, the second level storage is only accessed for back button requests, for which you may argue that they'll be far less common than normal requests (although even here, if you are serious about your stuff you might want to collect statistics about back button use and configure accordingly when that is possible). I know a database implementation of SecondLevelCacheSessionStore has been discussed, but I guess what I'm trying to point out is that the default implementation may actually perform and scale worse than no SecondLevelCacheSessionStore at all would. Furthermore, if a database- backed solution works well, why not just let the container store entire sessions in a database and avoid adding a second layer of session storage that must be managed in a cluster? If you depend on a cluster being managed by your app server, the old approach might be the best for you anyway. But if you are e.g. using Terracotta - which we plan to use for the day time job I'm working
Re: JMX in Trunk
Could you please open up a JIRA issue for this Johan? You can assign it to me. Eelco On 2/18/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 2/18/07, Johan Edstrom [EMAIL PROTECTED] wrote: Hi, I just ran into an issue with the JMX in trunk, it is now enabled by default. I'm porting an existing webapp, and was interested in the latest Wicket tools. Since this existing resource I rely on already exposes JMX and MBeans I really would like to be able to 'turn off' the JMX implementation in Wicket. Yep, you're right. It's not relevant for 1.3 as it's a separate project there, but for 2.0 we could/ should make it a separate setting or make it a separate project like it is for 1.3 Eelco
Re: JMX in Trunk
Yep, you're right. It's not relevant for 1.3 as it's a separate project there, but for 2.0 we could/ should make it a separate setting or make it a separate project like it is for 1.3 I think my preference would be to keep it in the same project but with a setting (which is off by default). Eelco
Re: JMX in Trunk
Thank you! WICKET-297 On 2/18/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Yep, you're right. It's not relevant for 1.3 as it's a separate project there, but for 2.0 we could/ should make it a separate setting or make it a separate project like it is for 1.3 I think my preference would be to keep it in the same project but with a setting (which is off by default). Eelco
wicket modules
just thinking out loud...
for a long time we have had problems with addons that have their own
application subclass because if you wanted to use more then one addon you
had to bastardize the code of one and add it to the application subclass of
the other. recently i refactored wicket-spring to not have its own
application subclass, but the user still had to install the component
injector - and needs to know how to do that.
i thought it would be great to have modules that users can install that
would take place of the module-specific application subclass. and then i
thought about it some more and realized we already have something like that.
interface wicketmodule extends iinitializer, idestroyer {}
and there you have it, a beginnings of a wicket module. i just refactored
wicket-spring to work like this, it uses an initializer to register the
springcomponnetinjector so now for user there is zero-configuration. drop
the jar onto the classpath and its ready to go. why didnt i do this a long
time ago? :|
now for security stuff we can also do some really cool things. it gets a bit
controversial here but bare with me. what if we let the security strategy
cascade from session-application-modules and instead of returning true or
false it returns pass or veto? the controversial bit is removing security
strategy from a setting and letting session, application, wicketmodule be
able to implement it directly - or implement a locator interface. this way
installing wicket-auth is pretty simple, drop the jar in and create your own
roles. the module takes care of installing the right security strategy, etc.
could be cool, the module interface can be extended to handle other usefull
callbacks, etc.
-igor
Re: [Vote] wicket modules
I like the idea of snap-in modules of some sort, but I don't completely
understand what you're talking about here and I'm not sure I agree with what
all of what I do get.
I'm unsure about auto-installing modules using the classpath. With the
classpath loading, you wind up with a lot of magic going on that you don't
explicitly specify. I find that kind of zero config to be slippery,
sometimes surprising and generally harder to manage than simply requiring a
single line of code in your application constructor that makes it clear to
everyone exactly what is supposed to happen (and when). It is very
straightforward and self-documenting to explicitly state the dependency for
each module you want to use in your app constructor. It's extremely hard to
mistake the intention of something like add(new WhateverModule()). You
don't have to know anything about how Wicket modules might work to figure it
out.
I also think that the current approach of having /a/ security strategy is
quite elegant and straightforward. The mechanism is extensible by explicit
chaining and I think probably better than a fancy one that has locators,
searching or cascading because you end up with magic again. Saying add(new
WebApplicationAuthenticator()) (instead of extending
AuthenticatedWebApplication) lets you to add web application authentication
functionality without having to educate anyone about how it happens.
I think what we should be shooting for is an easy way to use modules in
Wicket that add behavior explicitly in your application constructor. I
think this ought to be some kind of simple and explicit pattern of
composition.
I like the start of what you're thinking here, but let's be careful not to
invent for invention's sake. Wicket would best remain a highly predictable
and simple framework.
igor.vaynberg wrote:
just thinking out loud...
for a long time we have had problems with addons that have their own
application subclass because if you wanted to use more then one addon you
had to bastardize the code of one and add it to the application subclass
of
the other. recently i refactored wicket-spring to not have its own
application subclass, but the user still had to install the component
injector - and needs to know how to do that.
i thought it would be great to have modules that users can install that
would take place of the module-specific application subclass. and then i
thought about it some more and realized we already have something like
that.
interface wicketmodule extends iinitializer, idestroyer {}
and there you have it, a beginnings of a wicket module. i just refactored
wicket-spring to work like this, it uses an initializer to register the
springcomponnetinjector so now for user there is zero-configuration. drop
the jar onto the classpath and its ready to go. why didnt i do this a long
time ago? :|
now for security stuff we can also do some really cool things. it gets a
bit
controversial here but bare with me. what if we let the security strategy
cascade from session-application-modules and instead of returning true
or
false it returns pass or veto? the controversial bit is removing security
strategy from a setting and letting session, application, wicketmodule be
able to implement it directly - or implement a locator interface. this way
installing wicket-auth is pretty simple, drop the jar in and create your
own
roles. the module takes care of installing the right security strategy,
etc.
could be cool, the module interface can be extended to handle other
usefull
callbacks, etc.
-igor
--
View this message in context:
http://www.nabble.com/wicket-modules-tf3250868.html#a9037838
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [Vote] wicket modules
i disagree. having things explicit is very nice when there is a need for you
to know, but what if there isnt?
take wicket-spring module. its only service is to make fields annotated with
@SpringBean injectable. why should the user care that this is done with the
componentinstantiationlistener, or what a componentinstantiationlistener is.
there is also no need to make the user dig in though the docs and figure out
they they need to have
addComponentInstantionListener(new SpringComponentInjector(this));
to them its total garbage they just have to paste in. no one cares what it
is, they only care @SpringBean fields are injected.
so perhaps i should chage zero-configuration to zero-installation.
same for security
if i provide a module that provides a couple of annots like @Admin @User,
etc and a security strategy for them - why make user go through all the
gritty details of installing it. what if they have their own and want to mix
it with the one in the module? they have to do all the wrapping themselves -
it gets messy and the end result is exactly the same as when the module
wouldve installed its own by itself. if we move to veto semantics for return
values of strategies there is no difference how it is mixed in as long as it
is.
i dont know. if there is only one way to install something, why not have it
done automatically?
like i said, just thinking out loud
-igor
On 2/18/07, Jonathan Locke [EMAIL PROTECTED] wrote:
I like the idea of snap-in modules of some sort, but I don't completely
understand what you're talking about here and I'm not sure I agree with
what
all of what I do get.
I'm unsure about auto-installing modules using the classpath. With the
classpath loading, you wind up with a lot of magic going on that you don't
explicitly specify. I find that kind of zero config to be slippery,
sometimes surprising and generally harder to manage than simply requiring
a
single line of code in your application constructor that makes it clear to
everyone exactly what is supposed to happen (and when). It is very
straightforward and self-documenting to explicitly state the dependency
for
each module you want to use in your app constructor. It's extremely hard
to
mistake the intention of something like add(new WhateverModule()). You
don't have to know anything about how Wicket modules might work to figure
it
out.
I also think that the current approach of having /a/ security strategy is
quite elegant and straightforward. The mechanism is extensible by
explicit
chaining and I think probably better than a fancy one that has locators,
searching or cascading because you end up with magic again. Saying
add(new
WebApplicationAuthenticator()) (instead of extending
AuthenticatedWebApplication) lets you to add web application
authentication
functionality without having to educate anyone about how it happens.
I think what we should be shooting for is an easy way to use modules in
Wicket that add behavior explicitly in your application constructor. I
think this ought to be some kind of simple and explicit pattern of
composition.
I like the start of what you're thinking here, but let's be careful not to
invent for invention's sake. Wicket would best remain a highly
predictable
and simple framework.
igor.vaynberg wrote:
just thinking out loud...
for a long time we have had problems with addons that have their own
application subclass because if you wanted to use more then one addon
you
had to bastardize the code of one and add it to the application subclass
of
the other. recently i refactored wicket-spring to not have its own
application subclass, but the user still had to install the component
injector - and needs to know how to do that.
i thought it would be great to have modules that users can install that
would take place of the module-specific application subclass. and then i
thought about it some more and realized we already have something like
that.
interface wicketmodule extends iinitializer, idestroyer {}
and there you have it, a beginnings of a wicket module. i just
refactored
wicket-spring to work like this, it uses an initializer to register the
springcomponnetinjector so now for user there is zero-configuration.
drop
the jar onto the classpath and its ready to go. why didnt i do this a
long
time ago? :|
now for security stuff we can also do some really cool things. it gets a
bit
controversial here but bare with me. what if we let the security
strategy
cascade from session-application-modules and instead of returning true
or
false it returns pass or veto? the controversial bit is removing
security
strategy from a setting and letting session, application, wicketmodule
be
able to implement it directly - or implement a locator interface. this
way
installing wicket-auth is pretty simple, drop the jar in and create your
own
roles. the module takes care of installing the right security strategy,
etc.
could be cool, the module interface can be
Re: [Vote] wicket modules
i guess another thing to consider is that in both of these cases there are
no sideeffects of installing these things. if you dont use the annots
everything is as it was before. so its not like you drop this file in and
all of a sudden things get weird.
-igor
On 2/18/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i disagree. having things explicit is very nice when there is a need for
you to know, but what if there isnt?
take wicket-spring module. its only service is to make fields annotated
with @SpringBean injectable. why should the user care that this is done with
the componentinstantiationlistener, or what a componentinstantiationlistener
is.
there is also no need to make the user dig in though the docs and figure
out they they need to have
addComponentInstantionListener(new SpringComponentInjector(this));
to them its total garbage they just have to paste in. no one cares what it
is, they only care @SpringBean fields are injected.
so perhaps i should chage zero-configuration to zero-installation.
same for security
if i provide a module that provides a couple of annots like @Admin @User,
etc and a security strategy for them - why make user go through all the
gritty details of installing it. what if they have their own and want to mix
it with the one in the module? they have to do all the wrapping themselves -
it gets messy and the end result is exactly the same as when the module
wouldve installed its own by itself. if we move to veto semantics for return
values of strategies there is no difference how it is mixed in as long as it
is.
i dont know. if there is only one way to install something, why not have
it done automatically?
like i said, just thinking out loud
-igor
On 2/18/07, Jonathan Locke [EMAIL PROTECTED] wrote:
I like the idea of snap-in modules of some sort, but I don't completely
understand what you're talking about here and I'm not sure I agree with
what
all of what I do get.
I'm unsure about auto-installing modules using the classpath. With the
classpath loading, you wind up with a lot of magic going on that you
don't
explicitly specify. I find that kind of zero config to be slippery,
sometimes surprising and generally harder to manage than simply
requiring a
single line of code in your application constructor that makes it clear
to
everyone exactly what is supposed to happen (and when). It is very
straightforward and self-documenting to explicitly state the dependency
for
each module you want to use in your app constructor. It's extremely
hard to
mistake the intention of something like add(new
WhateverModule()). You
don't have to know anything about how Wicket modules might work to
figure it
out.
I also think that the current approach of having /a/ security strategy
is
quite elegant and straightforward. The mechanism is extensible by
explicit
chaining and I think probably better than a fancy one that has locators,
searching or cascading because you end up with magic again. Saying
add(new
WebApplicationAuthenticator()) (instead of extending
AuthenticatedWebApplication) lets you to add web application
authentication
functionality without having to educate anyone about how it happens.
I think what we should be shooting for is an easy way to use modules in
Wicket that add behavior explicitly in your application constructor. I
think this ought to be some kind of simple and explicit pattern of
composition.
I like the start of what you're thinking here, but let's be careful not
to
invent for invention's sake. Wicket would best remain a highly
predictable
and simple framework.
igor.vaynberg wrote:
just thinking out loud...
for a long time we have had problems with addons that have their own
application subclass because if you wanted to use more then one addon
you
had to bastardize the code of one and add it to the application
subclass
of
the other. recently i refactored wicket-spring to not have its own
application subclass, but the user still had to install the component
injector - and needs to know how to do that.
i thought it would be great to have modules that users can install
that
would take place of the module-specific application subclass. and then
i
thought about it some more and realized we already have something like
that.
interface wicketmodule extends iinitializer, idestroyer {}
and there you have it, a beginnings of a wicket module. i just
refactored
wicket-spring to work like this, it uses an initializer to register
the
springcomponnetinjector so now for user there is zero-configuration.
drop
the jar onto the classpath and its ready to go. why didnt i do this a
long
time ago? :|
now for security stuff we can also do some really cool things. it gets
a
bit
controversial here but bare with me. what if we let the security
strategy
cascade from session-application-modules and instead of returning
true
or
false it returns pass or veto? the
Re: wicket modules
Hi Igor, Jonathan, Good idea, I have never liked the way I had to inherit from the application base classes. From a users point of view, I agree with Jonathan on the config thing, I'd rather have one line of code somewhere (on a predictable place, e.g. application#init). This also makes it immediately clear when it does not work: you get a classnotfoundexception. When it is implicit you can search for hours before you realize that a jar is missing. Especially when you are talking about annotations. Regards, Erik. Jonathan Locke wrote: I like the idea of snap-in modules of some sort, but I don't completely understand what you're talking about here and I'm not sure I agree with what all of what I do get. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: wicket modules
all these cons are invalid you would also get class not found on the annotations like @SpringBean and a log message tells you what modules have been initialized :) -igor On 2/18/07, Erik van Oosten [EMAIL PROTECTED] wrote: Hi Igor, Jonathan, Good idea, I have never liked the way I had to inherit from the application base classes. From a users point of view, I agree with Jonathan on the config thing, I'd rather have one line of code somewhere (on a predictable place, e.g. application#init). This also makes it immediately clear when it does not work: you get a classnotfoundexception. When it is implicit you can search for hours before you realize that a jar is missing. Especially when you are talking about annotations. Regards, Erik. Jonathan Locke wrote: I like the idea of snap-in modules of some sort, but I don't completely understand what you're talking about here and I'm not sure I agree with what all of what I do get. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: [Vote] wicket modules
unlike jmx this isnt part of core, so if you dont want to activate it dont put it on your classpath. furthermore, like i said, there are no sideffects in activating it. the only downside i can think of is how to configure these things. usually you would do it when installing them, but when they install themselves it gets trickier. in case of wicket-spring there is no configuration -igor On 2/18/07, Eelco Hillenius [EMAIL PROTECTED] wrote: I like the idea. It's very much like the IInitializer idea anyway, and I agree it's funny we didn't actually think of this before. The only catch with auto-discovery/config/whateveryoucallit is - like we can see now with JMX - what do you do when people want it to be not activated. If we can have that as part of the pattern, I'm all for it. Eelco On 2/18/07, Igor Vaynberg [EMAIL PROTECTED] wrote: i disagree. having things explicit is very nice when there is a need for you to know, but what if there isnt? take wicket-spring module. its only service is to make fields annotated with @SpringBean injectable. why should the user care that this is done with the componentinstantiationlistener, or what a componentinstantiationlistener is. there is also no need to make the user dig in though the docs and figure out they they need to have addComponentInstantionListener(new SpringComponentInjector(this)); to them its total garbage they just have to paste in. no one cares what it is, they only care @SpringBean fields are injected. so perhaps i should chage zero-configuration to zero-installation. same for security if i provide a module that provides a couple of annots like @Admin @User, etc and a security strategy for them - why make user go through all the gritty details of installing it. what if they have their own and want to mix it with the one in the module? they have to do all the wrapping themselves - it gets messy and the end result is exactly the same as when the module wouldve installed its own by itself. if we move to veto semantics for return values of strategies there is no difference how it is mixed in as long as it is. i dont know. if there is only one way to install something, why not have it done automatically? like i said, just thinking out loud -igor On 2/18/07, Jonathan Locke [EMAIL PROTECTED] wrote: I like the idea of snap-in modules of some sort, but I don't completely understand what you're talking about here and I'm not sure I agree with what all of what I do get. I'm unsure about auto-installing modules using the classpath. With the classpath loading, you wind up with a lot of magic going on that you don't explicitly specify. I find that kind of zero config to be slippery, sometimes surprising and generally harder to manage than simply requiring a single line of code in your application constructor that makes it clear to everyone exactly what is supposed to happen (and when). It is very straightforward and self-documenting to explicitly state the dependency for each module you want to use in your app constructor. It's extremely hard to mistake the intention of something like add(new WhateverModule()). You don't have to know anything about how Wicket modules might work to figure it out. I also think that the current approach of having /a/ security strategy is quite elegant and straightforward. The mechanism is extensible by explicit chaining and I think probably better than a fancy one that has locators, searching or cascading because you end up with magic again. Saying add(new WebApplicationAuthenticator()) (instead of extending AuthenticatedWebApplication) lets you to add web application authentication functionality without having to educate anyone about how it happens. I think what we should be shooting for is an easy way to use modules in Wicket that add behavior explicitly in your application constructor. I think this ought to be some kind of simple and explicit pattern of composition. I like the start of what you're thinking here, but let's be careful not to invent for invention's sake. Wicket would best remain a highly predictable and simple framework. igor.vaynberg wrote: just thinking out loud... for a long time we have had problems with addons that have their own application subclass because if you wanted to use more then one addon you had to bastardize the code of one and add it to the application subclass of the other. recently i refactored wicket-spring to not have its own application subclass, but the user still had to install the component injector - and needs to know how to do that. i thought it would be great to have modules that users can install that would take place of the module-specific application subclass. and then i thought about it some more and realized we already have something like that. interface wicketmodule extends
