-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.
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,
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
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
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
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
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;
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
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).
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
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
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
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,
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
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
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
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
17 matches
Mail list logo
