Re: wicket:interface, etc. in generated URLs
i think i already proposed something like this long time ago But i think it was to avoid collisions in the url and more expressive urls? but this rename is fine by me except the wicket:bookmarkablePage that can be shorted like w:bookmarkablePage because the urls really says that it is bookmarkable (and all old urls must still work so wicket:bookmarkablePage must keep working) better would it in my eyes if developers could customize this them self. So have a settings class where they can be configured We (servoy) already had this for a large part but this we do by completely subclassing/copying WebRequestCodingStrategy so these should change: /** Name of interface target query parameter */ public static final String NAME_SPACE = "wicket:"; /** Name of interface target query parameter */ public static final String INTERFACE_PARAMETER_NAME = NAME_SPACE + "interface"; /** AJAX query parameter name */ public static final String BEHAVIOR_ID_PARAMETER_NAME = NAME_SPACE + "behaviorId"; /** Parameter name used all over the place */ public static final String BOOKMARKABLE_PAGE_PARAMETER_NAME = NAME_SPACE + "bookmarkablePage"; /** Pagemap parameter constant */ public static final String PAGEMAP = NAME_SPACE + "pageMapName"; into something like public static final String NAME_SPACE = Application.get ().getSettings().getNameSpace(); But ofcourse directly that can't be done so i guess we need to push them from our init phase johan On 7/25/07, Al Maw <[EMAIL PROTECTED]> wrote: Hi folks, Although some people don't really care what their URLs look like, lots of people do. If you use UrlCompressingWebCodingStrategy you can get the actual parameter values for interface/behaviour/etc. URLs looking pretty small and inoffensive. But the name is still something large, like "wicket:interface". I'm wondering if for 1.3 we could replace that with just: wicket:interface--> w:i wicket:behaviourId --> w:b wicket:bookmarkablePage --> w:p wicket:pageMapName --> w:m It'd make the URLs shorter and not really any less comprehensible (this stuff only really means anything to people who understand the internals anyway). It'd make things very marginally quicker (less string matching). In short, I can't really see any disadvantage to it, other than that it will break any existing bookmarks to non-mounted pages. I'm pretty sure that the upgrade from 1.2 to 1.3 breaks these anyway. It's a trivial fix (just update the constants in WebRequestCodingStrategy and a bunch of expected unit test results). What do people think? Regards, Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com
Re: Unable to convert returns null instead of throwing exception
hmm looking at the code this is strange it should throw a nullpointer
exception
PropertyResolverConverter.convert(Object object, Class/**/ clz)
IConverter converter = converterSupplier.getConverter(clz);
if (object instanceof String)
{
return converter.convertToObject((String)object, locale);
}
else if (clz == String.class)
{
return converter.convertToString(object, locale);
}
else
{
try
{
return Objects.convertValue(object, clz);
}
catch (RuntimeException ex)
{
// ignore that try it the other way
}
// go through string to convert to the right object.
String tmp = converter.convertToString(object, locale);
return converter.convertToObject(tmp, locale);
}
i see that we don't even test for the converter for null...
johan
On 7/22/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
I tried something that should throw an exception IMO.
public class Foo implements Serializable {}
public Index extends WebPage {
private Foo foo = null;
public Index() {
Form form = new Form("form");
form.add(new TextField("foo", new PropertyModel(this, "foo")));
}
}
If you don't register a convertor for Foo, then this should result in
a ConversionException in my opinion, but the field will become null
instead without any error.
If this is desired behavior, then at least throw the exception in
development mode.
But I may be missing something important here (apart from the fact
that doing this is very stupid).
Martijn
--
Wicket joins the Apache Software Foundation as Apache Wicket
Apache Wicket 1.3.0-beta2 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta2/
Re: getWrappedModel and getChainedModel (Component.getInnerMostModel())
nope not the IChainingModel i think that was igor. And also the getInnerMostModel() code is something i think from jonathan. And IChainingModel is much more the replacement of IModel.getNestedModel() then that IWrapModel is.. (thats really a new thing in 1.3) So what do people expect here: Component comp = new Component(new MyChainingModel(new HibernateModel(new Pojo(; IModel model = comp.getInnerMostModel() ?? johan On 7/20/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > we also have IChainingModel shouldn't we also test for that? > because çurrently the behavior is that we only test for WramModels to get to > the innermost model > but what is then the big difference with IChainingModel? Hey, didn't you code that stuff? :) Eelco
Re: yahoo components and the use of yahoo.js/event.js
On 7/19/07, James McLaughlin <[EMAIL PROTECTED]> wrote: The injecting flag is used only by the new yuiloader functionality, which will resolve and load library dependencies. Before this, you would need to specify each dep by hand. For some reason, the yui event prefers to use document.write to create the script node over document.createElement if not injecting. This doesn't apply to versions < 2.3, so on its own this is no reason to rush upgrading. what do you mean? that 2.2 didn't use document.write()? it did in my place and i had some strange exceptions when using the yahoo menu when i inject the 3 js libs for the menu. I am now on 2.3RC and i set the injection flag when i see that i output the libs in an ajax request are you saying that i dont have to do that? That some yahoo lib does that for us? That i can't find anywhere in the docs. johan
yahoo components and the use of yahoo.js/event.js
the current version (2.2) isn't made for injection (what we could do for
example if we have an ajax tabpanel)
But 2.3 which is about the get released i think says this in the code:
// If the library is being injected after window.onload, it
// is not safe to document.write the script tag. Detecting
// this state doesn't appear possible, so we expect a flag
// in YAHOO_config to be set if the library is being injected.
if (("undefined" !== typeof YAHOO_config) &&
YAHOO_config.injecting) {
I cant find much info about that injection flag currently anywhere else.
But i guess every lib that uses yahoo should upgrade asap to the 2.3 (now in
RC: http://sourceforge.net/project/showfiles.php?group_id=165715)
and should do something like:
YAHOO_config = {
listener: mycallback // this is already something you can do in 2.2 if
needed.
};
YAHOO_config.injecting = true;
and only when we are in an ajax request..
johan
getWrappedModel and getChainedModel (Component.getInnerMostModel())
we have this code in Component:
protected final IModel getInnermostModel(final IModel model)
{
IModel nested = model;
while (nested != null && nested instanceof IWrapModel)
{
final IModel next = ((IWrapModel)nested).getWrappedModel();
if (nested == next)
{
throw new WicketRuntimeException("Model for " + nested + "
is self-referential");
}
nested = next;
}
return nested;
}
we also have IChainingModel shouldn't we also test for that?
because çurrently the behavior is that we only test for WramModels to get to
the innermost model
but what is then the big difference with IChainingModel?
johan
RequestListenerInterface and the page.beforeCall..
the invoke method does this:
public final void invoke(final Page page, final Component component)
{
page.beforeCallComponent(component, this);
if (!component.isEnabled() || !component.isVisibleInHierarchy())
{
// just return so that we have a silent fail and just re-render
the
// page
log.info("component not enabled or visible; ignoring call.
Component: " + component);
return;
}
try
{
// Invoke the interface method on the component
method.invoke(component, new Object[] {});
}
catch (InvocationTargetException e)
{}
finally { page.afterCallComponent}
that looks odd
if the invoke is not really done '(disabled or not visible) then the
beforeCall is still hapening?
do we do this on purpose?
if so then i think we should also always call afterCallComponent
but i guess we should change it like this
public final void invoke(final Page page, final Component component)
{
if (!component.isEnabled() || !component.isVisibleInHierarchy())
{
// just return so that we have a silent fail and just re-render
the
// page
log.info("component not enabled or visible; ignoring call.
Component: " + component);
return;
}
page.beforeCallComponent(component, this);
try
{
// Invoke the interface method on the component
method.invoke(component, new Object[] {});
Re: Improve Wicket performance with ETags
wicket is a framework for dynamic webpages, so 99% of the time you don't want to cache and you want to make sure that the browser does query again for the page. Also the none bookmarkable pages are like wicket:interface= and that xxx can be anything and 2 the same values could point to completely different things over multiply runs of the browser. if you want caching you have to do it your self in Page.configureResponse() or in your Resources.configeResponse() In both default imp we do already some stuff for example Page is configured to not cache and a resource if it is cacheable will send 2 headers. Also we have special support for the head request: 'If-Modified-Since' johan On 7/17/07, Bruno Borges <[EMAIL PROTECTED]> wrote: http://www.infoq.com/articles/etags What is an "ETag"? The HTTP protocol specification defines an ETag as the "entity value for the requested variant" (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html - Section 14.19.) Another way of saying this is that the ETag is a token that can be associated with web resource. The web resource is typically a web page, but could also be a JSON or XML document. The server is solely responsible for figuring out what the token is and means, and transfers it to the client in the HTTP Response Header. The process looks like this: 1. Client requests a page (A). 2. Server sends back page A, plus an ETag for A. 3. Client renders the page then caches it, along with the ETag. 4. Client requests page A again, passing along the ETag it got back from the server the last time it made the request. 5. Server examines the ETag and determines that the page hasn't changed since last time the client requested it, so sends back a response of 304 (Not Modified) with an empty body. What you guys think about this? :) Is the wicket cache system "etagged" already? []'s!! -- Bruno Borges Summa Technologies Inc. www.summa-tech.com (11) 8565-7739 (11) 3055-2060 (48) 8404-1300
Re: [jira] Created: (WICKET-756) FormComponent.getValue uses equals instead of == to compare NO_RAW_INPUT
which places are using == or !=? because those places are wrong, even
static final strings must be compared with equals because the value
that you compare it with could be serialized and then deserialaized.
On 7/15/07, Willis Boyce (JIRA) <[EMAIL PROTECTED]> wrote:
FormComponent.getValue uses equals instead of == to compare NO_RAW_INPUT
Key: WICKET-756
URL: https://issues.apache.org/jira/browse/WICKET-756
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.2.6
Reporter: Willis Boyce
It looks like the "no raw input" condition is identified by the rawInput
member actually referencing the NO_RAW_INPUT constant, not having the same
string as NO_RAW_INPUT ("[-NO-RAW-INPUT-]"). Twice the code uses == or !=
to compare rawInput to NO_RAW_INPUT. But once it uses the equals method
instead. This is probably wrong; it should use ==.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Resource - should we call response.setHeader("Cache-Control", "no-cache, must-revalidate") by default?
you could try no-store
that has always major effect when i use that.
johan
On 7/16/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote:
* Al Maw:
> Hi folks,
>
> See http://issues.apache.org/jira/browse/WICKET-750
>
> I'm not sure whether we should be doing what Pierre suggests or not.
>
> if (!Resource.isCacheable()) {
> response.setHeader("Cache-Control", "no-cache, must-revalidate")
> }
>
> ...does seem quite sensible. After all, if it's not cacheable, then you
don't want it cached. ;-)
And it appeared that this was not sufficient to fix the following
usecase (as Pierre told me):
* you have a page with a dynamic resource
* an ajax request changes the underlying image and the response
outputs the with the exact same URL: nothing happens even
with cache headers like above
It seems like the real solution is to append &random=145 to the
URL. This may depend on the browser, and it would be interesting
to have a quickstart.
Did you also experience this?
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Register the web application instance with the servlet context (Was: svn commit: r556443)
and it looks like that we try to duplicate the Applicat.get(appname) behavior i think that is the way to always get an application object you only have to know the appname And to correctly do the thing below we also have to append the appname after: SERVLET_CONTEXT_APPLICATION_KEY johan On 7/16/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote: * [EMAIL PROTECTED]: > Author: ehillenius > Date: Sun Jul 15 13:20:59 2007 > New Revision: 556443 > > URL: http://svn.apache.org/viewvc?view=rev&rev=556443 > Log: > register the web application instance with the servlet context so that extending framework can find the instance without having to rely on the current thread Eelco, That's a nice idea but sadly I don't think it will work if you have multiple Wicket applications in the same servlet context. For example in wicket-examples we have several dozen apps on the same servlet context. The servlet context attribute will be overriden everytime, so in the end you'll only keep the last-initialized application. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: ehcache based MarkupCache
secondlevelcache doesn't cache anything anymore. (except caching it on disk) So ehcache cant really be used there. johan On 7/15/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: ehcache seems to be Apache licensed, so there is no immediate reason to put it into wicketstuff. Given that the extensions project is used to mature components and features, I think it is a logical place for it to be in. But given the limited usage: it is only used for the markup cache, correct? Woould the second level cache be a second feature that could benefit from ehcache? Martijn On 7/15/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > no big plus, just playing a bit and having the option if some realy > realy needs it.It should not go into the core project for sure. I'm > just looking for the right place to drop it. If extension is not the > right place either, due to the dependency, where should go? If not > useful at all, we don't need to put it anywhere. > > Juergen > > On 7/15/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > hmm i dont see the big plus, why would you have eviction? (except when the > > file really changes) > > The only eviction strategy i see that would be usefull is based if the > > avaialable memory is used up > > and it should free something. > > > > johan > > > > > > On 7/15/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > > > > > You can have all the out-the-box stats, jmx, eviction (remove if > > > markup was not requested for >7 days) etc. > > > > > > Juergen > > > > > > On 7/15/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > On 7/14/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > > > > > > > > > I've created a ehcache based MarkupCache extension. On my laptop it is > > > > > currently in wicket-extension which due to ehcache requires a ehcache > > > > > dependency in pom.xml. I wonder whether wicket-extension realy is the > > > > > right place? > > > > > > > > > > > > what are the advantages of this over the one we have? > > > > > > > > -igor > > > > > > > > > > > > > > > > Juergen > > > > > > > > > > > > > > > -- Wicket joins the Apache Software Foundation as Apache Wicket Apache Wicket 1.3.0-beta2 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta2/
Re: ehcache based MarkupCache
hmm i dont see the big plus, why would you have eviction? (except when the file really changes) The only eviction strategy i see that would be usefull is based if the avaialable memory is used up and it should free something. johan On 7/15/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: You can have all the out-the-box stats, jmx, eviction (remove if markup was not requested for >7 days) etc. Juergen On 7/15/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > On 7/14/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > > > I've created a ehcache based MarkupCache extension. On my laptop it is > > currently in wicket-extension which due to ehcache requires a ehcache > > dependency in pom.xml. I wonder whether wicket-extension realy is the > > right place? > > > what are the advantages of this over the one we have? > > -igor > > > > Juergen > > >
Re: Thread synchronization problems in FilePageStore
i will also look more closely to this the comming weekend. i guess we can drop the filestore if we can't find much wrong with the diskpagestore johan On 7/12/07, Matej Knopp <[EMAIL PROTECTED]> wrote: Well, it's very new and not very tested. Therefore it's "experimental". It might work well but there might also be issues. It would help a lot if you tried using it and if you come across any problems let me know. -Matej On 7/12/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote: > > > Matej Knopp-2 wrote: > > > > Hi, there's a new experimental DiskPageStore in Wicket trunk, would > > you mind checking if it suffers from the same problem? > > > > I ran the test on the new DiskPageStore with various sleep-times and up to > 1000 loops, and it never failed. > > I see it is storing various pages in a single file, and uses a > FileChannelPool to improve performance. Can we safely use the new > DiskPageStore as an alternative for FilePageStore ? > > Jan. > -- > View this message in context: http://www.nabble.com/Thread-synchronization-problems-in-FilePageStore-tf4063498.html#a11556698 > Sent from the Wicket - Dev mailing list archive at Nabble.com. > >
Re: Clone problem? Difference in behavior between 1.2 and 1.3
the problem with session data is just tricky, if you have a shopping
basket that is stored in the session object, and you add some to it,
the remove a few, then use the back button. what you now see on the
screen is the full shopping basket again, but on the serverside a
previos page is restored, so the view shows everything but the data
not, if you then remove one you have very funny behavior which you
really have to program for.
On 7/11/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> this is not really solveable by wicket itself.
> We don't know where such a reference is comming from, so this should be
> documented i guess
> that if you use session data from the session object itself. You should
> always use an extra
> indiretion to get it
> new Model()
> {
> getObject() {Session.get().getList()}
> }
I don't see a generic solution either, but in this case I though you
should use custom serialization of either your custom session or a
model you use for the extra indirection.
Eelco
Re: [vote] remove type parameter from TextField constructor
it must handle string[] because sometimes for a multiselect it returns a collection. I guess that is tricky thing to put into the converter interface :( On 7/11/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: On 7/11/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > On 7/11/07, Gwyn Evans <[EMAIL PROTECTED]> wrote: > > I did want to respond to Johan's comment, but it's /not/ a -1 vote, > > especially in view of your reasons above - "0" if anything. > > I didn't want to imply as such, but I would not hold a grudge if you > would -1 it. It is late in the game, so ... the thing about removing convertValue(String[]) if we are going to do it it needs to be now, or it wont make it into 1.3.xperiod. so we need to decide if this is important enough to get into 1.3 branch. one tricky part about it is that the converter will have to be installed for String[]? or do we call it repeatedly if there is more then one element? -igor Martijn > > -- > Wicket joins the Apache Software Foundation as Apache Wicket > Apache Wicket 1.3.0-beta2 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta2/ >
Re: bug in AbstractAjaxTimerBehavior?
please make a jira issue for this yes, i guess we need some check on an id so that we dont add it twice On 7/11/07, Xavier Hanin <[EMAIL PROTECTED]> wrote: Hi, I think I've found a bug in AbstractAjaxTimerBehavior... The problem happens when a component to which an AbstractAjaxTimerBehavior is attached is rendered by an AjaxRequestTarget which is not due to the timer, but to another Ajax call. In this case it seems that the renderHead method called on AbstractAjaxTimerBehavior adds another setTimeout() javascript call than the one originally rendered, which makes the timer call happen twice as frequently as it should. I haven't isolated the problem in a simple example, so my analysis may be wrong (I'm experiencing this issue when working on wicketstuff-push, so the source can be something else). Do you think my analysis make sense? Should I open an issue in JIRA? Xavier -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://incubator.apache.org/ivy/ http://www.xoocode.org/
Re: [vote] remove type parameter from TextField constructor
so you always want to call getConverter() and if typename is not set you get a null param? and then all the components that now implemements convertValue(String[] values) should override getConverted(Class) and test for null and if it is null then return a converter which does the same as convertValue does now. we could do that yes. It cleans up the api and makes it more obvious that getConverter() is always called. johan On 7/11/07, Al Maw <[EMAIL PROTECTED]> wrote: Al Maw wrote: > In my opinion, if you override getConverter() then it should always be > used, even if that means we have to call it with a null type parameter. > (Normally when you're overriding it for a particular component you don't > care about the type parameter anyway). Looking at this further, it seems logical to me that we should remove the convertValue(String[] value) method from FormComponent and push the logic in there into a "proper" converter, which gets registered for null types. Thoughts? Regards, Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com
Re: [vote] remove type parameter from TextField constructor
Ugh. We still seem to be changing lots of fundamental stuff, don't we. :-) I vote: [x] deprecate them for beta3 We could possibly remove them for rc1, but that makes migration from 1.2.x harder, doesn't it? i personally don't care that much about breaking stuff for 1.3. We really need to streamline the api i think for 1.3 so that we don't have to break a lot in the further anymore lets make 1.3 a very solid base..
Re: [vote] remove type parameter from TextField constructor
this constructor can be deleted yes:
public TextField(final String id, final Class type)
{
super(id);
setType(type);
}
but i don't know about this one:
public TextField(final String id, IModel model, Class type)
{
super(id, model);
setType(type);
}
because if you don't use the propertymodel here then that type is pretty
needed
And bigger problem here, if you override
public IConverter getConverter(Class type)
and you don't set the type then that converter isn't used.
but this is also pure for models that don't use our own property model
variants
because we always set the type then (IObjectClassAwareModel)
johan
On 7/10/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
Matej had the brilliant idea of auto discovery of the type parameter
for FormComponents when they use a PropertyModel or
CompoundPropertyModel. In order to remove confusion for noobs, and to
point out that there is a Better Way (tm) I propose the following
options:
For those wondering if it is still possible to set the target type:
yes you can, just use the setType() method on the form component.
I know it is a tad late in the game, but I think the clean up is
something worthwile.
[ ] remove the affected FormComponent constructors with the type parameter
[ ] deprecate the affected FormComponent constructors with the type
parameter
[ ] leave them
Martijn
--
Wicket joins the Apache Software Foundation as Apache Wicket
Apache Wicket 1.3.0-beta2 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta2/
Re: Clone problem? Difference in behavior between 1.2 and 1.3
this is not really solveable by wicket itself.
We don't know where such a reference is comming from, so this should be
documented i guess
that if you use session data from the session object itself. You should
always use an extra
indiretion to get it
new Model()
{
getObject() {Session.get().getList()}
}
johan
On 7/10/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
Working on the Book I found a difference between 1.2 and 1.3:
In the following setup if you click on the 'link' a couple of times,
you see that the list in the session grows, and that it is reflected
in each page render.
Now, press the back button and continue clicking on the link. You will
see that the page remains static from that moment on. This was not a
problem in 1.2 because the HttpSessionStore is the only way of storing
the pages for back button behavior. However, in 1.3 the 2nd level
cache is the new way of storing, and this is the consequence of that
store: you get different objects between versions.
Is there anything we can do to prevent this from happening?
public class MySession extends WebSession {
public final List list = new ArrayList();
}
public class FooPage extends WebPage {
public FooPage() {
add(new ListView("foo", MySession.get().list){
protected void populateItem(ListItem item) {
item.add(new Label("text", item.getModelObject()));
}
});
add(new Link("link") {
protected void onClick() {
MySession.get().list.add("foo " + System.currentTimeMillis
());
}
});
}
}
Click me
--
Wicket joins the Apache Software Foundation as Apache Wicket
Apache Wicket 1.3.0-beta2 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta2/
Re: PageParameters and bookmarkable page
this should work, do you have a quickstart that demonstrates this?
On 7/10/07, Goran <[EMAIL PROTECTED]> wrote:
I have a problem with passing request parameters to a Wicket page.
Bookmarkable page is defined in init method in WebApplication class like
this:
mountBookmarkablePage("/somepage", SomePage.class);
When I try to send parameters to that page from the form below:
http://someAddress/ApplicationName/app/somepage";
method="post">
The SomePage doesn't get request parameter param1 from PageParameters
object.
But when I change action attribute in form to (add otherParm and any
value):
http://someAddress/ApplicationName/app/somepage/otherParm/2
Then parm1 comes to the page also.
Why is that happening and how can I use
http://someAddress/ApplicationName/app/somepage
without the bogus otherParm parameter?
Thanks for the help :)
--
View this message in context:
http://www.nabble.com/PageParameters-and-bookmarkable-page-tf4054941.html#a11518078
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: NPE in Component.detachModel() when wrappedModel is null
What we are looking for is some transparent way for users to provide data to components that do not get stored with these components when the page is serialized. your are just describing IModel.detach().. But i guess your model that is wrapped does this behavior in detach? then how is this model called detach on? I still can't see the complete picture here how you are avoiding that those data structures are not serialized with just using IComponentAssignedModel because that model is referenced by the component. And that model has to reference the real model because how else can it get the data that it shows? So if the wrapmodel has to have a reference to the real model why can't you return it in getWrappedModel() johan
Re: NPE in Component.detachModel() when wrappedModel is null
I think it is wrong that the getWrappedModel() returns null
it is pretty much the contract that it has to return the model that it wraps
around
it is used in more places. (set model, inner model or getInnerMostModel)
and no if the model is not a inherited model but a component assign aware
model
then i want to handle the detach directly else every kind of implementation
has to
do it themselfs that will be forgotton now and then.
johan
On 7/9/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote:
Following code provokes a NPE the wrappedModel is null:
// also detach the wrapped model of a component assignet wrap (not
inherited)
if (model instanceof IWrapModel &&
!getFlag(FLAG_INHERITABLE_MODEL))
{
((IWrapModel)model).getWrappedModel().detach();
}
We have that case because we have an IContextWrapModel that wraps models
that are stored in a context outside of the component graph. It lazily
looks
up the model by key in the context, and in its detach() it does the
following:
public void detach() {
if (wrappedModel instanceof IContextModel)
wrappedModel = null;
}
Two questions:
(1) Would it not be more correct to leave the 'detach' responsability to
the
wrapModel implementation ?
(2) If not, can there be a check for null pointers in the code above ?
Jan
--
View this message in context:
http://www.nabble.com/NPE-in-Component.detachModel%28%29-when-wrappedModel-is-null-tf4048326.html#a11499084
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: IComponentInheritedModel & IWrapModel just to get the component in model
make your own base model
public abstract class ComponentAssignModel implements IWrapModel,
IComponentAssignedModel
{
private Component component;
/**
* @see org.apache.wicket.model.IWrapModel#getWrappedModel()
*/
public IModel getWrappedModel()
{
return this;
}
/**
* @see org.apache.wicket.model.IComponentAssignedModel#wrapOnAssignment
(org.apache.wicket.Component)
*/
public IWrapModel wrapOnAssignment(Component component)
{
this.component = component;
return this;
}
protected Component getComponent()
{
return this.component;
}
}
the only thing is that i dont know if this completely works correctly (but i
think it should, bug or no bugs)
johan
On 7/5/07, Vincent Demay <[EMAIL PROTECTED]> wrote:
Hi
I have a custom model where i need to access to the component. The only
method I found seems me a little bit overkill :
my model should implement IComponentInheritedModel and I also need to
declare a new class implementing IWrapModel to return on
wrapOnInheritance. Furthermore all this stuff is not really oriented to
simply get the component in the model. (maybe there is a better way?)
I thought about a very simple way :
Just creating a new interface :
IComponentAwareModel{ void setComponent(Component component)}
and adding in component.class
if (model instanceof IComponentAwareModel){
((IComponentAwareModel)model.setComponent(this))}
I think it also avoid to write 40 code lines just to get the component
in the model.
WDYT?
--
Vincent Demay
Re: FileUploadField closing input streams behind my back
and if i remember correctly, back then it looked if the FileUpload project was really in suspend stage. there wasn't much happening on it, so i am talking abou the time we added it to the core of wicket johan On 7/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > I understand "we just took what little pieces we needed instead of adding a > dependency on the entire thing", but what is meant by "the code grew in a > different direction due to various reasons"? We started using commons-io as just a dependency, but after a while we needed some tweaks to better let it integrate with Wicket (at least that's what I remember) and later on, when we tried to cut down on dependencies we went from a 'patched' version to just taking the classes we needed. Eelco
Re: [vote] rebuild of wicket-1.3.0-beta 2
then just see if we do it for the next version. On 7/2/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > Changing the case of Java files tends to cause pain on Windows systems, > because they're case-insensitive. We're almost guaranteed to have people > with strange ClassNotFoundExceptions if we go and do this. > > It's yet another API change just before we release 1.3.0. > > If we fix the class names, we should also fix the method names. There's > a lot of inconsistency at the moment, and this would cause an awful lot > of API breakage. > > It would make sense to use "Javascript" everywhere, as "JavaScript" is > one word, so when you CamelCase it, it should all go lower. > > Otherwise, if you have a "JavaScriptHandler", is it a ScriptHandler for > Java, or a Handler for JavaScript? > > Anyway, there's a bunch of stuff we'd need to fix, including > HeaderContributor.forJavaScript(), etc. etc. > > I don't think we want to do that this close to a 1.3 release. I imagine > it'd be a faff for the upcoming Wicket book, too. I agree. The book isn't much of a problem in this case, but I know from some previous renames (around 1.1 if I recall correctly) that it can be a pain especially for Windows users. Annoying as these little naming inconsistencies can be, I'm not sure if it's is worth the pain. Eelco
Re: [vote] rebuild of wicket-1.3.0-beta 2
please send in a patch so that we can have the right names before the final of 1.3 On 7/1/07, Gerolf Seitz <[EMAIL PROTECTED]> wrote: i found some naming inconsistencies: JavaScriptReference vs. JavascriptResourceReference there are some other Java(S/s)cript classes... gerolf On 6/30/07, jweekend <[EMAIL PROTECTED]> wrote: > > > FYI, I successfully downloaded the 1.3.0 beta2 release from > http://www.apache.org/dist/wicket/1.3.0-beta2/ . > We're putting a course together, based on 1.3 so hopefully the APIs are > fairly stable now. Having said that, if there is stuff that no longer > makes > any sense (unhelpful naming, bad signatures ...), IMO, this is probably > the > last chance to change it without causing a riot, so I'd say it's better > now > than never. > Cemal > > > > Martijn Dashorst wrote: > > > > The build now includes guice and ioc, and the release notes (list of > > fixed JIRA issues) > > > > [ ] I have checked the distribution and +1 its release > > [ ] I haven't checked the distribution and +0 its release > > [ ] I have checked the distribution and -1 its release because... > > > > I will try to upload this to the mirroring site once we have enough > > +1's (3 minimal), if we have enough karma to do so. Otherwise, we'll > > just have to do without 2000+ downloads. > > > > Martijn > > > > -- > > Wicket joins the Apache Software Foundation as Apache Wicket > > Join the wicket community at irc.freenode.net: ##wicket > > Wicket 1.2.6 contains a very important fix. Download Wicket now! > > http://wicketframework.org > > > > > > -- > View this message in context: > http://www.nabble.com/-vote--rebuild-of-wicket-1.3.0-beta-2-tf3996683.html#a11369135 > Sent from the Wicket - Dev mailing list archive at Nabble.com. > >
Re: [proposal] restructure projects a bit
fine by me +1 On 6/30/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: Igor just committed a maven archetype to our svn and we still have a quickstart and examples project that seem a bit out of place for our main distribution. trunk/ archetypes/ jdk-1.4/ wicket-quickstart jdk-1.5/ wicket-examples/ testing/ README NOTICE LICENSE release.sh eclipse.sh pom.xml I'm proposing to move things a bit around. trunk/ applications/ wicket-archetype/ wicket-quickstart/ wicket-examples/ jdk-1.4/ jdk-1.5/ testing/ README NOTICE LICENSE release.sh eclipse.sh pom.xml Each application will then have a separate release distribution, so we will release: wicket-1.3.zip wicket-quickstart-1.3.zip wicket-examples-1.3.zip (the archetype will only be released through the maven repo) The wicket zip will contain all library projects, so no stand alone war apps. The benefit is that we don't need to ship all those licenses in our main distribution, but can limit that to the wicket-examples distribution. I found it very hard to see and follow what we ship and what we don't. The examples distribution is the biggest project with all dependencies coming together. WDYT? Martijn -- Wicket joins the Apache Software Foundation as Apache Wicket Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
any objections to upgrade to slf4j 1.4.0?
We are on 1.3.1 now but i see there is a 1.4.0 and i have to use it anyway in another project (thats also using wicket) so i could also upgrade wicket to 1.4.0 johan
Re: [vote] rebuild of wicket-1.3.0-beta 2
if it is exactly the same as before and now with the 2 extra jars: [X] I have checked the distribution and +1 its release On 6/28/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: The build now includes guice and ioc, and the release notes (list of fixed JIRA issues) [ ] I have checked the distribution and +1 its release [ ] I haven't checked the distribution and +0 its release [ ] I have checked the distribution and -1 its release because... I will try to upload this to the mirroring site once we have enough +1's (3 minimal), if we have enough karma to do so. Otherwise, we'll just have to do without 2000+ downloads. Martijn -- Wicket joins the Apache Software Foundation as Apache Wicket Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
Re: [vote] release Apache Wicket 1.3.0-incubating-beta-2
you are building with java6 wicket 1.2 should be build with java 1.4 but i thought jonathan did fix this that we are now stable again and not depending on the order of the keys from a hashmap johan On 6/28/07, Martin Funk <[EMAIL PROTECTED]> wrote: err... I get a failing unit test on this one: https://issues.apache.org/jira/browse/WICKET-708 possibly a java implmentation issue? http://www.nabble.com/different-jdk-behavior-depending-on-OS-or-version-tf3673677.html#a10265596 mf
Re: [vote] release Apache Wicket 1.3.0-incubating-beta-2
[X ] I checked the distribution, and I +1 the release of them why doesn't RAT like the Diff package? it is ASL (not 2.0 but 1.1) johan On 6/26/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: This is a vote to release the Apache Wicket 1.3.0-beta2 (note the missing -incubating) distribution I just uploaded to my people.apache.org account page. I know we are anxious to get this one out the door, but I urge all of us to go through the release and check if you find anything wrong with it, and/or license wise wrongs. Particular care needs to be applied to the new projects wicket-ioc and wicket-guice. [ ] I didn't check the distribution, but I want to release them regardless (+0) [ ] I don't want to release the distribution, because ... You can find the RAT log, distributions and maven repository here: http://people.apache.org/~dashorst/releases/apache-wicket-1.3.0-beta2 Standard release procedures apply: 72 hours, at minimum 3 +1's from PMC members. Martijn
Re: getMarkupId doesn't return the id from the markup
i can think of one, getMarkupId() can't really be called in the constructor phase (as we could do in 2.0) (it now can but then you really have to make sure how you construct your objects you have to setup the hierachy up until the page as soon as possible) johan On 6/25/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: What are the side effects? We have been down this road too many times and we keep forgetting them (or ignoring until we can't bare them) I'd hate to not fix this one once and for all. Martijn -- BREAKING NEWS: Wicket joins the Apache Software Foundation as Apache Wicket Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
Re: should we get rid of IRequestCycleFactory and ISessionFactory?
+1 one class to implement and then one class to create most things needed.. johan On 6/24/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: On 6/24/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > IRequestCycleFactory and ISessionFactory annoy the hell out of me. We > simplified how they are used a bit in 1.3, but imho, I think we should > just ditch them all together in favor of simply two factory methods in > application. Factory method newSession already exists in > WebApplication (as that class implements ISessionFactory), but to > create a new request cycle you still have to override > getRequestCycleFactory(). > > Objections anyone? > > Eelco > +1 also what to do about session.newrequestcycle vs application.newdefaultrequestcycle. can we get rid of the session one? i understand the "concept" of a cascade: application creates session, session creates request cycle. but how practical is that? when do you want different request cycles for different sessions? and we already do create request/response in application where if you would follow the cascade idea they should be created in requestcycle, so its kinda broken already anyways. -igor
Re: Example for Border use wrong in wiki...
Also do look once to the IComponentBorder (and the implementation: MarkupComponentBorder) ofcourse that won't help you too much with your situation i guess because then still all subclasses shouldn't add to the page but to the panel that has the border.. johan On 6/18/07, Mark Derricutt <[EMAIL PROTECTED]> wrote: On 6/18/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > Not so sure what to do with this. I think we should regard such use of > borders as outdated, and that for such templating markup inheritance > should be used. In the case I was wanting to work with markup inheritance didn't really work right as I wanted to change the used border on the fly, in the end I just used object inheritance having the subclassed pages to call "border.add()" rather than add() directory (with the border defined/added by the base class as required). It works, and its good that its explicit that you're adding objects into the border, but it would also be nice to override add() and disallow the subclasses from adding to the page itself. Mark
Re: Application#internalInit() - should be final?
yeah webapplication could make that final. (same as the internalDestroy) But still if people would make there own none webapplication we would still have the same problem. would be nice to have some different scope in java like "friends" or thinks like protected only for or final protected except for On 6/20/07, Al Maw <[EMAIL PROTECTED]> wrote: Al Maw wrote: > Application#internalInit() isn't final. However, if you override it and > don't call super.internalInit(), you won't add the session store, the > converter locator, any of the component resolvers, etc. etc. > > Obviously you have the init() method to configure your app with. So > surely internalInit() should be made final? Errr, on WebApplication, I mean, obviously. Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com
Re: Transfering resources from incubator to TLP
The real power would be having commit rights on the normal repository!! i could think of some delete commands for specific projects :) "Apache Wicket, The only webframework around" johan On 6/21/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: On 6/21/07, Upayavira <[EMAIL PROTECTED]> wrote: > Seems like you've got most things. Which is reasonable seeing as likely > you nicked this all from your own graduation guide :-) Having commit access to the incubator repository makes me feel like: I've got the power hey yeah heh I've got the power Oh-oh-oh-oh-oh-oh-oh-oh-oh yeah-eah-eah-eah-eah-eah I've got the power Oh-oh-oh-oh-oh-oh-oh-oh-oh yeah-eah-eah-eah-eah-eah Gettin' kinda heavy It's gettin' it's gettin' it's gettin' kinda hectic It's gettin' it's gettin' it's gettin' kinda hectic It's gettin' it's gettin' it's gettin' kinda hectic It's gettin' it's gettin' it's gettin' kinda hectic -- BREAKING NEWS: Wicket joins the Apache Software Foundation as Apache Wicket Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
Re: VOTE: Rename AjaxSubmitButton to AjaxButton
AjaxSubmitButton is a right name because its only purpose is that it submits a form right? But i don't mind that it is renamed but Button is not only a SubmitButton. We could make a subclass that really makes a input type=submit? (or test fors it) Because i use buttons on many places to replace links (but the look and feel of a button) so for me its not what they do, its how the look. So now AjaxButton always submits and Button can submit but also used as a link click.. So maybe a bit better thing would be to hava a AjaxSubmitButton and a SubmitButton (extends Button) and let button be used also for the other types or maybe introduce LinkButton? johan On 6/21/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote: +0 The Javadoc says: "A button that submits the form via ajax". And the callback method is called onSubmit(). So even if you rename the class (which is a very costly operation in a framework), it won't be sufficient to eradicate the term "submit". I understand that you want to streamline the name with Button, but actually I would vote to rename Button to SubmitButton. I was recently doing pair programming with a colleague, and we were stupidly looking for "SubmitButton" and wondered why it was not showing up. It was the obvious class name we thought... -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: abbreviated stack traces
still again. what do we mess up i haven't seen an example yet i am very curious about that because we do print once the Complete stacktrace and that is of the root cause The only thing we do different then then java itself is that we dont do top exception top-1 exception xxx 10 more.. top-2 exception 20 more.. root cause 30 more.. no we do only the complete root cause immediantly as the top one. Because that is what you want to see. On 6/21/07, Jonathan Locke <[EMAIL PROTECTED]> wrote: i just want to change the code so that Strings.toString(throwable) does not do this. we can move this stack trace trimming code into the exception page. that way we're 100% sure that it will never mess up. i think at least one of the truncated stack traces i've found was caused by multithreading in the log files, but i still feel very uneasy about anything that processes stack trace strings. i think only the exception page display code should do that if anything. maybe the exception display page should just hide all the extra details using a javascript triggered fold-out instead of trying to programmatically remove it? i would feel better if we simply weren't doing this trimming at all. Johan Compagner wrote: > > i still don't get it what then should be changed > We are printing the complete stack.. > the root cause is completely printed. Only the exceptions around the root > cause is not completely printed. (those are stopped at the wicket > servlet/filter) > > johan > > > On 6/20/07, Jonathan Locke <[EMAIL PROTECTED]> wrote: >> >> >> >> do i need a vote to make this change at this point? >> >> >> Eelco Hillenius wrote: >> > >> >> It might be good to be more defensive here then (as I think the trace >> I >> >> got >> >> had lost the info in both places): We could turn >> >> Strings.toString(Throwable) >> >> back into a simple version that always gives you the entire stack >> trace >> >> (I >> >> would really prefer that since this is supposed to be a generic >> utility). >> >> Then take the fancy version that's in the util package now and make a >> >> private implementation detail of the exception page(s). That way >> nobody >> >> can >> >> accidentally make the mistake of removing exception information from a >> >> log >> >> or the console. >> > >> > I agree. >> > >> > Eelco >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a11219888 >> Sent from the Wicket - Dev mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a11224009 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: abbreviated stack traces
i still don't get it what then should be changed We are printing the complete stack.. the root cause is completely printed. Only the exceptions around the root cause is not completely printed. (those are stopped at the wicket servlet/filter) johan On 6/20/07, Jonathan Locke <[EMAIL PROTECTED]> wrote: do i need a vote to make this change at this point? Eelco Hillenius wrote: > >> It might be good to be more defensive here then (as I think the trace I >> got >> had lost the info in both places): We could turn >> Strings.toString(Throwable) >> back into a simple version that always gives you the entire stack trace >> (I >> would really prefer that since this is supposed to be a generic utility). >> Then take the fancy version that's in the util package now and make a >> private implementation detail of the exception page(s). That way nobody >> can >> accidentally make the mistake of removing exception information from a >> log >> or the console. > > I agree. > > Eelco > > -- View this message in context: http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a11219888 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: NPE in PropertyResolver.getGetAndSetter()
can't we call the class resolver? for this?
OSGI is supposed to implement this and then the defaults are also better
johan
On 6/20/07, Al Maw <[EMAIL PROTECTED]> wrote:
Jan Vermeulen wrote:
> So my question is now: is that 'wicket.properties' file meant to be a
> resource that's always within the Wicket 'bundle' ? If so, would it not
be
> better to use the latter code to lookup resources, so that it works in
> environments with multiple classloaders ?
Yes, it will always be packaged in the Wicket JAR file, at any rate.
What this means in an OSGI environment I'm afraid I don't know. ;-)
> And if it's not that evident where the 'wicket.properties' file should
> reside, don't you need some utility method for resource loading that
tries
> out different classloaders ? Something like:
>
> public static URL loadResource(String path) throws
ClassNotFoundException {
> try {
> return
> (Thread.currentThread().getContextClassLoader().getResource(path));
> } catch (ClassNotFoundException e) {
> return
(getClass().getClassLoader().getResource(path));
> }
> }
>
> Jan.
>
Yep, absolutely. I've updated it to use the Thread's contextClassLoader,
which I think should be sufficient, no?
I've also updated things so that we don't run the PropertyResolver
init/destroy code in the Initializer, but instead in internalInit() and
internalDestroy(), as it seems a better place for it to live.
Al
--
Alastair Maw
Wicket-biased blog at http://herebebeasties.com
Re: Test failure in spring.injection.annot.AnnotProxyFieldValueFactoryTest
isn't that one on bamboo then? http://wicketstuff.org/bamboo/ On 6/19/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: When running maven from the root: mvn clean test I get the following test failure: [surefire] Running org.apache.wicket.spring.injection.annot.AnnotProxyFieldValueFactoryTest [surefire] Tests run: 4, Failures: 1, Errors: 0, Time elapsed: 0.492 sec FAILURE !! Anyone committed something and failed to run all the tests? Martijn -- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
Re: NPE in PropertyResolver.getGetAndSetter()
does it load through the wrong getClass()?
or the wrong classloader?
that code itself is basic jdk so something else has to be changed.
johan
On 6/19/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote:
After downloading the last changes in Wicket 1.3 TRUNK, we have a NPE in
PropertyResolver, due to the fact that there is no HashMap for the current
application. That's because the init(Application) is never called.
Debugging the problem, we found that the wicket.properties resource file
where the Initializer is registered is not correctly loaded:
// Load properties files used by all libraries
final Enumeration resources =
getClass().getClassLoader().getResources(
"wicket.properties");
while (resources.hasMoreElements())
{...
In the code above (Application.initializeComponents()), the enum does not
seem to have any elements, although we see that the resource file is
available, and this code has not been changed lately.
So what is happening here ?
Jan.
--
View this message in context:
http://www.nabble.com/NPE-in-PropertyResolver.getGetAndSetter%28%29-tf3946346.html#a11194510
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Fix inconsistent naming for submit components
because wicket is so flexible that you can do almost everything with just
one component!
for the html below i would use button.. But that is because it is visual a
button.
The differences are i guess that button has the submit() method and link the
onClick()
and because of those silly behaviours we have suddenly a Button can also
'have' an onclick.
and Link could be a form submitting component when it implements the
interface
So how to streamline all this? i don't know
lets just make Button and Link pretty much behave the same.
johan
On 6/18/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
since everyone is talking about this can i add some more flames? why is
Link
called link? cause really its not just a link.
you can do:
add(new Link("foo") {});
and in markup have
so its not just a link.
-igor
On 6/18/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
>
> i agree more with Frank,
>
> i don't like that Button would be come SubmitButton
>
> For me Button doesn't say what it does. no it tells me how it looks
> And many buttons don't submit but they are link (onclick)
>
> So having a SubmitButton is mostly not true for me because it doesn't so
a
> submit!
> its a
>
> johan
>
>
> On 6/18/07, Frank Bille <[EMAIL PROTECTED]> wrote:
> >
> > Hey
> >
> > We could also rename AjaxSubmitButton into AjaxButton.
> >
> > Then we have:
> > Button, ImageButton and AjaxButton (and AjaxFallbackButton)
> >
> > and
> >
> > SubmitLink and AjaxSubmitLink
> >
> > I don't know whats best, yet. It's just a surgestion now that we play
> with
> > names :)
> >
> > Frank
> >
> >
> > On 6/18/07, Al Maw <[EMAIL PROTECTED]> wrote:
> > >
> > > Hello,
> > >
> > > I know we're in a feature freeze, and I'm aware this one is likely
to
> be
> > > somewhat controversial, but I think we should rename a couple of the
> > > submit components, leaving behind @deprecated classes which extend
the
> > > renamed ones.
> > >
> > > We currently have:
> > >
> > > Button, ImageButton, SubmitLink, AjaxSubmitButton, AjaxSubmitLink.
> > >
> > > We're about to have an AjaxFallbackSubmitButton, too. [1]
> > >
> > > It would make sense for me for everything to be based on the word
> > > "Submit", so I think we should rename:
> > >
> > > Button -> SubmitButton (highly controversial, obviously)
> > >ImageButton -> SubmitImage
> > >
> > > This may well need to wait 'til 1.4.x.
> > >
> > > WDYT?
> > >
> > >
> > > Al
> > >
> > > --
> > > Alastair Maw
> > > Wicket-biased blog at http://herebebeasties.com
> > >
> > > [1] WICKET-634
> > > [Ajax[Fallback]]Submit[Image|Button|Link]
> > > If we support all combinations (which we probably should)
that's
> > > nine(!) components. I wish Java supported mix-ins. :-(
> > >
> >
>
Re: Fix inconsistent naming for submit components
i agree more with Frank, i don't like that Button would be come SubmitButton For me Button doesn't say what it does. no it tells me how it looks And many buttons don't submit but they are link (onclick) So having a SubmitButton is mostly not true for me because it doesn't so a submit! its a johan On 6/18/07, Frank Bille <[EMAIL PROTECTED]> wrote: Hey We could also rename AjaxSubmitButton into AjaxButton. Then we have: Button, ImageButton and AjaxButton (and AjaxFallbackButton) and SubmitLink and AjaxSubmitLink I don't know whats best, yet. It's just a surgestion now that we play with names :) Frank On 6/18/07, Al Maw <[EMAIL PROTECTED]> wrote: > > Hello, > > I know we're in a feature freeze, and I'm aware this one is likely to be > somewhat controversial, but I think we should rename a couple of the > submit components, leaving behind @deprecated classes which extend the > renamed ones. > > We currently have: > > Button, ImageButton, SubmitLink, AjaxSubmitButton, AjaxSubmitLink. > > We're about to have an AjaxFallbackSubmitButton, too. [1] > > It would make sense for me for everything to be based on the word > "Submit", so I think we should rename: > > Button -> SubmitButton (highly controversial, obviously) >ImageButton -> SubmitImage > > This may well need to wait 'til 1.4.x. > > WDYT? > > > Al > > -- > Alastair Maw > Wicket-biased blog at http://herebebeasties.com > > [1] WICKET-634 > [Ajax[Fallback]]Submit[Image|Button|Link] > If we support all combinations (which we probably should) that's > nine(!) components. I wish Java supported mix-ins. :-( >
Re: IMarkupLoader backport
sounds good to me. On 6/16/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: I've backported the IMarkupLoader change which removes "business" logic e.g. merging markup for inheritance out of MarkupCache into markup loaders. The interface is designed in a way that markup loaders can be chained, the most simple one just using MarkupParser. Another one merging the markup in case of inheritance. In addition I moved getMarkupCache from Application to IMarkupSettings but kept the method (it now delegates) in Application and deprecated it. Beside some increased flexibility in MarkupCache (see jira) I removed the sync lock which protected the hash map from parallel access. Since we are using ConcurrentHashMap for some time already, it should no longer be a reason for the sync block. Removing the sync may improve performance in situations where many markup files must be loaded (not just taken from the cache) (how much is that an issue in real life situations) but it also means that the very same markup might be loaded twice if while the first version is loaded (but not yet in the cache) a 2nd request will load the very same markup again. The code (on my laptop) will throw the 2nd version away and always use the first one. In my opinon that is acceptable, but I didn't want to commit it before I've discussed it. What would be the best test method (e.g. threadtest? a ready made web application and hhtpunit is most likely not the most suitable approach) to stress test these scenarios to make sure that we don't run into any race conditions. I guess this is especially usefull if we agree on putting it into 1.3. Juergen
Re: [vote] Release Apache Wicket 1.3.0-incubating-beta-2
we didn't completely decide what the next version number should be i think but i guess it could be again wicket 2.0 (or 1.4 or 1.5) I dont think we are going to release a generic version only (compared to 1.3 ) When we release 1.3 i will try to generify as soon as possible (again :( ) the complete source. And then we can have a first beta (that would be pretty stable because that one would be 1.3+generics) so users can use that and then we look what we can do more for that version. API wise the old 2.0 users could migrate to 1.3 except for generics. I think we did backport most api changes johan On 6/15/07, Stefan Lindner <[EMAIL PROTECTED]> wrote: Francisco Diaz Trepat wrote > God I can't wait to get my hands on the new generics for wicket. > I saw Version 1.4 in the issue tracker's roadmap. Is 1.4 the Java 5 version of Wicket 1.3 (the same as Wicket 1.3 but with generics)? Is 1.4 the new Name, not 2.0? And: is 1.4 as stable as 1.3 and can we old 2.0 users start to migrate to 1.4 or should we wait until 1.3 ist finally released? Like Francisco we cant' wait to get our hands on the new generics for wicket! Keep on running! Stefan
Re: automatically marking pages as stateless: is this really a good idea?
i didn't say dirty() should call bind() but bind should call dirty() (instead of storing everything right into the session) i see the problem with bind() being called by dirty() johan On 6/15/07, Al Maw <[EMAIL PROTECTED]> wrote: Johan Compagner wrote: > ahh i see, shouldn't bind() call just dirty() then? See, you might think this is a good idea, but the way things are currently, it would break stateless support, as Session.dirty() is tied into PageMaps and feedback messages in a way that's quite tricky to remove (or at least, it was when I last looked at this stuff three months or so ago). Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com
Re: automatically marking pages as stateless: is this really a good idea?
ahh i see, shouldn't bind() call just dirty() then?
instead of already storing itself and all the temp objects in the session
(are all those detached?)
and if we want to say to the developers call bind() yourself instead of
dirty()
then bind should be callable twice and not:
else
{
log.warn("trying to bind an already bound and non-temporary
session");
}
that should the then i guess
else
{
dirty()
}
johan
thats not good. bind() can be called at any time. So those values could all
be
On 6/14/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
On 6/14/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> he just has to call dirty() when he alters a session and wants to store
it
That currently (in 1.3) doesn't trigger binding.
Eelco
Re: automatically marking pages as stateless: is this really a good idea?
he just has to call dirty() when he alters a session and wants to store it On 6/14/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: I'm wondering whether it still is a good idea to automatically mark pages as stateless if there are no 'statefull' components/ callbacks on it. It's not so much a problem that the page isn't stored - it isn't as there aren't any non-bookmarkable callbacks to it - but it can be a problem that a session isn't automatically created. See for example http://www.nabble.com/Re%3A-noob-question-about-wicket-p3903.html I'm not sure... on the one hand I like it that Wicket tries to be as efficient as it can be with storing stuff and creating sessions. On the other hand, like the referenced thread shows (if I'm right there), it can lead to situations people don't immediately understand. I'm leaning towards prefering the current situation, but I thought this would be a good time to get your opinions on this. Cheers, Eelco
Re: svn commit: r545324 - in /incubator/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax: ./ form/
fix it! :)
On 6/10/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote:
* [EMAIL PROTECTED]:
> Author: jcompagner
> Date: Thu Jun 7 14:39:55 2007
> New Revision: 545324
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=545324
> Log:
> api cleanup and a refactor of some getCallbackScript methods.
> its now much more obvious what to call and what to override when you
want something. (success or failure scripts)
>
> Modified:
> incubator/wicket/trunk/jdk-1.4
/wicket/src/main/java/org/apache/wicket/ajax/AbstractAjaxTimerBehavior.java
> incubator/wicket/trunk/jdk-1.4
/wicket/src/main/java/org/apache/wicket/ajax/AbstractDefaultAjaxBehavior.java
> incubator/wicket/trunk/jdk-1.4
/wicket/src/main/java/org/apache/wicket/ajax/AjaxEventBehavior.java
> incubator/wicket/trunk/jdk-1.4
/wicket/src/main/java/org/apache/wicket/ajax/form/AjaxFormChoiceComponentUpdatingBehavior.java
> incubator/wicket/trunk/jdk-1.4
/wicket/src/main/java/org/apache/wicket/ajax/form/AjaxFormComponentUpdatingBehavior.java
> incubator/wicket/trunk/jdk-1.4
/wicket/src/main/java/org/apache/wicket/ajax/form/AjaxFormSubmitBehavior.java
>
> Modified: incubator/wicket/trunk/jdk-1.4
/wicket/src/main/java/org/apache/wicket/ajax/AbstractAjaxTimerBehavior.java
> URL:
http://svn.apache.org/viewvc/incubator/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AbstractAjaxTimerBehavior.java?view=diff&rev=545324&r1=545323&r2=545324
>
==
> ---
incubator/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AbstractAjaxTimerBehavior.java
(original)
> +++
incubator/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AbstractAjaxTimerBehavior.java
Thu Jun 7 14:39:55 2007
> @@ -81,16 +81,22 @@
>
> protected CharSequence getCallbackScript()
> {
> + return generateCallbackScript("wicketAjaxGet('"
> + + getCallbackUrl(onlyTargetActivePage()) +
"'");
> + }
> +
> + /**
> + * @see
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior#getPreconditonScript()
> + */
> + protected CharSequence getPreconditonScript()
There's a typo, should be getPrecondit*i*onScript() I guess
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: [vote] Release Apache Wicket 1.3.0-incubating-beta-2
wicket core shipping log4j? thats wrong anyway. only examples could include it. johan On 6/10/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote: What's the deal with http://svn.apache.org/viewvc/incubator/wicket/tags/wicket-1.3.0-incubating-b eta-2/licenses/log4j-license.txt?revision=545721&view=markup ? Log4J is an ASF project, and we have not permitted new code to go out with the old license for years. I checked pom.xml, and wicket uses Log4J 1.2.13. According to http://svn.apache.org/viewvc/logging/log4j/tags/v1_2_13/, that is under the current Apache License, not the old one. --- Noel
Re: [proposal] 1.3.0 end game
why would that be a problem for wicket the urls of wicket don't point to any files directly. But there are a lot of those (struts .do files??) so it seems that it first tries to resolve a jsp file before giving it to the filter? But how is that relevant for wicket? what does it first try to resolve? If that is the case that a filter only works for a request that maps to a real file then that websphere version should never be released. That seems to me like a major critical bug. but you can always use the wicket servlet. johan On 6/8/07, Sean Sullivan <[EMAIL PROTECTED]> wrote: Websphere 6.0.2.13 returns a 404 response for all of my requests. The root cause seems to be a bug in Websphere's servlet container. The bug is documented here: http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg1PK27620 I'm the process of upgrading to Websphere 6.0.2.17. I'll let you know if the problem goes away. Sean On 6/8/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote: > > > > Sean Sullivan-3 wrote: > > > > FYI --- I'm still having serious trouble with Wicket 1.3 in Websphere > 6.0. > > I am debugging the issue and > > I'll open a JIRA issue this morning. > > > > Sean > > > > What issues are you having ? > We are running Wicket 1.3 on WebSphere 6 (using OSGI BridgeServlet). > > Jan. > >
Re: [proposal] 1.3.0 end game
can't we do an RC at the moment we graduate? (a bit more fuss then?) Also we can try to have only 1 or 2 release candidates so that the release is a bit earlier.. johan On 6/7/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: This is the proposal for our end game to a final release of Wicket 1.3.0 - build 1.3.0-beta 2 this weekend, release next week - after the 20th start work on release candidates: These will not be official releases, because I want to move quickly on these builds. So at least once every week we (I?) will publish a new release on people.apache.org. We will hold a vote on whether the released packages will be the final version, or a new release is necessary. Schedule: 6/09 release beta 2 6/15 make beta 2 available for general public, if PPMC and IPMC don't object 6/20 board@ meeting, graduate? 6/23 build rc1 6/26 vote: make rc1 final, or build a new one 6/30 build rc2 7/03 vote: make rc2 final, or build a new one 7/07 build rc3 7/10 vote: make rc3 final, or build a new one 7/14 give up Any one have other/better/alternative ideas? Martijn -- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
Re: messy api of AbstractDefaultAjaxBehavior (and AbstractAjaxBehavior)
if (decorator != null)
{
failure = decorator.decorateOnFailureScript(failure);
}
AppendingStringBuffer buff = new AppendingStringBuffer(256);
buff.append("var ").append(IAjaxCallDecorator.WICKET_CALL_RESULT_VAR
).append("=");
buff.append(partialCall).append(", function() { ").append(success);
buff.append("}.bind(this), function() {
").append(failure).append("}.bind(this)");
if (precondition != null)
{
buff.append(", function() {");
buff.append(precondition);
buff.append("}");
}
buff.append(");");
CharSequence call = buff;
if (!Strings.isEmpty(indicatorId))
{
call = new
AppendingStringBuffer("wicketShow('").append(indicatorId).append("');")
.append(call);
}
if (decorator != null)
{
call = decorator.decorateScript(call);
}
return call;
}
/**
*
* @return String
*/
private String findIndicatorId()
{
if (getComponent() instanceof IAjaxIndicatorAware)
{
return
((IAjaxIndicatorAware)getComponent()).getAjaxIndicatorMarkupId();
}
if (this instanceof IAjaxIndicatorAware)
{
return ((IAjaxIndicatorAware)this).getAjaxIndicatorMarkupId();
}
Component parent = getComponent().getParent();
while (parent != null)
{
if (parent instanceof IAjaxIndicatorAware)
{
return
((IAjaxIndicatorAware)parent).getAjaxIndicatorMarkupId();
}
parent = parent.getParent();
}
return null;
}
/**
* @see wicket.behavior.IBehaviorListener#onRequest()
*/
public final void onRequest()
{
AjaxRequestTarget target = new AjaxRequestTarget();
RequestCycle.get().setRequestTarget(target);
respond(target);
}
/**
* @param target
*The AJAX target
*/
// TODO rename this to onEvent or something? respond is mostly the same
as
// onRender
// this is not the case this is still the event handling period. respond
is
// called
// in the RequestCycle on the AjaxRequestTarget..
protected abstract void respond(AjaxRequestTarget target);
/**
* Wraps the provided javascript with a throttled block. Throttled
behaviors
* only execute once within the given delay even though they are
triggered
* multiple times.
*
* For example, this is useful when attaching an event behavior to the
* onkeypress event. It is not desirable to have an ajax call made every
* time the user types so we throttle that call to a desirable delay,
such
* as once per second. This gives us a near real time ability to provide
* feedback without overloading the server with ajax calls.
*
* @param script
*javascript to be throttled
* @param throttleId
*the id of the throttle to be used. Usually this should
remain
*constant for the same javascript block.
* @param throttleDelay
*time span within which the javascript block will only
execute
*once
* @return wrapped javascript
*/
public static final CharSequence throttleScript(CharSequence script,
String throttleId,
Duration throttleDelay)
{
if (Strings.isEmpty(script))
{
throw new IllegalArgumentException("script cannot be empty");
}
if (Strings.isEmpty(throttleId))
{
throw new IllegalArgumentException("throttleId cannot be
empty");
}
if (throttleDelay == null)
{
throw new IllegalArgumentException("throttleDelay cannot be
null");
}
return new AppendingStringBuffer("wicketThrottler.throttle(
'").append(throttleId).append(
"', ").append(throttleDelay.getMilliseconds()).append(",
function() { ").append(
script).append("});");
}
}
On 6/7/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
Hi,
i like to do a bit of refactor on the AbstractDefaultAjaxBehavior class
because i find the api very messy and what to implement or what to call is
very hard to understand
First what we have now:
AbstractAjaxBehavior had 2 methods:
getCallBackUrl() and getCallBackUrl(boolean)
thats all fine, now i move to the subclass
AbstractDefaultAjaxBehavior does have a getCallbackScript() and
getCallbackScript(boolean)
which is sort of the same thing as getCallBackUrl() but they encapsulate
it
until now its still good but.
besides that we have in AbstractDefaultAjaxBehavior:
protected CharSequence getCallbackScript(final CharSequence partialCall,
final CharSequence onSuccessScript, final CharSequence onFailureScr
messy api of AbstractDefaultAjaxBehavior (and AbstractAjaxBehavior)
Hi,
i like to do a bit of refactor on the AbstractDefaultAjaxBehavior class
because i find the api very messy and what to implement or what to call is
very hard to understand
First what we have now:
AbstractAjaxBehavior had 2 methods:
getCallBackUrl() and getCallBackUrl(boolean)
thats all fine, now i move to the subclass
AbstractDefaultAjaxBehavior does have a getCallbackScript() and
getCallbackScript(boolean)
which is sort of the same thing as getCallBackUrl() but they encapsulate it
until now its still good but.
besides that we have in AbstractDefaultAjaxBehavior:
protected CharSequence getCallbackScript(final CharSequence partialCall,
final CharSequence onSuccessScript, final CharSequence onFailureScript)
and
protected CharSequence getCallbackScript(final CharSequence
partialCall,final CharSequence onSuccessScript, final CharSequence
onFailureScript,final CharSequence precondition)
and thats a bit funny,what does have the boolean one in common with the
other 2??
and what method do i have to implement to get a precondition in the right
place?
what do i need to call then afterwards.
i think this would be much better:
this stays the same:
protected CharSequence getCallbackScript()
{
return getCallbackScript(false);
}
this:
protected CharSequence getCallbackScript(boolean onlyTargetActivePage)
{
return getCallbackScript("wicketAjaxGet('"+
getCallbackUrl(onlyTargetActivePage) + "'", null, null);
}
should become:
protected CharSequence getCallbackScript(boolean onlyTargetActivePage)
{
return getCallbackScript("wicketAjaxGet('"+
getCallbackUrl(onlyTargetActivePage) + "'", getSuccessScript(),
getFailureScript(),getPreconditonScript());
}
This one can be removed then:
protected CharSequence getCallbackScript(final CharSequence
partialCall,final CharSequence onSuccessScript, final CharSequence
onFailureScript)
And this one can (doesn't have to be but i guess api wise it is a bit
better) be made final
protected CharSequence getCallbackScript(final CharSequence
partialCall,final CharSequence onSuccessScript, final CharSequence
onFailureScript, final CharSequence precondition)
and i would like to rename it to generateCallBackScript()
because it is not really in line with the 2 other once (no param and boolean
param)
and we add 4 extra methods:
getSuccessScript(), getFailureScript(),getPreconditonScript()
that by default just return null;
Then if you want a successscript or precondition script you just implement
those getters.
johan
Re: wicketstuff server down often?
it doesn't seem to be the jdk the complete hangs also seem to come from bamboo i am currently in contact with them and i hope they can fix it in the next release johan On 6/7/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote: * Eelco Hillenius: > Some people were complaining that the wicketstuff.org server was > down quite a bit. Anyone (Johan, Jan) has an idea why? Could it > be bamboo? I discussed this with Johan, and he told me wicketstuff.org uses FreeBSD's native jdk1.5. I advised to use diablo-jdk1.5 that is known to be more reliable, it is a binary version that could finally be distributed after negotiations between the FreeBSD foundation and Sun as the latter is not providing binaries for FreeBSD. I have my personal server running on FreeBSD and it is much more reliable with Diablo JDK. If you want I can go on and make the change to see if it helps, I have access to wicketstuff.org now. Or if you want to give it a try, just do this: $ cd /usr/ports/java/diablo-jdk15 $ make install Then you just need to use the "java" command from /usr/local/diablo-jdk1.5 Cheers, -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: ExternalLink.setOutputMarkupId has no effect
i fixed it for thrunk if you want a fix for 1.2.7 then please add a jira request for that. johan On 6/7/07, Johannes Fahrenkrug <[EMAIL PROTECTED]> wrote: Hi, I ran into something concerning ExternalLink and setOutputMarkupId. ExternalLink.setOutputMarkupId(true) has no effect. I could track this issue down to super.onComponentTag not being called at the end of ExternalLink's onComponentTag. Adding super.onComponentTag(tag); to the end of ExternalLink's onComponentTag would call Component's onComponentTag which in turn would add the markup id. Should I open a bug report for this? (I'm using 1.2.6, but I just checked the version in trunk and it seems to have the same problem, although I didn't try it) - Johannes -- Johannes Fahrenkrug Tel:+49 (0)431 5446 246 Fax:+49 (0)431 5446 248 E-Mail: [EMAIL PROTECTED] Gebeco GmbH & Co KG Holzkoppelweg 19 D-24118 Kiel Handelsregister Kiel Nr. A 3964 Steuernummer: 19 285 65407 Geschaeftsfuehrung: Ury Steinweg, Vorsitzender der Geschaeftsfuehrung Thomas Bohlander Besuchen Sie uns auch unter / we are also available at: www.gebeco.de oder www.drtigges.de
Re: CompoundPropertyModel#detach should check for IDetachable instead of IModel
fine by me i think its a bit better why test for more if you call on less... On 6/6/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: All, I'm not sure the usecase is general, but in our application we have a couple of classes that implement IDetachable, but not IModel, and these are put into a CompoundPropertyModel The thing is that the CompoundPropertyModel does an instanceof check for IModel instead of the slightly more general IDetachable. Are there any objections to changing that check to IDetachable instead of IModel? Martijn -- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
Re: wicketstuff server down often?
ok that T 5 seem to work better
But i now have a stack dump and it seems that there is a deadlock in bamboo
that causes first 2 threads to hang and then others hang on one other lock
that first 2 also locks
and those all have already a hibernate session. So then the rest keeps
hanging because the connections are exhausted.
johan
On 6/5/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
ok i now do
wget -T 5 -O - -o /dev/null --proxy=off
http://${HOST}:${PORT}/isalive.html
see if that helps
On 6/5/07, Johan Compagner < [EMAIL PROTECTED]> wrote:
>
> i think we are running constantly out of perm space heap
> why that is i don't know because the examples are already manual
> deployed now (running a script by hand)
> it is just restarted and the perm space is 100MB
> it can grow to 150MB at the moment and i think it slowly does that
>
> i have a script running that triggers this:
>
> http://wicketstuff.org/isalive.html
>
> if that doesn't work the tomcat is auto restarted.
> The problem is that sometimes the wget to that url just never times out
> (or very very very late)
> it just hangs on it. So the tomcat server doesn't get started
> anybody knows the wget command that it times out much earlier?
>
> johan
>
>
> On 6/5/07, Eelco Hillenius < [EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > Some people were complaining that the wicketstuff.org server was down
> > quite a bit. Anyone (Johan, Jan) has an idea why? Could it be bamboo?
> > Or do we do hot deploys of the examples project everytime it is
> > rebuild?
> >
> > Eelco
> >
>
>
Re: wicketstuff server down often?
ok i now do
wget -T 5 -O - -o /dev/null --proxy=off http://${HOST}:${PORT}/isalive.html
see if that helps
On 6/5/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
i think we are running constantly out of perm space heap
why that is i don't know because the examples are already manual deployed
now (running a script by hand)
it is just restarted and the perm space is 100MB
it can grow to 150MB at the moment and i think it slowly does that
i have a script running that triggers this:
http://wicketstuff.org/isalive.html
if that doesn't work the tomcat is auto restarted.
The problem is that sometimes the wget to that url just never times out
(or very very very late)
it just hangs on it. So the tomcat server doesn't get started
anybody knows the wget command that it times out much earlier?
johan
On 6/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Some people were complaining that the wicketstuff.org server was down
> quite a bit. Anyone (Johan, Jan) has an idea why? Could it be bamboo?
> Or do we do hot deploys of the examples project everytime it is
> rebuild?
>
> Eelco
>
Re: wicketstuff server down often?
i think we are running constantly out of perm space heap why that is i don't know because the examples are already manual deployed now (running a script by hand) it is just restarted and the perm space is 100MB it can grow to 150MB at the moment and i think it slowly does that i have a script running that triggers this: http://wicketstuff.org/isalive.html if that doesn't work the tomcat is auto restarted. The problem is that sometimes the wget to that url just never times out (or very very very late) it just hangs on it. So the tomcat server doesn't get started anybody knows the wget command that it times out much earlier? johan On 6/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: Hi, Some people were complaining that the wicketstuff.org server was down quite a bit. Anyone (Johan, Jan) has an idea why? Could it be bamboo? Or do we do hot deploys of the examples project everytime it is rebuild? Eelco
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
> But i also need it for other stuff that are specific to specific > implementations of certain things > for example the AccessStackStore doesn't need such a thread locale but SLC > does.. Fair enough. So you would use such a 'bag' in request cycle to store stuff like dirtyObjects (session)? Aren't you afraid this will open up a new can of worms (users misusing this facility rather then providing their own request cycle implementation for instance)? Isn't that the problem we also should then have on Session or Component? And i don't see it miss used a lot (at least all the examples i get from people here on the lists/web) also don't think that will happen a lot because most people (you and me included!) like to have a simple get/setter. But the problem is that we as the framework just can't do that for specific/default implementations of stuff. Then Requestcycle would become polluted. The nice thing about metadata is (compare to a pure put/get like hashmap) then they can be generified so with java5 you don't have to cast
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
don't we pretty much already have that map? RequestCycle.get().getRequest().getRequestParameters().getParameters() that one is parsed in the first step. (but mutable) but that one is going into the PAgeParameters except that PP has a little bit more that is not done in the first step but in the second one of the request cycle because bookmarkable mounts can introduce any kind of parameters from the url. and this is done in more then one place So the only thing i see to really do it right is to make sure that our base page has a PageParameters constructor and users should call that super() so that we can set the real one in the request cycle johan On 6/4/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: Sorry, but I don't agree. I think it's YAGNI. Metadata is a bit uglier to read (at least the code to access it), it's harder to trace in the debugger and just less obvious. I actually don't think it would be that out of place to put the (immutable instance of) request parameters as parsed in the first step of request cycle processing in the request. Eelco On 6/4/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > On 6/4/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > i am getting a bit tired of all those threadlocals that have to be > > > cleaned... I already discussed this with matej and i thing we should > > > give the RequestCycle metadata... then we can store any thing we want > > > and it is auto cleanup > > > > Agreed. RequestCycle currently doesn't have metadata though. What's > > the advantage of using meta data there instead of a normal property? I > > think none... > > I think the advantage of metadata is to have less tight coupling of > other parts to the request cycle. We are going to use the request > cycle as a Bag of stuff, which is needed during RC processing, but > don't have a direct relationship to the RC, other than that it is part > of the RC. > > Having a metadata facility in the RC will facilitate this, and not > make the RC 'bloated'. > > Just thinking out loud. > > Martijn > > -- > Join the wicket community at irc.freenode.net: ##wicket > Wicket 1.2.6 contains a very important fix. Download Wicket now! > http://wicketframework.org >
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
the second level cache has now a thread local Session has 2 thread locals especially the first one of the SLC do you really want to have a property on the RequestCycle for that? then you get really strange coupling. i am not talking about the PageParameters. That could maybe go into the request cycle because that is pretty much core (is it web only or not??) But i also need it for other stuff that are specific to specific implementations of certain things for example the AccessStackStore doesn't need such a thread locale but SLC does.. johan On 6/4/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > i am getting a bit tired of all those threadlocals that have to be > cleaned... I already discussed this with matej and i thing we should > give the RequestCycle metadata... then we can store any thing we want > and it is auto cleanup Agreed. RequestCycle currently doesn't have metadata though. What's the advantage of using meta data there instead of a normal property? I think none... Eelco
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
i am getting a bit tired of all those threadlocals that have to be cleaned... I already discussed this with matej and i thing we should give the RequestCycle metadata... then we can store any thing we want and it is auto cleanup On 6/4/07, Eelco Hillenius (JIRA) <[EMAIL PROTECTED]> wrote: [ https://issues.apache.org/jira/browse/WICKET-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501258 ] Eelco Hillenius commented on WICKET-605: The best hack I can currently imagine is to set the current PageParameters instance as a threadlocal somewhere (RequestCycle?) when the WebPage(PageParameters) constructor is called (btw, I see no reason why this constructor couldn't be moved to Page... we can do that regardless), and clean it up again in RequestCycle#detach. It would be yet another threadlocal unfortunately, but otoh it is valuable information to have accesible, which is hard to get to right now. WDYT? > Stataless form skips page parameters > > > Key: WICKET-605 > URL: https://issues.apache.org/jira/browse/WICKET-605 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: trunk > Environment: linux, glassfish v2 >Reporter: József Börcsök >Assignee: Eelco Hillenius > > Page parameters are not included in stataless form action parameter. > I think stateless form should override urlFor(RequestListenerInterface listener) method and append page parameters. (Submit works if I manually add them at runtime ie. with firebug plugin in browser.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r544015 - in /incubator/wicket/trunk: jdk-1.4/wicket/src/main/java/org/apache/wicket/ jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/resolver/ jdk-1.4/wicket/src/main/java/org/a
eelco is always blowing things way out proportions johan On 6/4/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote: * [EMAIL PROTECTED]: > Author: ehillenius > Date: Sun Jun 3 17:13:59 2007 > New Revision: 544015 > > URL: http://svn.apache.org/viewvc?view=rev&rev=544015 > Log: > simplified converterlocators by removing IConverterLocatorFactoryLocatorFactoryFactory. ^ Indeed, that seems to be a very complex interface, looking at its name!!! ;-) ;-) -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: svn commit: r544015 - in /incubator/wicket/trunk: jdk-1.4/wicket/src/main/java/org/apache/wicket/ jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/resolver/ jdk-1.4/wicket/src/main/java/org/a
it is harder now to specify converters on the session. (which we always had as far as i remember) because now you by pass that. Dont know if people did use that (session specific converters) This change did break my code (not to bad and they wheren't really session converters so thats not a problem for me) johan On 6/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: ehillenius Date: Sun Jun 3 17:13:59 2007 New Revision: 544015 URL: http://svn.apache.org/viewvc?view=rev&rev=544015 Log: simplified converterlocators by removing IConverterLocatorFactoryLocatorFactoryFactory. We really don't need that much indirection. Application now has overridable method newConverterLocator that is called during startup, and you can ask application to give the converter locator. If, for some super crazy reason, that's not enough indirection, it's easy for people to add a layer themselves. Removed: incubator/wicket/trunk/jdk-1.4 /wicket/src/main/java/org/apache/wicket/util/convert/ConverterLocatorFactory.java incubator/wicket/trunk/jdk-1.4 /wicket/src/main/java/org/apache/wicket/util/convert/IConverterLocatorFactory.java Modified: incubator/wicket/trunk/jdk-1.4 /wicket/src/main/java/org/apache/wicket/Application.java incubator/wicket/trunk/jdk-1.4 /wicket/src/main/java/org/apache/wicket/Component.java incubator/wicket/trunk/jdk-1.4 /wicket/src/main/java/org/apache/wicket/IConverterLocator.java incubator/wicket/trunk/jdk-1.4 /wicket/src/main/java/org/apache/wicket/Session.java incubator/wicket/trunk/jdk-1.4 /wicket/src/main/java/org/apache/wicket/markup/resolver/AutoComponentResolver.java incubator/wicket/trunk/jdk-1.4 /wicket/src/main/java/org/apache/wicket/model/AbstractPropertyModel.java incubator/wicket/trunk/jdk-1.4 /wicket/src/main/java/org/apache/wicket/settings/IApplicationSettings.java incubator/wicket/trunk/jdk-1.4 /wicket/src/main/java/org/apache/wicket/settings/Settings.java incubator/wicket/trunk/jdk-1.4 /wicket/src/main/java/org/apache/wicket/util/lang/PropertyResolver.java incubator/wicket/trunk/jdk-1.5 /wicket-jmx/src/main/java/org/apache/wicket/jmx/ApplicationSettings.java incubator/wicket/trunk/jdk-1.5 /wicket-jmx/src/main/java/org/apache/wicket/jmx/ApplicationSettingsMBean.java
Re: Please grant me some Confluence karma
not me. i didn't do anything with confluence on the wicket server i think igor? johan On 6/2/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: Who are the admins currently? Eelco On 6/2/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote: > I'd like to edit this page: > > http://wicketstuff.org/confluence/display/STUFFWIKI/Wiki > > This is restricted to group wicket-stuff-admin and I am in > confluence-users only. > > Thanks, > -- > Jean-Baptiste Quenot > aka John Banana Qwerty > http://caraldi.com/jbq/ >
Re: Nasty null value bug in AbstractTextComponent (TextField, etc.) - WICKET-606
yes it will break if the property resolves to a String the only fix is see quickly is to override getConverter in AbstractTextComponent like i described in the issue: http://issues.apache.org/jira/browse/WICKET-606 On 5/31/07, Al Maw <[EMAIL PROTECTED]> wrote: Hi folks, TextField should be (by default) converting empty strings to nulls. This is broken in trunk if your component uses an IObjectClassAwareModel (e.g. PropertyModel). This was presumably broken by the IObjectClassAwareModel stuff. ;-) http://issues.apache.org/jira/browse/WICKET-606 I'm busy for the rest of the day, but I'm sure this will be breaking lots of things for people, so someone needs to look into it ASAP. Best regards, Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com
Re: abbreviated stack traces
ahh sorry i meant printStackTrace() (and toString)
johan
On 5/31/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
that was a couple days ago. i will let you know if i repro.
the normal toString() does not give you the complete exception. it just
gives
you just the message string (see Throwable.java):
public String toString() {
String s = getClass().getName();
String message = getLocalizedMessage();
return (message != null) ? (s + ": " + message) : s;
}
this was the original point of Strings.toString(Throwable)... to give you
the complete trace for an exception object.
Johan Compagner wrote:
>
> why would we have a Strings.toString(Throwable) that gives you
everything?
> then the normal thing (toString of the exception) just works just as
fine.
>
> johan
>
>
>
> On 5/31/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> It might be good to be more defensive here then (as I think the trace I
>> got
>> had lost the info in both places): We could turn Strings.toString
>> (Throwable)
>> back into a simple version that always gives you the entire stack trace
>> (I
>> would really prefer that since this is supposed to be a generic
utility).
>> Then take the fancy version that's in the util package now and make a
>> private implementation detail of the exception page(s). That way
nobody
>> can
>> accidentally make the mistake of removing exception information from a
>> log
>> or the console.
>>
>>
>> Johan Compagner wrote:
>> >
>> > the full thing should go into the log
>> > i can't believe that that strings.toString(throwable) is used for
>> logging
>> > thats pure for our page itself i think
>> >
>> > johan
>> >
>> >
>> > On 5/31/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>> >>
>> >>
>> >>
>> >> This happened a few days ago, so I don't recall for sure, but I
>> believe
>> I
>> >> was missing information from the cause exception which would have
>> helped
>> >> me
>> >> diagnose my problem. There are two things I can think of that might
>> >> help.
>> >> We could: 1) take some extra precautions to only remove specific
stuff
>> we
>> >> know doesn't matter and 2) always print full stack traces to the
>> >> log/console
>> >> but put the abbreviated exception in the error page.
>> >>
>> >>
>> >> Johan Compagner wrote:
>> >> >
>> >> > Which part do you mis then?
>> >> > because the root isn't cut of:
>> >> > sb.append("Root cause:\n\n");
>> >> > outputThrowable(cause, sb, false); << false is don't
>> stop
>> >> at
>> >> > wicket servlet.
>> >> >
>> >> > all other causes do stop at the wicket servlet (but those are
mostly
>> >> just
>> >> > invocation target and so on)
>> >> >
>> >> > for all we just skip the: !(traceString.startsWith("sun.reflect.")
>> >> > so that we don't have all those reflection stacks in it that don't
>> give
>> >> > you
>> >> > any information then you already had.
>> >> >
>> >> > johan
>> >> >
>> >> >
>> >> > On 5/30/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >>
>> >> >> while i like shorter stack traces in some sense, i've run into a
>> >> couple
>> >> >> of
>> >> >> cases where the stack trace being shown by wicket cut out
important
>> >> >> information. could we review the code in Strings.toString
>> (Throwable)
>> >> to
>> >> >> make sure we're really doing the right thing here? i'd rather
have
>> >> too
>> >> >> much
>> >> >> stack trace information from wicket than lose a key piece of info
>> at
>> a
>> >> >> critical time. unless we can feel really sure we're not cutting
out
>> >> >> important information, i think we ought to err on the safe side.
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
>> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10895556
>> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10896903
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10899655
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
yes move the code thats now in internalInit to get the configuration type to application/webapplication. Was the proposal that we need to implement it always? and then do all the things themselfs what we do now? thats horrible johan On 5/31/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > Proposal: > = > I think we should have a pull model for this. In other words, we should > make Application#getConfigurationType() abstract and call that to get > the type. We then let people handle this however they want. I'm fine with that method, but why make it abstract? I think it's better to provide an implementation, which by default looks for the filter parameter and possibly - as an override - the system property. If people want to pin the type down, they can override the method and return what they like. Eelco
Re: abbreviated stack traces
why would we have a Strings.toString(Throwable) that gives you everything?
then the normal thing (toString of the exception) just works just as fine.
johan
On 5/31/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
It might be good to be more defensive here then (as I think the trace I
got
had lost the info in both places): We could turn Strings.toString
(Throwable)
back into a simple version that always gives you the entire stack trace (I
would really prefer that since this is supposed to be a generic utility).
Then take the fancy version that's in the util package now and make a
private implementation detail of the exception page(s). That way nobody
can
accidentally make the mistake of removing exception information from a log
or the console.
Johan Compagner wrote:
>
> the full thing should go into the log
> i can't believe that that strings.toString(throwable) is used for
logging
> thats pure for our page itself i think
>
> johan
>
>
> On 5/31/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> This happened a few days ago, so I don't recall for sure, but I believe
I
>> was missing information from the cause exception which would have
helped
>> me
>> diagnose my problem. There are two things I can think of that might
>> help.
>> We could: 1) take some extra precautions to only remove specific stuff
we
>> know doesn't matter and 2) always print full stack traces to the
>> log/console
>> but put the abbreviated exception in the error page.
>>
>>
>> Johan Compagner wrote:
>> >
>> > Which part do you mis then?
>> > because the root isn't cut of:
>> > sb.append("Root cause:\n\n");
>> > outputThrowable(cause, sb, false); << false is don't stop
>> at
>> > wicket servlet.
>> >
>> > all other causes do stop at the wicket servlet (but those are mostly
>> just
>> > invocation target and so on)
>> >
>> > for all we just skip the: !(traceString.startsWith("sun.reflect.")
>> > so that we don't have all those reflection stacks in it that don't
give
>> > you
>> > any information then you already had.
>> >
>> > johan
>> >
>> >
>> > On 5/30/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>> >>
>> >>
>> >> while i like shorter stack traces in some sense, i've run into a
>> couple
>> >> of
>> >> cases where the stack trace being shown by wicket cut out important
>> >> information. could we review the code in Strings.toString
(Throwable)
>> to
>> >> make sure we're really doing the right thing here? i'd rather have
>> too
>> >> much
>> >> stack trace information from wicket than lose a key piece of info at
a
>> >> critical time. unless we can feel really sure we're not cutting out
>> >> important information, i think we ought to err on the safe side.
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
>> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10895556
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10896903
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: abbreviated stack traces
i am still very curious what you think you missed
please give me an example
johan
On 5/31/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
It might be good to be more defensive here then (as I think the trace I
got
had lost the info in both places): We could turn Strings.toString
(Throwable)
back into a simple version that always gives you the entire stack trace (I
would really prefer that since this is supposed to be a generic utility).
Then take the fancy version that's in the util package now and make a
private implementation detail of the exception page(s). That way nobody
can
accidentally make the mistake of removing exception information from a log
or the console.
Johan Compagner wrote:
>
> the full thing should go into the log
> i can't believe that that strings.toString(throwable) is used for
logging
> thats pure for our page itself i think
>
> johan
>
>
> On 5/31/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> This happened a few days ago, so I don't recall for sure, but I believe
I
>> was missing information from the cause exception which would have
helped
>> me
>> diagnose my problem. There are two things I can think of that might
>> help.
>> We could: 1) take some extra precautions to only remove specific stuff
we
>> know doesn't matter and 2) always print full stack traces to the
>> log/console
>> but put the abbreviated exception in the error page.
>>
>>
>> Johan Compagner wrote:
>> >
>> > Which part do you mis then?
>> > because the root isn't cut of:
>> > sb.append("Root cause:\n\n");
>> > outputThrowable(cause, sb, false); << false is don't stop
>> at
>> > wicket servlet.
>> >
>> > all other causes do stop at the wicket servlet (but those are mostly
>> just
>> > invocation target and so on)
>> >
>> > for all we just skip the: !(traceString.startsWith("sun.reflect.")
>> > so that we don't have all those reflection stacks in it that don't
give
>> > you
>> > any information then you already had.
>> >
>> > johan
>> >
>> >
>> > On 5/30/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>> >>
>> >>
>> >> while i like shorter stack traces in some sense, i've run into a
>> couple
>> >> of
>> >> cases where the stack trace being shown by wicket cut out important
>> >> information. could we review the code in Strings.toString
(Throwable)
>> to
>> >> make sure we're really doing the right thing here? i'd rather have
>> too
>> >> much
>> >> stack trace information from wicket than lose a key piece of info at
a
>> >> critical time. unless we can feel really sure we're not cutting out
>> >> important information, i think we ought to err on the safe side.
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
>> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10895556
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10896903
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
is fine by me as long as the current stuff keeps working like the system property which i use all the time because i always set it directly in deployment but in my launch configs i set it back with a system property johan On 5/31/07, Al Maw <[EMAIL PROTECTED]> wrote: Hi folks, I've been thinking a lot about this lately. Current issues: === - We default to DEVELOPMENT and we should make it more obvious that you should set DEPLOYMENT for production servers. - We currently provide the following methods to configure which mode you run in: - Set a System property. - Set a servlet context param. - Set a filter param. If you don't fit into any of those, it makes life difficult - you don't want to just call configure(DEPLOYMENT) in your init() method, because then configure() is called twice - once by Wicket internally, probably in default DEVELOPMENT mode, and once by you manually. This results in a bunch of DEVELOPMENT mode stuff running on your live environment, and it's not that obvious that this is what's going on. (See WICKET-6, where even JBQ doesn't seem to entirely get this.) To avoid this, you need to override internalInit(), which is a right pain, as although the one in WebApplication doesn't do much, the one in Application does (adds all the component resolvers, etc.) and you'd need to keep things in sync. Ugh. All the configure() methods are final, too, so it's not an option to munge the value and then call super() with it, either. Proposal: = I think we should have a pull model for this. In other words, we should make Application#getConfigurationType() abstract and call that to get the type. We then let people handle this however they want. Advantages: - More discoverable as it's an abstract method, like getHomePage(). - Much more flexible for configuration. - More "Wicket-like". - Less code for us to maintain. Disadvantages: - The 1.3 migration guide gets a little larger. ;-) Err, can I call a vote on this please? [ ] Yes, great idea, let's get it into 1.3.0-beta2 [ ] No, that's rubbish, because... Regards, Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com
Re: abbreviated stack traces
the full thing should go into the log
i can't believe that that strings.toString(throwable) is used for logging
thats pure for our page itself i think
johan
On 5/31/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
This happened a few days ago, so I don't recall for sure, but I believe I
was missing information from the cause exception which would have helped
me
diagnose my problem. There are two things I can think of that might help.
We could: 1) take some extra precautions to only remove specific stuff we
know doesn't matter and 2) always print full stack traces to the
log/console
but put the abbreviated exception in the error page.
Johan Compagner wrote:
>
> Which part do you mis then?
> because the root isn't cut of:
> sb.append("Root cause:\n\n");
> outputThrowable(cause, sb, false); << false is don't stop at
> wicket servlet.
>
> all other causes do stop at the wicket servlet (but those are mostly
just
> invocation target and so on)
>
> for all we just skip the: !(traceString.startsWith("sun.reflect.")
> so that we don't have all those reflection stacks in it that don't give
> you
> any information then you already had.
>
> johan
>
>
> On 5/30/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>>
>>
>> while i like shorter stack traces in some sense, i've run into a couple
>> of
>> cases where the stack trace being shown by wicket cut out important
>> information. could we review the code in Strings.toString(Throwable)
to
>> make sure we're really doing the right thing here? i'd rather have too
>> much
>> stack trace information from wicket than lose a key piece of info at a
>> critical time. unless we can feel really sure we're not cutting out
>> important information, i think we ought to err on the safe side.
>>
>> --
>> View this message in context:
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10895556
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: abbreviated stack traces
Which part do you mis then?
because the root isn't cut of:
sb.append("Root cause:\n\n");
outputThrowable(cause, sb, false); << false is don't stop at
wicket servlet.
all other causes do stop at the wicket servlet (but those are mostly just
invocation target and so on)
for all we just skip the: !(traceString.startsWith("sun.reflect.")
so that we don't have all those reflection stacks in it that don't give you
any information then you already had.
johan
On 5/30/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
while i like shorter stack traces in some sense, i've run into a couple of
cases where the stack trace being shown by wicket cut out important
information. could we review the code in Strings.toString(Throwable) to
make sure we're really doing the right thing here? i'd rather have too
much
stack trace information from wicket than lose a key piece of info at a
critical time. unless we can feel really sure we're not cutting out
important information, i think we ought to err on the safe side.
--
View this message in context:
http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: case insensitive check for attributes?
On 5/31/07, Al Maw <[EMAIL PROTECTED]> wrote:
As far as I can see, the only reasons not to lower-case stuff
automatically are that it's too magic and/or too expensive to check all
the attribute modifiers.
it isn't about the attribute modifiers..
if you create one like this: new AttributeModifier("onClick",)
then we do internally always just toLowerCase() on it (based on setting?)
that doesn't matter to much
The problem is the tag.getAttributes() map. so those comming from the markup
if we lower case the attribute modifier always and then we also lowercase
all the keys
that are in the attribute map of a tag that comes from the markup then the
problem is gone
And that lowercasing of all the tags attributes map is only done once
(loading the markup)
so that is not a problem.
ofcourse we could make this a setting:
boolan Settings.getLowerCaseAttributes() default = true
then we lower case all the attribute modifiers that are made and all the
markup attributes that we get from the markup.
As a slight aside, but related to the magic, I've long been confused by
AttributeModifier silently throwing things away if you omit the boolean
constructor param. It seems to confuse fresh Wicket developers. Does
anyone have a use-case for this? Why is it like that?
yeah that was something for way back.
thats why igor did make the SimpleAttributeModifier i think.
It is that markup can't be changed by the developer if the markup doesn't
specify it.
But i think this is just bogus. Developers want to do that a designer
doesn't have to
think about what a developer maybe want to do
So we can make that boolean by default true?
johan
Re: case insensitive check for attributes?
and when will html5 be a standard supported by all major browsers? will i still be programming then :) johan On 5/31/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: On 5/31/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > and it will make the output more xhtml Heh, the world is moving away from xhtml: html5 will be the next big thing. Even the w3c seems to think so. That said, lower casing attributes should not be a problem for html5 as well, iiuc. Martijn -- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
Re: case insensitive check for attributes?
see the thread :) that was my first idea (and also almaw) but the discussion was that we wanted to do this long before (wicket 0?) and then we concluded that we shouldn't alter the markup?? But making it all lowercase is still my prefference. It won't hurt as far as i know nobody and it will make the output more xhtml johan On 5/31/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: On 5/31/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > the problem that testing all these is not just very simple > Now it is just a hash lookup but then we need to iterate > over all the keys everytime and check for equals ignoring case. Can't we put them in there always using lower case? Martijn
Re: IllegalStateException in PageSerializingThread
hmmm now i am really going to make an extra method in Page: getPageMapName() because i really start to hate all those: page.getPageMap().getName() just to get the name... (and now causing this problem :( ) johan On 5/31/07, Jonathan Locke <[EMAIL PROTECTED]> wrote: This looks like a problem. PageSerializingThread definitely does not have a request cycle going and it's calling getPageMap. Has it already been fixed or should I report as a bug? [22:34:28] ERROR - Objects- Error serializing object class ... java.lang.IllegalStateException: you can only locate or create sessions in the context of a request cycle at org.apache.wicket.Session.findOrCreate(Session.java:250) at org.apache.wicket.Session.get(Session.java:284) at org.apache.wicket.PageMap.forName(PageMap.java:64) at org.apache.wicket.Page.getPageMap(Page.java:510) at org.apache.wicket.protocol.http.FilePageStore$SessionPageKey.( FilePageStore.java:312) at org.apache.wicket.protocol.http.FilePageStore$PageSerializer.serializePage (FilePageStore.java:831) at org.apache.wicket.Page.writeObject(Page.java:282) at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:589) at java.io.ObjectStreamClass.invokeWriteObject( ObjectStreamClass.java:945) at java.io.ObjectOutputStream.writeSerialData( ObjectOutputStream.java:1456) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java :1387) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java :1145) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java :1504) at java.io.ObjectOutputStream.writeSerialData( ObjectOutputStream.java:1469) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java :1387) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java :1145) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java :1504) at java.io.ObjectOutputStream.writeSerialData( ObjectOutputStream.java:1469) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java :1387) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java :1145) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java :1333) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java :1141) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java :1504) at java.io.ObjectOutputStream.writeSerialData( ObjectOutputStream.java:1469) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java :1387) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java :1145) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java :326) at java.util.ArrayList.writeObject(ArrayList.java:570) at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:589) at java.io.ObjectStreamClass.invokeWriteObject( ObjectStreamClass.java:945) at java.io.ObjectOutputStream.writeSerialData( ObjectOutputStream.java:1456) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java :1387) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java :1145) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java :1504) at java.io.ObjectOutputStream.writeSerialData( ObjectOutputStream.java:1469) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java :1387) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java :1145) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java :1504) at java.io.ObjectOutputStream.writeSerialData( ObjectOutputStream.java:1469) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java :1387) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java :1145) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java :1333) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java :1141) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java :1504) at java.io.ObjectOutputStream.writeSerialData( ObjectOutputStream.java:1469) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java :1387) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java :1145) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java :1504) at java.io.ObjectOutputStream.writeSerialData( ObjectOutputStrea
Re: case insensitive check for attributes?
the problem that testing all these is not just very simple Now it is just a hash lookup but then we need to iterate over all the keys everytime and check for equals ignoring case. So doing that in deployment mode is a bit to much (at least what i think) johan On 5/31/07, Timo Rantalaiho <[EMAIL PROTECTED]> wrote: On Wed, 30 May 2007, Johan Compagner wrote: > here we have a case that the design says one thing and the java code another > so its a mismatch > what should happen then? > Today maurice had such a case and that did cost him quite some time to track > down. > Maybe in development mode we test for it somehow and then throw an > exception? Or just throw an exception always -- is there any case in which you would want to have a differing case in markup than in code? - Timo -- Timo Rantalaiho Reaktor Innovations Oyhttp://www.ri.fi/ >
Re: case insensitive check for attributes?
hmm but that is not the right argument here i think (we shouldn't change because we shouldn't) here we have a case that the design says one thing and the java code another so its a mismatch what should happen then? Today maurice had such a case and that did cost him quite some time to track down. Maybe in development mode we test for it somehow and then throw an exception? johan On 5/30/07, Gwyn Evans <[EMAIL PROTECTED]> wrote: On Wednesday, May 30, 2007, 3:55:51 PM, Eelco <[EMAIL PROTECTED]> wrote: It's not on Nabble (too early) but it was "Attributes need to perserve case" from 06-Sep-2005 on [EMAIL PROTECTED] Let me know if you want a copy, but the summary was that Juergen suggested it wasn't really Wicket's place to modify them as it could be confusing, and no one disagreed. The 'issue' was 1286616 on SF - https://sourceforge.net/tracker/?func=detail&atid=684975&aid=1286616&group_id=119783 /Gwyn > I vaguely remember having a to-lowercase conversion build in around > Wicket 1.0. If it was removed again, we probably had a reason for it. > Did you search the mail archives? > Eelco > On 5/30/07, Johan Compagner <[EMAIL PROTECTED]> wrote: >> that would also be my fix. >> Just lower case everything once when loading and we are done. >> Then also lower case the AttributeModifiers and these problems are gone. >> >> does somebody disagree? >> >> johan >> >> >> On 5/30/07, Al Maw <[EMAIL PROTECTED]> wrote: >> > >> > Johan Compagner wrote: >> > > should we try to match case insenstive? Not it is just a ValueMap of >> > > attributes so the problem is that we then have to lowercase all the >> > > attributes keys >> > >> > H. XHTML says all the attributes should be lowercased, so I see no >> > particular problem with lowercasing everything in the markup loader, >> > aside from the extra overhead. Someone will doubtless complain, though. >> > >> > Regards, >> > >> > Al >> > >> > -- >> > Alastair Maw >> > Wicket-biased blog at http://herebebeasties.com >> > >> /Gwyn
Re: case insensitive check for attributes?
that would also be my fix. Just lower case everything once when loading and we are done. Then also lower case the AttributeModifiers and these problems are gone. does somebody disagree? johan On 5/30/07, Al Maw <[EMAIL PROTECTED]> wrote: Johan Compagner wrote: > should we try to match case insenstive? Not it is just a ValueMap of > attributes so the problem is that we then have to lowercase all the > attributes keys H. XHTML says all the attributes should be lowercased, so I see no particular problem with lowercasing everything in the markup loader, aside from the extra overhead. Someone will doubtless complain, though. Regards, Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com
case insensitive check for attributes?
i have this html:
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
">
http://www.w3.org/1999/xhtml";
xmlns:wicket="http://wicket.apache.org/
">
Insert title here
click
then this page:
public class CaseSensitiveAttributePage extends WebPage
{
public CaseSensitiveAttributePage()
{
add(new Label("click").add(new AttributeModifier("onclick",true,new
Model("test2();";
}
}
what should the output then be?
or if i do: add(new Label("click").add(new
AttributeModifier("onclick",false,new Model("test();"; // see the false
currently if we have a true (do append it) then we get:
which is wrong of course
with the false:
we don't add the attribute at all. (and it is mentioned in the html)
should we try to match case insenstive? Not it is just a ValueMap of
attributes so the problem is that
we then have to lowercase all the attributes keys
johan
Re: Please welcome Jean-Baptiste to the Wicket PPMC!!
JPQ is tha man! On 5/30/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: Close observers to our graduation proposal would already have noticed our newest member to the Wicket PPMC, but it is always a good time to celebrate happy events: Please join me in welcoming Jean-Baptiste Quenot to the Wicket PPMC. Congratulations Jean-Baptiste! Martijn -- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
Re: Build Failed
why would i do a text search? and yes i hate command line :) i just want TODO or TASK marker then its very easy to find in eclipse johan On 5/29/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote: * Martijn Dashorst: > When you comment such a failing test, then at the very least add the > class and method to the issue. Otherwise it will be HELL to find the > test again. Also, ensure that the method is commented with the JIRA > issue number. That's why I suggested to rename testXXX() to bugTestXXX(), see how it's easy to find it: $ cd wicket $ grep -rs bugTest src/test/java Whereas only commenting it makes it impossible to find it again. Am I the only command-line addict here? Come on you can also do a text search in Eclipse can't you? -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: Build Failed
but if you do that (give it that name) the build works right? so then the method isn't executed and its in the deep black hole where nobody is looking at it again.. failures can happen and if they don't show in the unit test i run (or bamboo runs) then i will not notice them and never do anything about it. about the current one. i think i will comment it out let one build pass and then enable the failure test again so that we do have a build for people that are testing against the snapshots johan On 5/28/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote: * Martijn Dashorst: > In Wicket development (on the core project), the unit tests > sometimes just don't run for a couple of days because they are > used as a method of communication: someone knows how to > reproduce a bug but doesn't know how to fix it. The unit test > exposing the bug is then committed, so that someone else can > look at it in due time. Mmm actually I don't really agree, making the build fail should not be intentional. We could have some convention like for example naming the failing unit test methods after bugTestXXX() instead of testXXX() to make it obvious that the test does not run and that there is a bug. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: Wicket graduation proposal passes the Incubator PMC
whoooho On 5/27/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: All, I just wanted to let you know that the Wicket graduation proposal has passed the Incuabator Project Committee and we will now propose the Board to establish Apache Wicket as a top level project. Congratulations to the Wicket community and we hope to get the approval at the next board meeting! Martijn -- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
Re: multiple IComponentResolvers
AlMaw also already looked at it: http://www.nabble.com/Chaining-IComponentResolvers-tf3803758.html#a10763056 is juergen around? johan On 5/28/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: Not sure whether someone was already looking at this, but currently org.apache.wicket.markup.html.basic.SimplePageTest#testRenderHomePage_7 is failing. The problem is that test 2 is resolved by WicketMessageTagHandler and thus not by RelativePathPrefixHandler. I'm not sure what the best solution is to this, but my first question is whether it is really a good idea to create auto components for all the tags we find that need to have the relative path fix in the first place. I understand we need to do this dynamically because of URL mounting and stuff, but can't we use for instance IResponseFilters for this problem instead? If I didn't overlook something, and the above thought is correct, the same goes for wicket:message tags. Do they really need to be resolved to components? I'm afraid those auto components can add up quite a bit when it comes to memory usage. WDYT? Eelco
Re: [jira] Reopened: (WICKET-588) continueToOriginalDestination / RestartResponseAtInterceptPageException with page parameters broken
but that should work fine because we make the redirect url context sensitive AlMaw?? On 5/24/07, Wouter de Vaal (JIRA) <[EMAIL PROTECTED]> wrote: [ https://issues.apache.org/jira/browse/WICKET-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wouter de Vaal reopened WICKET-588: --- The solution does not work when running in a context other than the root. So when signing in to path /myapp/admin/stuff the redirect after signin is to /admin/stuff, without the /myapp > continueToOriginalDestination / RestartResponseAtInterceptPageException with page parameters broken > --- > > Key: WICKET-588 > URL: https://issues.apache.org/jira/browse/WICKET-588 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta1 >Reporter: Wouter de Vaal > Assigned To: Johan Compagner > Fix For: 1.3.0-beta2 > > Attachments: patch.txt > > > I'm using the login/authorization strategy taken from the wicket > examples, which is > throw new RestartResponseAtInterceptPageException(SignIn.class); > in the application class and calling > continueToOriginalDestination() > in the login page. > However when I'm using a bookmarkable page with PageParameters, the > parameters get lost in the process.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (WICKET-271) investigate Ajax back button support
ahh i did read it wrong, maybe its my small screen (nokia 9300 with mobile gmail application) On 5/24/07, Al Maw <[EMAIL PROTECTED]> wrote: Johan Compagner wrote: > this wont be fixed for 1.3 at least i dont think so, we have support > for it on the serverside but no support on the client side yet Yep, that's why I removed 1.3.0 from the fix versions. ;-) Al
Re: [jira] Updated: (WICKET-271) investigate Ajax back button support
this wont be fixed for 1.3 at least i dont think so, we have support for it on the serverside but no support on the client side yet On 5/24/07, Alastair Maw (JIRA) <[EMAIL PROTECTED]> wrote: [ https://issues.apache.org/jira/browse/WICKET-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alastair Maw updated WICKET-271: Fix Version/s: (was: 1.3.0) (was: 2.0) > investigate Ajax back button support > > > Key: WICKET-271 > URL: https://issues.apache.org/jira/browse/WICKET-271 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Eelco Hillenius > > Investigate what we can do to support the back button with Ajax. Currently, we don't support versioning with Ajax, so the back button always takes you back to the location before the ajax calls. > See discussion here: http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Wicket supporting Java 1.4 until... ?
that will always work for wicket 1.3 On 5/23/07, Bruno Borges <[EMAIL PROTECTED]> wrote: supported = javac -target 1.4 -- Bruno Borges Summa Technologies Inc. www.summa-tech.com (48) 8404-1300 (11) 3055-2060 On 5/23/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > define 'supported' > > On 5/23/07, Bruno Borges <[EMAIL PROTECTED]> wrote: > > > > I'm just wondering if isn't a good idea to have Wicket been supported > > under > > 1.4 until Sun drops it. :) > > > > -- > > Bruno Borges > > Summa Technologies Inc. > > www.summa-tech.com > > (48) 8404-1300 > > (11) 3055-2060 > > > > On 5/23/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > > > really ? i thought sun wanted to have a cycle of 18 months for major > > > updates? > > > and 3/4 months for minor updates? > > > > > > johan > > > > > > > > > On 5/23/07, Bruno Borges <[EMAIL PROTECTED]> wrote: > > > > > > > > Danny Coward said at JavaOne that Java 7 will not be release before > > > 2009. > > > > With that in mind, lets remember that Sun only support the last 3 > > > versions > > > > of the Java Platform. So, we probably are going to have Java > > > 1.4available, > > > > supported and maintained until 2009. Will Wicket keep supporting > this > > > > version? > > > > > > > > []'s > > > > -- > > > > Bruno Borges > > > > Summa Technologies Inc. > > > > www.summa-tech.com > > > > (48) 8404-1300 > > > > (11) 3055-2060 > > > > > > > > > >
Re: Any documentation on how the wicketstuff.org server is set up?
everything you see is served by tomcat at this time, maybe i can split this up a bit. and i think we (igor and i) did fight with symlinks once before with the maven repository until igor was sick of it and just really made the maven repository directly a real dir of the maven webapp. johan On 5/23/07, Al Maw <[EMAIL PROTECTED]> wrote: Johan Compagner wrote: >> >> >> - Not serve up all the dependencies - we should just have >> org/apache/wicket/ and wicket/ in there. > > > hmm don't know how to do that directly > because we just share the local repository of maven > and bambo builds from that and deploys to it. > So i guess we need to somehow have 2? one that has all and one that has > only wicket? Hmmm. We probably need to have a for bamboo, which has a section that points to a local directory, which we serve as the maven repo, and then change the Bamboo builds to do a mvn deploy, not a mvn install. Or somewhat more simply, we could just create a parallel directory structure and symlink stuff: htdocs/ htdocs/wicket -> /home/foo/.m2/repository/wicket htdocs/org/ htdocs/org/apache/ htdocs/org/apache/wicket -> /home/foo/.m2/repository/org/apache/wicket (And make sure the Apache follow symlinks config directive is set.) Al
Re: Wicket supporting Java 1.4 until... ?
define 'supported' On 5/23/07, Bruno Borges <[EMAIL PROTECTED]> wrote: I'm just wondering if isn't a good idea to have Wicket been supported under 1.4 until Sun drops it. :) -- Bruno Borges Summa Technologies Inc. www.summa-tech.com (48) 8404-1300 (11) 3055-2060 On 5/23/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > really ? i thought sun wanted to have a cycle of 18 months for major > updates? > and 3/4 months for minor updates? > > johan > > > On 5/23/07, Bruno Borges <[EMAIL PROTECTED]> wrote: > > > > Danny Coward said at JavaOne that Java 7 will not be release before > 2009. > > With that in mind, lets remember that Sun only support the last 3 > versions > > of the Java Platform. So, we probably are going to have Java > 1.4available, > > supported and maintained until 2009. Will Wicket keep supporting this > > version? > > > > []'s > > -- > > Bruno Borges > > Summa Technologies Inc. > > www.summa-tech.com > > (48) 8404-1300 > > (11) 3055-2060 > > >
Re: Any documentation on how the wicketstuff.org server is set up?
- Not serve up all the dependencies - we should just have org/apache/wicket/ and wicket/ in there. hmm don't know how to do that directly because we just share the local repository of maven and bambo builds from that and deploys to it. So i guess we need to somehow have 2? one that has all and one that has only wicket? - Remove the 1.3-SNAPSHOT stuff (1.3.0-incubating-SNAPSHOT is current). No one should be using 1.3-SNAPSHOT; we should actively break this. i removed those. johan
Re: Wicket supporting Java 1.4 until... ?
really ? i thought sun wanted to have a cycle of 18 months for major updates? and 3/4 months for minor updates? johan On 5/23/07, Bruno Borges <[EMAIL PROTECTED]> wrote: Danny Coward said at JavaOne that Java 7 will not be release before 2009. With that in mind, lets remember that Sun only support the last 3 versions of the Java Platform. So, we probably are going to have Java 1.4available, supported and maintained until 2009. Will Wicket keep supporting this version? []'s -- Bruno Borges Summa Technologies Inc. www.summa-tech.com (48) 8404-1300 (11) 3055-2060
Re: Any documentation on how the wicketstuff.org server is set up?
Basically I just read a message that the maven repo for our snapshots at wicketstuff.org could be cleaned (to avoid problems with too many versions lying around). Can/should we rm -rf the whole repository prior to a wicket build? can bamboo run scripts already before building, last time i checked that wasn't really possible, And more: is there some documentation on how the server is set up, so that when Johan is on holiday someone else knows how to administer the thing? there is no doc but igor also knows it. And it is just tomcat and some webapps nothing more. johna
