Eelco Hillenius wrote:
I just committed the changes for the core projects (both the 1.3
branch and 2.0 trunk). See
http://issues.apache.org/jira/browse/WICKET-337
So Eugene, this configuration fragment:
wicket.IClusterable+
true
should suffice for Wicket, right?
That is the idea.
Pre
I just committed the changes for the core projects (both the 1.3
branch and 2.0 trunk). See
http://issues.apache.org/jira/browse/WICKET-337
So Eugene, this configuration fragment:
wicket.IClusterable+
true
should suffice for Wicket, right? Pretty cool if that works! Could you
ping this thre
+1
Eelco Hillenius wrote:
>
> Hi,
>
> I'm making an inventory of classes that should be instrumented by
> Terracotta if you deploy for them. I have a whole bunch of classes and
> interfaces like PopupSettings and IPageable and IPagingLabelProvider
> that are serializable which typically means
I don't see reason to object, +1
-Matej
Eelco Hillenius wrote:
Hi,
I'm making an inventory of classes that should be instrumented by
Terracotta if you deploy for them. I have a whole bunch of classes and
interfaces like PopupSettings and IPageable and IPagingLabelProvider
that are serializable
go for it
-igor
On 2/28/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Hi,
I'm making an inventory of classes that should be instrumented by
Terracotta if you deploy for them. I have a whole bunch of classes and
interfaces like PopupSettings and IPageable and IPagingLabelProvider
that are se
On Feb 28, 2007, at 10:41 PM, Eugene Kuleshov wrote:
Jonas Bonér wrote:
It's not super important, but would the marker interface be a
wicket type or a terracotta type? I could imagine it could be
either actually, just wondering which one you had in mind.
Clusterable extends Serializable?
Jonas Bonér wrote:
It's not super important, but would the marker interface be a wicket
type or a terracotta type? I could imagine it could be either actually,
just wondering which one you had in mind.
Clusterable extends Serializable? Why the coupling?
Finally, (and please excuse my ignoranc
Eelco Hillenius wrote:
Finally, (and please excuse my ignorance of annotations), is it feasible
to introduce an annotation without adding any compile time dependencies?
I don't think so. And as we're targetting Wicket 1.3 for JDK 1.4 and
up, annotations are out of the question for us.
You ca
You can actually use annotations on pre-1.5 JRE's, as long as you
don't mind to have compilation postprocessing pass. I.e. either using
backport175 [1] or commons attributes [2].
True. But in both cases that would mean adding an additional
dependency. Which we are very careful about for Wicket
That all makes sense. I guess the question about extending Serializable
only makes sense if you were proposing that the marker interface was a
Terracotta type (but that is not what you were proposing)
Eelco Hillenius wrote:
It's not super important, but would the marker interface be a wicket
t
that are serializable which typically means in the context of Wicket
that they should be available for serializing.
Duh. I meant 'available for clustering'.
Eelco
On Feb 28, 2007, at 10:26 PM, Eelco Hillenius wrote:
It's not super important, but would the marker interface be a wicket
type or a terracotta type? I could imagine it could be either
actually,
just wondering which one you had in mind.
It would be a Wicket type, as we don't want a compile
On Feb 28, 2007, at 10:20 PM, Tim Eck wrote:
It's not super important, but would the marker interface be a wicket
type or a terracotta type? I could imagine it could be either
actually,
just wondering which one you had in mind.
Clusterable extends Serializable? Why the coupling?
Finally, (
I'm curious if the case would ever come up where someone wants to extend a
Clusterable class but not want the extended class to itself be Clusterable.
Yeah, that's an interesting case. It is not supported by JDK's
serialization but interestingly enough, it is by Terracotta.
Eelco
It's not super important, but would the marker interface be a wicket
type or a terracotta type? I could imagine it could be either actually,
just wondering which one you had in mind.
It would be a Wicket type, as we don't want a compile time dependency
on Terracotta, and it wouldn't introduce a
I'm curious if the case would ever come up where someone wants to extend a
Clusterable class but not want the extended class to itself be Clusterable.
On 2/28/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Hi,
I'm making an inventory of classes that should be instrumented by
Terracotta if you
It's not super important, but would the marker interface be a wicket
type or a terracotta type? I could imagine it could be either actually,
just wondering which one you had in mind.
Clusterable extends Serializable? Why the coupling?
Finally, (and please excuse my ignorance of annotations), i
Any grave objections to this?
And if you don't have objections/ agree your reaction is welcome as
well so that I have an idea that people read it and agree :)
Eelco
It will work when I'll be done with subtype-based matching. But using
marker interface is somehow ugly (even so it is probably the best fit
for the Terracotta support).
Somewhat ugly but as we were already using a marker interface
(Serializable) it doesn't really change much. Introducing a new
I like it.
And if i use terracotta i wouldn't mind such a marker interface anyway.
I don't really find it ugly
Especially if terracotta can use this for subtype matching then it would be
sooo much
easier..
Only one problem that is see.. Still lists or maps that are used by use are
ofcourse not
ma
It will work when I'll be done with subtype-based matching. But using
marker interface is somehow ugly (even so it is probably the best fit
for the Terracotta support).
Java5 annotations could be a nicer option for such purpose, but then
Terracotta don't support matching on annotations yet
Hi,
I'm making an inventory of classes that should be instrumented by
Terracotta if you deploy for them. I have a whole bunch of classes and
interfaces like PopupSettings and IPageable and IPagingLabelProvider
that are serializable which typically means in the context of Wicket
that they should b
22 matches
Mail list logo
