On 2/12/07, Alastair Maw (JIRA) [EMAIL PROTECTED] wrote:
We now have a YUI-based datepicker in wicket-datetime, and the old picker
available in Wicket Stuff as wicket-contrib-datepicker, complete with migration
docs noting these in the Migrate 1.3 guide on the wiki. Are we happy to close
this
But it should be tested, if we disable it then it will never be tested...
for a release (beta) we can disable it but i like to keep it enabled in svn.
johan
On 2/12/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I've turned that custom streaming off by default. Until we are
absolutely,
This is fixed.
I didn't overwrite all the read and write methods.
johan
On 2/12/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Not entirely I'm afraid:
2007-02-11 16:25:47,595 ERROR wicket.protocol.http.FilePageStore -
Error in page save thread
java.lang.RuntimeException:
hmm are you sure you test with the latest code?
i just committed some fixes. Can you test with the latest code?
Also look what kind of files are created (what is the filename of a page)
I don't get this at all anymore on my machine. I did get it before i made
the change to a stricter syncing.
in the new wicket object outputstream i can generated exactly the path for
you
and exactly what field goes wrong.
Ofcourse what i also can do is just completely disable the serializeable
test and just do it ;)
johan
On 2/12/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Folks,
In 1.3 we
Following the [1]earlier discussion about line endings, I'd like
to perform the necessary cleanup ASAP. But as this may be a
little intrusive, it would be better if you could check-in or
revert any pending change to minimize the possibility of a
conflict. I'll do that in
I think you should, because it can leave your page in an inconsistent state,
when calling this method while a new version is being created. So it is
better that the user of the framework has no access to this option.
Jan.
--
View this message in context:
hmm i get on my machine a bigger leap.
115 seconds agains 90 seconds.
but i think that the synching gets to much time.
johan
On 2/12/07, Matej Knopp [EMAIL PROTECTED] wrote:
2nd level with byteoutputstream 53906
2nd level with wicketbyteoutputstream 50350
http session store 37714
Johan
Weaver, Scott wrote:
Hi All,
First off, it has been a loong time since I have had to submit a
patch (with the Jetspeed project I had the luxury of just committing).
Hopefully the format is correct (it was generated from Subclipse so I am
guessing it should be).
Okay, that out of the way on
* Johan Compagner:
You can start it now as far as i am concerned.
I am curious do i check in the files correct?
For example the 2 new files i checked in last night: WicketObjectIn and
OutputStream
are those correct?
To know whether you have the right settings, try:
$ svn proplist
But i am not going to set properties on every new file that i check in
So how do i get the right properties (which) by default in eclipse?
johan
On 2/12/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
* Johan Compagner:
You can start it now as far as i am concerned.
I am curious do i
+1 examples don't matter a few extra libs.
johan
On 2/10/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
JHighlight [1] is a CDDL 1.0 licensed library that generates syntax
highlighted markup for Java, Groovy and other languages, created by
Java champion Geert Bevin.
Our current examples have
Hi,
I don't know about you guys, but maven isn't picking up fresh
snapshots from http://wicketstuff.org/maven/repository/ for me.
My guess is that a file like
http://wicketstuff.org/maven/repository/org/apache/wicket/wicket-datetime/1.3-incubating-SNAPSHOT/maven-metadata-local.xml
once created
On 2/12/07, Johan Compagner [EMAIL PROTECTED] wrote:
...But i am not going to set properties on every new file that i check in
So how do i get the right properties (which) by default in eclipse?...
FIY, http://www.apache.org/dev/svn-eol-style.txt has an example config
for command-line SVN.
can't this be pushed to the server?
Let the server convert it to the right thing he wants.. And then send me
back the changes after commit
johan
On 2/12/07, Bertrand Delacretaz [EMAIL PROTECTED] wrote:
On 2/12/07, Johan Compagner [EMAIL PROTECTED] wrote:
...But i am not going to set
Johan Compagner wrote:
can't this be pushed to the server?
Let the server convert it to the right thing he wants.. And then send me
back the changes after commit
Typically no, because the server doesn't know your operating system,
your client does. That is the argument, anyhow.
Upayavira
Hi All,
First off, it has been a loong time since I have had to submit a
patch (with the Jetspeed project I had the luxury of just committing).
Hopefully the format is correct (it was generated from Subclipse so I am
guessing it should be).
Okay, that out of the way on to the important part.
Thanks.
Eelco
On 2/12/07, Weaver, Scott [EMAIL PROTECTED] wrote:
Okay, it is up in Jira (WICKET-279) with the corrected patch format.
Regards,
-scott
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Monday, February 12, 2007 11:16 AM
To:
Johan Compagner wrote:
or i can make it so that it returns really an page copy with that version.
Just some thoughts about the idea of copying a page:
I have been experimenting with making copies of pages, and there are some
tricky things to take care of. The page has internal flags that
i think we should externalize it away from the page. the page doesnt need to
know HOW it is versioned, all it needs to have is a listener for when its
state is changed and we have that through addStateChange
-igor
On 2/12/07, Johan Compagner [EMAIL PROTECTED] wrote:
or i can make it so that
Jan Vermeulen wrote:
And you should manipulate the versionManager of that copy, so that it
points to the correct versionNumber.
Sorry, not needed. That's done by the rollback.
Jan.
--
View this message in context:
for eelco: you had to disable both methods! (objectToByte and byteToObject)
For now i enabled both so that it gets tested as much as possible the coming
few days
Ok, we can keep it in for a few days, but it has to improve quite a
bit before it's ready for real world use.
* Does your code
before we start doing all this have you guys tried the jboss serialization
thing yet?
the problem, like johan mentioned, is that this wont work across jvms
because he keeps some kind of cache? but then this makes it useless for
clustering. i think whatever solution we come up with needs to work
On 2/12/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
before we start doing all this have you guys tried the jboss serialization
thing yet?
Yes, and it didn't even remotely work for the project I'm working on.
Furthermore, maybe I'm wrong, but it seems that after doing two
initial releases this
There probably are a couple of cases where our code could benefit from
either custom read/writeObject methods or implementing Externalizable.
What are your ideas about that?
Eelco
On 2/12/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 2/12/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
before we start doing all this have you guys tried the jboss serialization
thing yet?
Yes, and it didn't even remotely work for the project I'm working on.
Furthermore, maybe I'm wrong, but
On 2/12/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
for eelco: you had to disable both methods! (objectToByte and byteToObject)
For now i enabled both so that it gets tested as much as possible the coming
few days
Ok, we can keep it in for a few days, but it has to improve quite a
bit
well the fact that it is LGPL is ok, we can rewrite the pieces we need. i
was mainly interested in the ideas they used, they did claim it was 30%
faster? hmm
-igor
On 2/12/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 2/12/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 2/12/07, Igor
On 2/12/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
for eelco: you had to disable both methods! (objectToByte and byteToObject)
For now i enabled both so that it gets tested as much as possible the coming
few days
Ok, we can keep it in for a few days, but it has to improve quite a
bit
Hi,
Is there a JIRA issue already?
I released a Wicket app based on a pre-1.2.5 release 2 weeks ago. I
would like to know whether we need to create an update after 1.2.6 is out.
Regards,
Erik.
Johan Compagner wrote:
Yesterday i just fixed the AccessStackPageMap in 1.3 (that is the one
And sorry to anyone if it has been discussed before
we have a user list on sf.net
usually when incubating in apache the user list moves over after graduation
from the incubator
-igor
On 2/12/07, Luca Botti [EMAIL PROTECTED] wrote:
And sorry to anyone if it has been discussed before
I hope to do a port to 2.0 later this week.
Just did that.
Eelco
Igor Vaynberg wrote:
we have a user list on sf.net
usually when incubating in apache the user list moves over after graduation
from the incubator
Or more likely, there will be a user list at Apache when there is an
Apache release of Wicket for users to discuss - whether that be 1.3 or 2.0.
On 2/12/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 2/12/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
for eelco: you had to disable both methods! (objectToByte and byteToObject)
For now i enabled both so that it gets tested as much as possible the coming
few days
Ok, we can keep it
does that go toward final releases or betas too?
-igor
On 2/12/07, Upayavira [EMAIL PROTECTED] wrote:
Igor Vaynberg wrote:
we have a user list on sf.net
usually when incubating in apache the user list moves over after
graduation
from the incubator
Or more likely, there will be a user
Igor Vaynberg wrote:
does that go toward final releases or betas too?
Betas would do for me, personally.
Upayavira
On 2/12/07, Upayavira [EMAIL PROTECTED] wrote:
Igor Vaynberg wrote:
we have a user list on sf.net
usually when incubating in apache the user list moves over after
On 2/12/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
In general, @author tags and attributions are poison to ASF-style
collaboration, they are all about carving out niches in the code.
The ASF-style development is about tearing down niches and promoting
collaboration across an entire code
we discussed it before
the consensus at that time was to keep them because they make
blaming^H^H^H^H^H^H^Hdelegating easier
-igor
On 2/12/07, Frank Bille [EMAIL PROTECTED] wrote:
On 2/12/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
In general, @author tags and attributions are poison
Yeah. I think we are an excellent example of a project where
maintainers bare shared responsibility for the code base. There are a
couple of instances where person A knows more about a certain piece of
code than person B, but that's independent from having those author
tags. Also, as those tags
I tried jboss didn't get me anything no speed and size improvement.
when i used JBossOut en In instead of the normal out en in.
I can make it work for clusterings but the bytes will be much greater then i
guess
because i need to write a class name instead of a short.
Of course we could do that
well you know, im just playing a devils advocate :)
i guess you are kinda using the codec ideas we discussed - cutting out the
long class header
here is what i would try
i guess right now you are keeping an application map:classname-byte
but what if we do this:
keep an application
On 2/12/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
for eelco: you had to disable both methods! (objectToByte and
byteToObject)
For now i enabled both so that it gets tested as much as possible the
coming
few days
Ok, we can keep it in for a few days, but it has to improve quite a
bit
So you want to add a registry of classnames-id and also save that?
(as a TOC prepended to the beginning of the the stream is very hard because
you write as you go further)
But why do that? then you still write the classnames and if we write a
classname
it is a string. So that classname will be
custom read/write is supported (only have to fix one bug)
I have no idea what Externalizeable brings you exactly compared to the
read/write objects..
But checking if it implements that interface and then just call those
methods is pretty easy.
johan
On 2/12/07, Eelco Hillenius [EMAIL
Thats fine.
Already thought about it where we let the Objects class look at a setting
where
you can choose what every you want.
But i don't think that is really a choice many people will use. But if they
can come up with a better way for serialization and deserialization thats
fine with me
We
What do you think i have been doing the past weekend!! :)
This is really as fast and as small as we can get. Its almost no overhead
and we only store as less bytes as possible.
Its really almost done (for a few bugs of course)
The only thing that is open now is that new GregorianCalendar()
hmm the application should be available
because if we start writing classnames and we have to resolve them
then i want to be able to get the right classloader.
But i gues this can also be done in the constructor of
WicketObjectInputStream (give the classloader)
johan
On 2/12/07, Eelco
hmmm
so if you have something like this
class A {}
class B { private A a; private A aprime; }
when you serialize B does it write the class header for A once or twice?
because i think that header has the classname so it would be output twice
no? last time i checked the header was a bit over
On 2/12/07, Johan Compagner [EMAIL PROTECTED] wrote:
On 2/12/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
for eelco: you had to disable both methods! (objectToByte and
byteToObject)
For now i enabled both so that it gets tested as much as possible the
coming
few days
Ok, we can keep
On 2/12/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
hmmm
so if you have something like this
class A {}
class B { private A a; private A aprime; }
when you serialize B does it write the class header for A once or twice?
because i think that header has the classname so it would be output twice
On 2/12/07, Johan Compagner [EMAIL PROTECTED] wrote:
hmm the application should be available
because if we start writing classnames and we have to resolve them
then i want to be able to get the right classloader.
But i gues this can also be done in the constructor of
WicketObjectInputStream
On 2/12/07, Johan Compagner [EMAIL PROTECTED] wrote:
Thats fine.
Already thought about it where we let the Objects class look at a setting
where
you can choose what every you want.
But i don't think that is really a choice many people will use. But if they
can come up with a better way for
On 2/12/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 2/12/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
hmmm
so if you have something like this
class A {}
class B { private A a; private A aprime; }
when you serialize B does it write the class header for A once or twice?
because i think
I think now that we're dependent on JDK 1.5+, there is a JMX-related sizeof
method we can use to find out the exact size of a given object in memory.
We might want to switch to that.
Eelco Hillenius wrote:
On 2/12/07, Johan Compagner [EMAIL PROTECTED] wrote:
Thats fine.
Already thought
no, this is different
B b=new B(); b.a=new A(); b.aprime=new A();
they are different instances, i am talking about class headers not
references
the way jdk serialization works is that for every class it does something
like this
[class-header classname,etc][fields]
so what i want to know and
hrm, so the default jdk serialization is also building a toc? interesting,
thats what i wanted to know.
-igor
On 2/12/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
no, this is different
B b=new B(); b.a=new A(); b.aprime=new A();
they are different instances, i am talking about class
57 matches
Mail list logo
