RE: Converting Wicket Application to fat client (Swing/WebStart)

[Frank Silbermann]

Well, I started it 5 years ago when the policy on open source had not yet been 
nailed down. As I've been improving it since then and the production 
infrastructure group did not have servers to run it on, we been running it on 
dev/test machines, and production managers have nonetheless been making good 
use of it.

Since then, the architecture group has tightened their standards with two 
purposes in mind:
(1) Standardize the tool sets so that developers become a more easily 
replaceable commodity, and
(2) Satisfy the lawyers, who fear the implications of a rogue open-source 
license whose terms might put the company in legal trouble.

New government regulations are also forcing upper management to monitor 
software installations much more closely.  Therefore, any use of open source 
software must be approved by the architecture board, a board which is NOT 
responsible for our department's budget or convenience.  I have to consider the 
possibility that they will take a tough line.


Therefore, I'm trying to think of a back-up strategy in case they refuse to 
approve Wicket, which they might well do for the sake of reason (1), even if 
Apache's role in Wicket relieves concern (2).

I chose Wicket because the "standard" Java web frameworks then in existence 
horrified me (and still do).  Perhaps I should have used Java Swing with 
WebStart from the beginning, but I'd heard that 
WebStart still had problems.  (I expect it has been improved since then, but at 
this point I no longer care.)  I don't want a difficult rewrite, especially not 
one that forces me to give up the DRY (don't repeat yourself) principle.

Yeah, it might cost $8 million to re-implement Wicket in-house :-), but I was 
hoping that maybe it would be much cheaper to re-implement my base components 
in a fat-client technology -- since that would eliminate most of the problems 
Wicket was created to solve.
 
-Original Message-
From: Jeremy Thomerson [mailto:jer...@wickettraining.com] 
Sent: Monday, December 20, 2010 12:36 PM
To: users@wicket.apache.org
Subject: Re: Converting Wicket Application to fat client (Swing/WebStart)

On Mon, Dec 20, 2010 at 10:45 AM, Frank Silbermann
 wrote:
>
> I have a Wicket application at work that has been well-received by its 
> internal users.  Because I am not much of a web programmer, and because it is 
> for internal use only, I built a bunch of general-purpose panels and base 
> pages which I use to assemble the application-oriented pages using no 
> additional HTML.  Many of the general-purpose panels simply provide the HTML 
> for general purpose Wicket components (e.g. sets of radio-buttons and sets of 
> checkboxes) with a simplified API façade that provides only the flexibility 
> needed in my application.
>
> My application-oriented pages therefore emphasize the business logic, with 
> very little code whatsoever dealing with display logic.  Yes, the resulting 
> pages are ugly, but they are functional and reliable so my users don't care.
>
> Now I have a new requirement.  A group would like to use this application 
> with the proviso that no open-source software be used!  (They have a short 
> list of permitted exceptions containing standard stuff such as Struts.)  
> Since I chose Wicket so that I could use more-or-less a Swing style of 
> programming, I figured it would be easier to translate my application into a 
> fat-client application using Swing and deliver it via WebStart -- rather 
> than, say, re-implementing it in JSP or JFS. :-(

Then they don't want to use "this application".  They want a "new
application".  And the real problem is why do they say "no open-source
software"?  What I would do in this case is counter with a budget
proposal for the project.  Start off with "implement web framework
that works with "this application" from scratch since we can't use
open source software" == $8,428,748
(http://www.ohloh.net/p/wicket#cocomo).  Then add the other pieces
that you'll be replacing.

> There will only be a few users, and they work for the company; I'm not 
> terribly concerned about maximizing performance.
>
> Do you have any suggestions about the most straight-forward way of 
> translating a Wicket application to Swing?  I suppose that I would represent 
> each page as a JFrame, and each panel as a JPanel.
>
> In my panels I have a number of components (buttons, checkboxes, radio 
> buttons...), many (but not all) of which post back immediately on change, and 
> a very few AJAX components that redraw only a bit of the page.  What would be 
> the most direct method of modeling page post-back (and partial post-back, for 
> the AJAX components) in Swing?
>
> This question is kind of ironic, since Wicket was created to provide a more 
> Swing-li

Converting Wicket Application to fat client (Swing/WebStart)

[Frank Silbermann]

I have a Wicket application at work that has been well-received by its internal 
users.  Because I am not much of a web programmer, and because it is for 
internal use only, I built a bunch of general-purpose panels and base pages 
which I use to assemble the application-oriented pages using no additional 
HTML.  Many of the general-purpose panels simply provide the HTML for general 
purpose Wicket components (e.g. sets of radio-buttons and sets of checkboxes) 
with a simplified API façade that provides only the flexibility needed in my 
application.

My application-oriented pages therefore emphasize the business logic, with very 
little code whatsoever dealing with display logic.  Yes, the resulting pages 
are ugly, but they are functional and reliable so my users don't care.

Now I have a new requirement.  A group would like to use this application with 
the proviso that no open-source software be used!  (They have a short list of 
permitted exceptions containing standard stuff such as Struts.)  Since I chose 
Wicket so that I could use more-or-less a Swing style of programming, I figured 
it would be easier to translate my application into a fat-client application 
using Swing and deliver it via WebStart -- rather than, say, re-implementing it 
in JSP or JFS. :-(

There will only be a few users, and they work for the company; I'm not terribly 
concerned about maximizing performance.

Do you have any suggestions about the most straight-forward way of translating 
a Wicket application to Swing?  I suppose that I would represent each page as a 
JFrame, and each panel as a JPanel.

In my panels I have a number of components (buttons, checkboxes, radio 
buttons...), many (but not all) of which post back immediately on change, and a 
very few AJAX components that redraw only a bit of the page.  What would be the 
most direct method of modeling page post-back (and partial post-back, for the 
AJAX components) in Swing?

This question is kind of ironic, since Wicket was created to provide a more 
Swing-like approach to web programming, and now I'm wondering about Wicket-like 
approach to Swing programming!  :-)

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Need Wicket Book

[Frank Silbermann]

When I coded my application originally based on Wicket 1.2, I after looking at 
the DataTable example, I had to peruse the DataTable (and, for 1.2, 
DefaultDataTable) code to figure out what I needed to do for my task.

Even if I had had _Wicket_in_Action_ at my disposal back then, I think I still 
would have had to look at the DataTable implementation.

Perhaps with open source it is expected that users will have to look at the 
implementation code now and then, but I think for many people it is a 
psychological hurdle.  /Frank

-Original Message-
From: Martijn Dashorst [mailto:martijn.dasho...@gmail.com] 
Sent: Friday, November 12, 2010 8:57 AM
To: users@wicket.apache.org
Subject: Re: Need Wicket Book

On Fri, Nov 12, 2010 at 3:24 PM, Frank Silbermann
 wrote:
> Does any Wicket book describe the use of Wicket Extensions, such as
> DataTable?  I didn't see anything on that subject in _Wicket_in_Action_.

In order to keep the book manageable (in thickness) and to be able to
publish it on some derailed schedule, datatable and extensions friends
were not included. It would probably have costed another 20 pages or
so to properly discuss datatable, and another 20 to quickly summarize
each component in extensions.

We believe that the explanations offered in Wicket in Action should
provide anyone to fully grasp Wicket concepts and that should suffice
to have a really quick understanding of anything wicket extensions
throws at you (unless you look at modal window, or the tree components
;-)

Martijn

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Need Wicket Book

[Frank Silbermann]

Does any Wicket book describe the use of Wicket Extensions, such as
DataTable?  I didn't see anything on that subject in _Wicket_in_Action_.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Free wicket from component hierarchy hell

[Frank Silbermann]

What were the reasons for requiring the hierarchies to match in the
original design of Wicket?

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Free wicket from component hierarchy hell

[Frank Silbermann]

I don't understand your example.  You have two forms on one panel.  You
wish to move a field (of one of the forms?) to another panel.  Doesn't
that imply that you've taken the field out of the form?

-Original Message-
From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com]
On Behalf Of James Carman
Sent: Tuesday, November 09, 2010 10:34 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell

On Tue, Nov 9, 2010 at 11:10 AM, Carl-Eric Menzel
 wrote:
>
> I think you misunderstood Frank's point. Why are the components in a
> hierarchy in the first place, if the hierarchy can be changed without
> changing behavior or semantics? They can simply be flat in the parent
> then.
>

Say you have two forms on one panel (don't know if this is the best
example or not, but here goes).  You want to move a field from one
panel to another.  You'd have to do that in code with the traditional
approach.  With the "queued" approach, you'd just queue all your
components to the parent container and it would auto-add them to the
correct subcomponent as it finds them in the markup.

With this, the order does matter, though.  Suppose you had two
components you wanted to queue with the same id, completely different
components.  If you reverse their order, then they're auto-added in a
different order.



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Free wicket from component hierarchy hell

[Frank Silbermann]

If the component hierarchy can be changed without changing behavior or
semantics, then why are the components in a hierarchy to begin with?
Why aren't all the components being moved around already siblings at the
same level?  Does Wicket require that the order of sibling Wicket
components match the order at which simply HTML elements appear?

-Original Message-
From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com]
On Behalf Of James Carman
Sent: Tuesday, November 09, 2010 9:39 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell

I get what you're
saying about having to stick to the hierarchy when designing markup
files.  I just don't know whether this approach is the best or not.
Again, I really haven't had a chance to sit down and think it through.

>
> Sounds completely fair to me.
>

Why don't you put this work into wicketstuff (or flesh it out more
with Igor in his git repo first and then move it), so we can see what
it's all about and perhaps try it out for ourselves?

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Free wicket from component hierarchy hell

[Frank Silbermann]

Progress is made by people who have understanding, not by the ignorant.
You're not in a position to make suggestions about extending Wicket if
you don't yet understand how to use the powers it already has. 

-Original Message-
From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] 
Sent: Tuesday, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell

> So instead of asking, "How can we make Wicket different so that my
> problem will go away?" the proper question to try first is, "What is
the
> Wicket way of solving my problem?"

That's not how proggress is made...

**
Martin



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Free wicket from component hierarchy hell

[Frank Silbermann]

As an alternative, suppose that one's non-panel compound component
contained a map from wicket-id's to components.  The hierarchy could be
encoded in a lisp-like string; the component's constructor could parse
the string and create the component hierarchy to match.  The hierarchy
string could be a configuration property that the constructor looks up.

When you want to use the component on an HTML page whose wicket-ids are
embedded differently, set the configuration parameter to the desired
hierarchy string.

So instead of asking, "How can we make Wicket different so that my
problem will go away?" the proper question to try first is, "What is the
Wicket way of solving my problem?"

-Original Message-
From: Carl-Eric Menzel [mailto:cmen...@wicketbuch.de] 
Sent: Tuesday, November 09, 2010 9:12 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell

On Tue, 9 Nov 2010 14:21:46 +0200
Martin Makundi  wrote:

Here we finally come to an actual argument about this:

> Panel is not reusable enough because it has its own markup. If I
> override its markup, it stops working.

Frank wrote in another message how to deal with this case. I agree with
him and add: If your new panel is so different from the old panel that
it requires a different internal hierarchy, it's no longer the same
component. Use standard OO techniques to deal with it. Also, think
about whether your component design (as in what parts form a component,
and what parts don't) is correct. Seems to me that in such a case too
many things have been thrown together that should not be together.

Carl-Eric
www.wicketbuch.de

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Free wicket from component hierarchy hell

[Frank Silbermann]

Well then, why don't you have your base panel provide methods that
generate the individual components, with methods that implement
composite behaviors involving groups of components.

Your constructor can call the component-creation methods to assemble the
component hierarchy to match the HTML.

Then, when you want a panel with a different hierarchy you subclass the
panel, override the constructor to create the 2nd component hierarchy,
and provide the new panel its own HTML page.

If you don't like overriding the constructor along with the HTML, then
you can build some sort of configurable constructor-constructor.

/Frank

-Original Message-
From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] 
Sent: Tuesday, November 09, 2010 6:55 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell

Hi!

> Isn't this exactly the reason we've got CSS?

It's just the buzz, not the reality. Unfortunately often CSS "doesn't
quite cut it:
* http://blog.iconara.net/2007/09/21/the-failure-of-css/

> HTML shouldn't really be used for look&feel and the size and placement
of
> components can perfectly be defined using CSS classes.

In CSS the actual nesting of components plays a big role (div inside
float inside abs top 0px ul relative etc.).

If you want a professional finish, you will often need to pull
components around the layers for different display. Even trying to
pull one component will break wicket in strict hierarchy mode.

**
Martin

>
> Matt
>
> On 2010-11-09 13:34, Martin Makundi wrote:
>>
>> Also making skins for different devices / screen sizes becomes
easier.
>>
>> **
>> Martin
>>
>> 2010/11/9 Vitaly Tsaplin:

 In simple cases it makes no difference. It makes real difference
with
 some complex widgets (for example search components) that must be
 reused on many pages and they should render differently on each
page
 depending on how much space and what context they are in. I don't
like
 duplicating code even if it is gui code.
>>>
>>> Sounds like the first appealing argument slowly comming out of
>>> surrounding fuzz =)
>
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Estimated number of developers in the Wicket community

[Frank Silbermann]

Chris Colman  Tue, Sep 28, 2010 at 2:41
PM:
>>
>> The 'popularity' test is very vague but I understand it's purpose,
>> they want to ensure that they use products that are widely used
>> and have an active user community: which is very true of Wicket.
>> Does anyone have some numbers on this?  Like how many Wicket
developers
>> there are, or how many websites are Wicket driven? ...

Jeremy Thomerson  Tue, Sep 28, 2010 at 2:53
PM:
> There's no way to quantify this metric.  ... There is a page on
> the wiki that lists a fraction of the sites using Wicket.
> https://cwiki.apache.org/WICKET/websites-based-on-wicket.html

That page would help, but a mere fraction of the sites might give the
wrong idea.

Jeremy:
> Ultimately, I would direct them away from this.  It doesn't *actually*
> matter.  What matters is this (in roughly this order):
> 
>  1. Pick a technology that fits your needs
>  2. Pick a technology that is productive
>  3. Pick a technology that, when you hit a stumbling block, you can
get
> help with.
>
> You've already demonstrated one and two.

Not really.  He has yet to demonstrated that Wicket meets their
popularity needs.  In lieu of having them subscribe to the message list,
maybe he can direct them to the archived messages on Nabble.

Is there a way a program could extract a count of the participants (i.e.
distinct e-mail addresses) in the archived mailing list for a variety of
time periods (to show growth in user base)?


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Shared Components

[Frank Silbermann]

I don't understand the question.  I may be viewing the same web page as
you, but that doesn't mean we should share the same computer display
monitor.  If there are two copies of the display (yours and mine), then
there should be two copies of the display's components.

What's wrong with just building the model for each user's component
around the same application-scoped Java POJO?  (Of course, you might
have to synchronize concurrent access to it, but that's just standard
Java.)

On Thu, May 13, 2010 at 12:38 PM, Ayodeji Aladejebi
wrote:
>
> Please any concept of shared components in Wicket. If I have a
component
> that the content (model) will always be the same across all sessions
and
> users, is there a wicket api approach for ensuring we only have one of
such
> components throughout the application scope



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: UI Layout

[Frank Silbermann]

Single page versus multi-page application?

 

Some people build a single-page application in which panels are replaced
dynamically.  With this approach, the single page is analogous to a
Swing JFrame, to whom components are added and removed (or made visible
or invisible as needed).

 

Many people prefer to have separate pages for different functionality --
and this is necessary if the user is to be able to bookmark several
different pages.  To do this, many people use markup inheritance, in
which sub-pages inherit from the base page, and the sub-page mark-up is
combined with the base-page mark-up.  (Though it is to be generalized in
the future, I believe currently there can be only a single place in the
base page where the sub-page's components can go.)

 

 

I prefer to use a base page which contains one or more panels to be
defined by the sub-pages, via abstract panel-creation methods called by
the base page.  However, Wicket convention is to add components in the
page constructor, and calling an overridden method from a constructor is
bad.  (The overridden method will not be able to use anything set up in
the sub-page's constructor, due to the order in which constructors are
called.)  I solve this problem by making my base pages inherit from the
following:  

 

public class DelayedAssemblyWebPage extends WebPage {

protected boolean componentsAssembled = false;



@Override

protected void onBeforeRender() {

if ( !componentsAssembled ) {

try {

assembleComponents();

componentsAssembled = true;

} catch (Exception e) {

throw new RuntimeException(e);

}

}

super.onBeforeRender(); 

}

 

abstract protected void assembleComponents() throws Exception {}

}

 

So my application base page would look something like this:

 

public class MyApplicationBasePage extends DelayedAssemblyWebPage {


protected void assembleComponents() throws Exception {

// Add some components.

// Panels to be defined in subclasses are added 

// by calling:

//

// add( createPanel_A("a_wicket_id") );

//

// and

//

// add( createPanel_B("some_other_wicket_id") );

}

 

abstract protected Panel createPanel_A( String panelWicketID );

abstract protected Panel createPanel_B( String panelWicketID );

}

 

Concrete child pages would look something like this:

 

public class OneConcreteChildPage extends MyApplicationBasePage {



protected Panel createPanel_A( String panelWicketID ) {

 return new WhateverPanel(panelWicketID,...);

}

protected Panel createPanel_B( String panelWicketID ) {

 return new SomeOtherPanelType(panelWicketID, ...);

}  

}

 

This can be generalized in that the application base page can have
however many component-defining abstract methods you please.
Furthermore, one can generalize this to a page hierarchy of any depth,
since a semi-base page can define additional abstract methods to be
called by its implementation of createPanel_A() or createPanel_B().

 

-Frank

 

-Original Message-
From: nino martinez wael [mailto:nino.martinez.w...@gmail.com] 
Sent: Friday, February 26, 2010 7:50 AM
To: users@wicket.apache.org
Subject: Re: UI Layout

 

For me it seems it would very confusing if I only had one page. I'd
prefer

pages that are target against their specific functionality, keeping code

simpler. I'd still be using panels though, giving the benefit of ajax,
role

base plus all the other stuff.

 

my 2 centavos

-Nino

 

2010/2/26 Josh Kamau 

 

> Wicket offers high level of flexibility when it comes to page layout.
So i

> ask, what are the best practices? is it ok if i use panels only and
one

> main

> layout page?

> 

> Kind regards

> 

> Josh.

> 

RE: Offline capable web application

[Frank Silbermann]

Any application that executes _offline_ is not a _web_ application --
unless the system consists of a stand-alone application containing a web
server that runs on the client (e.g. via jetty) so that both client and
server are running on the same box.

Theoretically, a Wicket application that runs on a jetty server on the
client could synchronize itself, when possible, via non-Wicket web
services that run on the server.

But why go that route?  I'd build just an ordinary stand-alone client
application, e.g. using Java WebStart and Swing, that could optionally
connect to the server.  There's no need for Wicket on the server, since
the client would provide the user interface.  (The client would have to
do that, if it were to be able to run stand-alone.)


-Original Message-
From: Josh Kamau [mailto:joshnet2...@gmail.com] 
Sent: Friday, February 19, 2010 7:05 AM
To: users@wicket.apache.org
Subject: Offline capable web application

Hi guys;

I am working on an application that i want to enable to work offline. I
want
to use wicket for this. Any ideas. I would like uses to fill and submit
forms even when working offline and then the data is synchronised later.
Is
it possible? all manner of suggestions/links are welcome.

Regards.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Heap space issue

[Frank Silbermann]

I am monitoring a Wicket 1.4.5 application running on Tomcat 6.0 which
accesses a SQL Server 2000 database.  Periodically the application
becomes unresponsive due to a lack of heap space, and I have to bounce
Tomcat.  I'm trying to figure out what sort of errors could cause this
to happen.

Any suggestions?

I've looked in the Tomcat error logs, but the only errors I see prior to
the out-of-heapspace error are a small number of SQL errors that result
from bad input data.  The Wicket application handles these errors by
switching the user to a standard error page.  I suppose it's a bad
architecture to rely on SQL errors reported by the database rather than
checking the data, but does this result in a memory leak?

Frank Silbermann

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: New german Wicket book

[Frank Silbermann]

In das neues Deutsches Buch, benuezen die Examplaren Wicket 1.3 odor Wicket 
1.4?  Lernt man jedes ueber Repeaters (DataTable zum Beispiel)?

Frank Silbermann

-Original Message-
From: Carl-Eric Menzel [mailto:cmen...@wicketbuch.de] 
Sent: Tuesday, December 15, 2009 11:29 AM
To: users@wicket.apache.org
Subject: New german Wicket book

Hi Wicket devs and users,

I'm proud to announce the release of our new german-language Wicket
book:

"Wicket: Komponentenbasierte Webanwendungen in Java" by Roland Förther,
Carl-Eric Menzel and Olaf Siefart. Published by dpunkt Verlag (many
thanks to René Schönfeldt and the others at dpunkt). More information
is available at http://www.wicketbuch.de/.

A few words in german on availability:
Die Auslieferung an den Buchhandel hat gestern begonnen, bei den
meisten Händlern müßte das Buch Ende dieser Woche oder spätestens
Anfang nächster Woche verfügbar sein. Es sollte also zu Weihnachten
noch reichen :-)

Carl-Eric
-- 
Carl-Eric Menzel
Das neue deutschsprachige Wicketbuch:
 Wicket: Komponentenbasierte Webanwendungen in Java
 http://www.wicketbuch.de/

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Reused Component with a form inside another form

[Frank Silbermann]

HTML doesn't like forms inside of forms.  What don't you just create an
address panel that belongs inside a form, but which does not provide its
own form?

-Original Message-
From: Arnaud Garcia [mailto:arn...@imagemed-87.com] 
Sent: Monday, November 23, 2009 10:37 AM

...Patient has an Address.
Since an Address can be used somewhere else in the code, for adding a
new one, you  have to create a simple AdressPanel with a form
inside...

So, how can I reuse this component in the PatientPanel ? because in
this Panel I will also have a form, with also a submit button..
...but how the form can be merged ?

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: page without class

[Frank Silbermann]

I don't know, but I wouldn't be surprised if the answer is no.

A foundational assumption about the way Wicket works is that a WebPage
object would result from the combination of a WebPage class with a
matching HTML file.  When Wicket sees MyPage.html in MyPackage with no
matching class, it assumes the class is erroneously missing.  You want
instead that Wicket should assume the class:

package MyPackage
class MyPage extends org.apache.wicket.markup.html.WebPage {}

I don't think the convenience of avoiding this two-line MyPage.java file
justifies eliminating this error check.

I suppose Wicket could provide an API command to tell it to assume a
trivial MyPage.java for MyPage.html, but I don't think such an API call
would save you all that many keystrokes over the two-line class
definition. 

-Original Message-
From: fachhoch [mailto:fachh...@gmail.com] 
Sent: Friday, November 13, 2009 12:12 PM
To: users@wicket.apache.org
Subject: Re: page without class


I am asking about creating a wicket page without a  class , can I create
a  
org.apache.wicket.markup.html.WebPage  instance without any additional  
java file   just html  ?




insom wrote:
> 
> I believe you can do this if you change the Wicket filter mapping in
your
> web.xml to something other than /*. Then Tomcat will serve the page
and
> bypass Wicket entirely.
> 
> Dane
> 
> 
> On Fri, Nov 13, 2009 at 8:36 AM, fachhoch  wrote:
> 
>>
>> Ok I have to tell that page to my IApplicationSettings
>>
>>IApplicationSettings settings=
>> super.getApplicationSettings();
>>settings.setAccessDeniedPage(accessDeniedPage)
>> here accessDeniedPage page is a static html page and I dont need java
.
>>  I am talking about a wicket page without a class  just html  is it
>> possible
>> ?
>>
>>
>>
>> Pedro H. O. dos Santos wrote:
>> >
>> > Only put then on top-level directory of a web module.
>> > http://java.sun.com/javaee/5/docs/tutorial/doc/bnadx.html#bnadz
>> >
>> > On Fri, Nov 13, 2009 at 1:21 PM, tubin gen 
wrote:
>> >
>> >> can I create a page just with html  and not write class ? I need
some
>> >> static
>> >> html pages and writing java for those will be of no use .
>> >>
>> >
>> >
>> >
>> > --
>> > Pedro Henrique Oliveira dos Santos
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/page-without-class-tp26338268p26339453.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> 

-- 
View this message in context:
http://old.nabble.com/page-without-class-tp26338268p26340879.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Calling IN TO Wicket from JSP

[Frank Silbermann]

When working within Wicket, we need not concern ourselves with the raw content 
of the HttpServletRequest object, as our models are automatically updated with 
the contents.  However, I do believe Wicket provides you with the ability to 
read the HttpServletRequest object if you wish to do so.

Suppose that instead of providing your data as request parameters you POST your 
form to the Wicket page.  Then I imagine that your form data would be contained 
within the HttpServletRequest object -- and your wicket page could query it and 
obtain that data manually.  Further interactions with the user, then, would be 
through Wicket's native mechanisms.

Caution is that I've never done this -- I'm just speculating.

Frank Silbermann,   Memphis, Tennessee

On Thu, Nov 12, 2009 at 8:34 AM, Corbin, James  wrote:
> That is exactly the issue that is causing the problem and what I need
> clarification on how to do
>
> J.D.
>
> -----Original Message-
> From: Frank Silbermann [mailto:frank.silberm...@fedex.com]
> Sent: Thursday, November 12, 2009 9:23 AM
> To: users@wicket.apache.org
> Subject: RE: Calling IN TO Wicket from JSP
>
> The question, I think, is how to deliver request-specific parameters
> along with the URL to the Wicket page.  For example, if a form in a JSP
> page is to be processed by a Wicket page, how can the JSP's form data to
> be delivered to the Wicket page?
>
> Is that the question?
>
>> -Original Message-
>> From: Jeremy Thomerson [mailto:jer...@wickettraining.com]
>> Sent: Thursday, November 12, 2009 9:59 AM
>> To: users@wicket.apache.org
>> Subject: Re: Calling IN TO Wicket from JSP
>>
>> I guess a more concrete example from you would be helpful.  You should
> be
>> able to mount a page to a bookmarkable URL and then it will be easy to
>> create a URL to go into Wicket.
>
>
>>> -Original Message-
>>> From: Corbin, James [mailto:jcor...@iqnavigator.com]
>>> Sent: Wednesday, November 11, 2009 4:51 PM
>>> To: users@wicket.apache.org
>>> Subject: Calling IN TO Wicket from JSP
>>>
>>> Is it possible to build a wicket URL in a JSP that gets forwarded to
> and
>>> handle by the Wicket filter mechanism?
>>>
>>> This seems like it should be simple but doesn't appear to work right
> in
>>> 1.4.1.
>>>
>>> We build up a wicketized URL that makes it into the WicketFilter, but
>>> that filter strips all the request parameters.
>>>
>>> Any suggestions on how to approach redirecting from JSP into Wicket
>>> would be greatly appreciated.
>>>
>>> J.D. Corbin | IQNavigator, Inc. | Technology 6465 Greenwood Village
>>> Blvd, Suite 800, Centennial, CO  80111 | Office 303.563.1503 | Mobile
>>> 303.912.0958 | www.iqnavigator.com | jcor...@iqnavigator.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Calling IN TO Wicket from JSP

[Frank Silbermann]

The question, I think, is how to deliver request-specific parameters
along with the URL to the Wicket page.  For example, if a form in a JSP
page is to be processed by a Wicket page, how can the JSP's form data to
be delivered to the Wicket page?

Is that the question?

> -Original Message-
> From: Jeremy Thomerson [mailto:jer...@wickettraining.com] 
> Sent: Thursday, November 12, 2009 9:59 AM
> To: users@wicket.apache.org
> Subject: Re: Calling IN TO Wicket from JSP
> 
> I guess a more concrete example from you would be helpful.  You should
be
> able to mount a page to a bookmarkable URL and then it will be easy to
> create a URL to go into Wicket.


>> -Original Message-
>> From: Corbin, James [mailto:jcor...@iqnavigator.com]
>> Sent: Wednesday, November 11, 2009 4:51 PM
>> To: users@wicket.apache.org
>> Subject: Calling IN TO Wicket from JSP
>>
>> Is it possible to build a wicket URL in a JSP that gets forwarded to
and
>> handle by the Wicket filter mechanism?
>>
>> This seems like it should be simple but doesn't appear to work right
in
>> 1.4.1.
>>
>> We build up a wicketized URL that makes it into the WicketFilter, but
>> that filter strips all the request parameters.
>>
>> Any suggestions on how to approach redirecting from JSP into Wicket
>> would be greatly appreciated.
>>
>> J.D. Corbin | IQNavigator, Inc. | Technology 6465 Greenwood Village
>> Blvd, Suite 800, Centennial, CO  80111 | Office 303.563.1503 | Mobile
>> 303.912.0958 | www.iqnavigator.com | jcor...@iqnavigator.com

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: dynamic components

[Frank Silbermann]

Create a panel with dummy components (e.g. Label components where the
label is an empty string).  Later you can "replace" one or more of the
components.

One complication is that some wicket components (e.g. Image) need to be
attached to specialized HTML.  However, the basic principle still
stands.

-Original Message-
From: Gw [mailto:not4spamm...@gmail.com] 
Sent: Saturday, November 07, 2009 7:38 AM
To: users@wicket.apache.org
Subject: dynamic components

Hi people,

Does anyone know how to dynamically add components to a form?
The types and numbers of the components are arbitrary, and will be
determined programmatically.
In one page, the form may contain 1 textbox, 2 buttons. In another page,
it
may contain 2 textareas, 1 checkbox, and so on...

Perhaps there's a framework over Wicket for this?
Lots of thanks in advance for ur assist.

Regards,
Mike

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Glue for composing panels

[Frank Silbermann]

Michal, I adopted your idea, but with a variation.  It is something like:

// Use this instead of WebPage for any base page whose component-tree
// construction relies on abstract or overridable methods.
//
abstract class DelayedConstructionWebPage extends WebPage {

private Boolean componentsAssembled = false;

...(preserve the standard constructors of WebPage)...

// This method's implementation will build the component tree.
// It may freely call abstract or overridable methods.
//
abstract protected void assembleComponents();

// If you have any method which accesses a component,
// and which might be called before the first rendering,
// to ensure that the component exists you should insert
// a one-line call to assembleComponentsIfNecessary()
//
protected assembleComponentsIfNecessary() {
if ( !componentsAssembled ) {
assembleComponents();
componentsAssembled = true;
}
}

@Override
void onBeforeRender() {
assembleComponentsIfNecessary();
super.onBeforeRender(); 
}
}   

I believe this will minimize the boilerplate code in the classes that provide 
the actual business value.

-Original Message-
From: Michal Kurtak [mailto:michal.kur...@gmail.com] 
Sent: Monday, November 02, 2009 11:08 AM
To: users@wicket.apache.org
Subject: Re: Glue for composing panels

Yes Frank, model-setting method was just an example how to access a
component before onBeforeRender() executes.

I've only tried to point out that we set componentsAssembled = true in
assembleComponents() method. We call assembleComponents() from
get-method (for referenced component) to ensure that referenced
component has been created.

michal

...
> /Frank
>
> -Original Message-
> From: Michal Kurtak [mailto:michal.kur...@gmail.com]
> Sent: Monday, November 02, 2009 3:39 AM
> To: users@wicket.apache.org
> Subject: Re: Glue for composing panels
>
> Hi Frank,
>
> We use the same approach as you. We have found one disadvantage, which
> relates to references to components created by subclasses.
> I'll demostrate it (problem and solution) in the following example:
>
> class BasePage extends Page
> {
>   /** Component created by subclass */
>   private Component component;
>   private boolean componentsAssembled = false;
>
>    /** Let the assemple method to set componentsAssembled flag */
>    private void assembleComponents()
>    {
>        component = createComponent();
>        ...
>        componentsAssembled = true;
>    }
>
>    protected abstract Component createComponent();
>
>     @Override
>       void onBeforeRender() {
>               if ( !componentsAssembled ) {
>                       assembleComponents();
>               }
>               super.onBeforeRender(); // Or whatever else is needed
>       }
>
>   /** Method uses assambelComponents() to ensure, that component is created */
>   public Component getComponent()
>   {
>       if(component == null)
>       {
>              assembleComponents();
>       }
>       return component;
>   }
>
>   /** public method delegete to referenced component. Uses safe
> getComponent() method  */
>   public void setComponentModel(IModel model)
>   {
>     getComponent().setModel(model);
>   }
>
>
>
> michal
>
>
> 2009/10/29 Frank Silbermann :
>>
>> I was discussing glue for composing reusable panels into web pages on
>> the blog of Erik van Oosten
>> (http://blog.jteam.nl/2009/09/16/wicket-dos-and-donts/).
>>
>> I told him that my approach had been to create an abstract base page
>> that constructs the common elements while leaving place-holders for
>> page-specific panels by defining methods such as:
>>
>>        abstract Panel createUpperLeftPanel (String wicketID);
>>        abstract Panel createLowerRightPanel(String wicketID);
>>
>> and having the base page's constructor say things like:
>>
>>        Panel p1 = createUpperLeftPanel("a_wicket_id");
>>        add(p1);
>>        ...
>>        Add( createUpperRightPanel("another_wicket_id") );
>>
>> The child page's contribution would be the implementation of the
>> abstract methods.
>>
>> I explained that I preferred this to mark-up inheritance because I could
>> add to the base page in any number places (not just one place), the
>> compiler would tell the child-page writer exactly what panels were
>> needed, and most importantly, no additional mark-up whatsoever would
>> need to be associated with any of the child pages.  (Panel classes used
>> by the child page would of course have their associated mark-up.)
>>
&

RE: Glue for composing panels

[Frank Silbermann]

If I understand you correctly, Michal, you don't want to set the component's 
model once and for all as it is being created, and you're worried that the 
model-setting method might be called before the first onBeforeRender().

That's just an example, I guess, so perhaps the general concern is that you 
might need to access a component for whatever reason before the first call to 
onBeforeRender().

Therefore, _any_ attempt to access a component after constructors have 
terminated should trigger construction of the component tree if necessary.

Is that the idea?

It sure would be nice to have an honest to goodness post-constructors event on 
which I could hang the component tree creation -- then we wouldn't have to 
worry about this.

In my use of Wicket, I've always set a component's model at the time that 
component was created -- I've never had to swap out a model in a separate 
operation.  If the data to be displayed changes dynamically, I've always simply 
used a model which took that into account.

Is that just a different style of programming?  Or are there circumstances 
beyond my limited experience which would require one to access a component 
before the first call to onBeforeRender()?  

/Frank

-Original Message-
From: Michal Kurtak [mailto:michal.kur...@gmail.com] 
Sent: Monday, November 02, 2009 3:39 AM
To: users@wicket.apache.org
Subject: Re: Glue for composing panels

Hi Frank,

We use the same approach as you. We have found one disadvantage, which
relates to references to components created by subclasses.
I'll demostrate it (problem and solution) in the following example:

class BasePage extends Page
{
   /** Component created by subclass */
   private Component component;
   private boolean componentsAssembled = false;

/** Let the assemple method to set componentsAssembled flag */
private void assembleComponents()
{
component = createComponent();
...
componentsAssembled = true;
}

protected abstract Component createComponent();

 @Override
   void onBeforeRender() {
   if ( !componentsAssembled ) {
   assembleComponents();
   }
   super.onBeforeRender(); // Or whatever else is needed
   }

   /** Method uses assambelComponents() to ensure, that component is created */
   public Component getComponent()
   {
   if(component == null)
   {
  assembleComponents();
   }
   return component;
   }

   /** public method delegete to referenced component. Uses safe
getComponent() method  */
   public void setComponentModel(IModel model)
   {
 getComponent().setModel(model);
   }



michal


2009/10/29 Frank Silbermann :
>
> I was discussing glue for composing reusable panels into web pages on
> the blog of Erik van Oosten
> (http://blog.jteam.nl/2009/09/16/wicket-dos-and-donts/).
>
> I told him that my approach had been to create an abstract base page
> that constructs the common elements while leaving place-holders for
> page-specific panels by defining methods such as:
>
>        abstract Panel createUpperLeftPanel (String wicketID);
>        abstract Panel createLowerRightPanel(String wicketID);
>
> and having the base page's constructor say things like:
>
>        Panel p1 = createUpperLeftPanel("a_wicket_id");
>        add(p1);
>        ...
>        Add( createUpperRightPanel("another_wicket_id") );
>
> The child page's contribution would be the implementation of the
> abstract methods.
>
> I explained that I preferred this to mark-up inheritance because I could
> add to the base page in any number places (not just one place), the
> compiler would tell the child-page writer exactly what panels were
> needed, and most importantly, no additional mark-up whatsoever would
> need to be associated with any of the child pages.  (Panel classes used
> by the child page would of course have their associated mark-up.)
>
> Eric and others explained what a bad idea it is for constructors to call
> overridable methods -- they execute before the child-page's properties
> have been set.  I usually got away with this, but I admit I was burnt a
> few times.  Recently, I wondered whether there might be a simple fix for
> the constructor-calls-overridable-method problem, such as:
>
> (a) Move the base page's component tree construction out of the
> constructor, and put it into the method:
>
>        private void assembleComponents() {
>                ...
>        }
>
> (b) Add the property:
>
>        private boolean componentsAssembled = false;
>
> (c) Override as follows to construct the component tree after the class
> constructors finish:
>
>       �...@override
>        void onBeforeRender() {
>                if 

RE: Glue for composing panels

[Frank Silbermann]

Having sub-pages push components to the base page (where they will live
in a ListView) looks like an effective solution.

One advantage is that the writer of SubPage can add zero, one, or many
components to (in his example) leftNavChildren.  To do that with my
base-page-pull approach, the base page's abstract method would have to
return a type of, say, List.  Then the subpage's
implementation would have to return a list of the desired length (zero,
one, or many).

A minor disadvantage of John's push-approach is that the writer of the
child page would have to rely on base page documentation or code to know
that the base page can be extended in this way.  With my approach the
compiler figuratively rubs his nose in it.

Another difference is that, with John's push approach, the base page
writer must do four things for each point of extension:

(1) declare the RepeatingView variable
(2) add the repeating view in the base page constructor
(3) provide a method called by subpages to add a component
(4) provide a method called by subpages to get the component's wicket-id

In my base-page pull method, once you've invested in the small (but
nontrivial) complexity of moving component-tree creation out of the
constructor into the "protected void assembleComponents()" method, only
two steps are required for each point of extension:

(1) define the abstract method creating the component (or
List)
(2) call it in the base page's "void assembleComponents()" method. 

And perhaps the movement of component-tree construction from constructor
to "assembleComponents()" method could be done once and for all in a
base page of all base pages!

Since I'd want to follow this approach in panel construction as well as
page construction, I would have to move component-tree assembly to an
"assembleComponents()" method in my very own "BasePanel extends Panel"
class as well.

fs

-Original Message-
From: John Krasnay [mailto:j...@krasnay.ca] 
Sent: Thursday, October 29, 2009 2:47 PM
To: users@wicket.apache.org
Subject: Re: Glue for composing panels

Rather than having the base class "pull" in components from the
subclass,
recently I've been tackling this kind of problem by creating
RepeatingViews in
the base class and letting subclasses "push" components in by adding to
the
repeating view:


  


public class BasePage extends WebPage {
private RepeatingView leftNavChildren;
public BasePage() {
add(leftNavChildren = new RepeatingView("leftNavChild"));
}
protected void addLeftNavChild(Component child) {
leftNavChildren.add(child);
}
protected String newLeftNavChildId() {
return leftNavChildren.newChildId();
}
}

public class SubPage extends BasePage {
public SubPage() {
    addLeftNavChild(new MyNavPanel(newLeftNavChildId()));
}
}

jk

On Thu, Oct 29, 2009 at 01:50:06PM -0500, Frank Silbermann wrote:
> 
> I was discussing glue for composing reusable panels into web pages on
> the blog of Erik van Oosten
> (http://blog.jteam.nl/2009/09/16/wicket-dos-and-donts/).
> 
> I told him that my approach had been to create an abstract base page
> that constructs the common elements while leaving place-holders for
> page-specific panels by defining methods such as:
> 
>   abstract Panel createUpperLeftPanel (String wicketID);
>   abstract Panel createLowerRightPanel(String wicketID);
> 
> and having the base page's constructor say things like:
> 
>   Panel p1 = createUpperLeftPanel("a_wicket_id");
>   add(p1);
>   ...
>   Add( createUpperRightPanel("another_wicket_id") );
> 
> The child page's contribution would be the implementation of the
> abstract methods.
>  
> I explained that I preferred this to mark-up inheritance because I
could
> add to the base page in any number places (not just one place), the
> compiler would tell the child-page writer exactly what panels were
> needed, and most importantly, no additional mark-up whatsoever would
> need to be associated with any of the child pages.  (Panel classes
used
> by the child page would of course have their associated mark-up.)  
> 
> Eric and others explained what a bad idea it is for constructors to
call
> overridable methods -- they execute before the child-page's properties
> have been set.  I usually got away with this, but I admit I was burnt
a
> few times.  Recently, I wondered whether there might be a simple fix
for
> the constructor-calls-overridable-method problem, such as:
> 
> (a) Move the base page's component tree construction out of the
> constructor, and put it into the method:
> 
>   private void assembleComponents() {
&g

Glue for composing panels

[Frank Silbermann]

I was discussing glue for composing reusable panels into web pages on
the blog of Erik van Oosten
(http://blog.jteam.nl/2009/09/16/wicket-dos-and-donts/).

I told him that my approach had been to create an abstract base page
that constructs the common elements while leaving place-holders for
page-specific panels by defining methods such as:

abstract Panel createUpperLeftPanel (String wicketID);
abstract Panel createLowerRightPanel(String wicketID);

and having the base page's constructor say things like:

Panel p1 = createUpperLeftPanel("a_wicket_id");
add(p1);
...
Add( createUpperRightPanel("another_wicket_id") );

The child page's contribution would be the implementation of the
abstract methods.
 
I explained that I preferred this to mark-up inheritance because I could
add to the base page in any number places (not just one place), the
compiler would tell the child-page writer exactly what panels were
needed, and most importantly, no additional mark-up whatsoever would
need to be associated with any of the child pages.  (Panel classes used
by the child page would of course have their associated mark-up.)  

Eric and others explained what a bad idea it is for constructors to call
overridable methods -- they execute before the child-page's properties
have been set.  I usually got away with this, but I admit I was burnt a
few times.  Recently, I wondered whether there might be a simple fix for
the constructor-calls-overridable-method problem, such as:

(a) Move the base page's component tree construction out of the
constructor, and put it into the method:

private void assembleComponents() {
...
}

(b) Add the property:

private boolean componentsAssembled = false;

(c) Override as follows to construct the component tree after the class
constructors finish:

@Override
void onBeforeRender() {
if ( !componentsAssembled ) {
assembleComponents();
componentsAssembled = true;
}
super.onBeforeRender(); // Or whatever else is needed
}

Then component construction would wait until the properties in both the
parent and the subclass had been set.  I'd no longer have the problem
associated with calling abstract methods from the constructor.

Do you see any disadvantages to this approach? Is there a more
appropriate hook upon which to hang my base page's component-tree
assembly?

If it _is_ a good approach, is there any reason the Wicket designers
chose not to create an overrideable method in the Component class that
is called just once after constructors terminate, and tell developers
that this is where the component tree should be created?

/Frank

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Export Excel file containing string and rendered component

[Frank Silbermann]

I, too, am trying to have my application download MS Excel files.  Until now,
mine have contained the content of a DataTable, using the code I received
from the mailing list three years ago:

Button button = new Button("excelExport") {
public void onSubmit() {
getRequestCycle().setRequestTarget(
new ComponentRequestTarget(dataTable)
);
WebResponse wr = (WebResponse)getResponse();
wr.setContentType( "excel/ms-excel; name="+getMSExcelFilename() );
wr.setHeader( "content-disposition",
"attachment;filename="+getMSExcelFilename() );
}
};

The file downloaded contains an HTML fragment that both MS Excel and MS Word
can interpret, if one opens the resulting file in those applications.

Now my users told me they would like the download to contain not just the
data, but the date of its creation.  Is there an easy way to pre-pend an
arbitrary string to that HTML fragment?  I don't really understand the
details of Wicket's page rendering process, and looking at the classes I've
been using there don't seem to be any obvious hooks.




stream = class AbstractResourceStreamWriter()
{
  public void write(OutputStream output)
 {
   // do your writing
 }
}

 getRequestCycle().setRequestTarget(
 new ResourceStreamRequestTarget( stream ).setFileName(
"file.xls" )
);

johan


On Tue, Apr 1, 2008 at 9:31 AM,  wrote:

> Hello:
> I am trying to export dynamically generated excel file.
> The generator would send the file.xls to an OutputStream.
...

-- 
View this message in context: 
http://www.nabble.com/export-excel-file-via-an-OutputStream-tp16416239p23873774.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Change to PageParameters?

[Frank Silbermann]

In my Wicket 1.2 application I used PageParameters like a simple
HashMap, calling:
 
pageParameters.put(keyString, valueString)
 
and
 
String s = (String) pageParameters.get(keyString)
 
After upgrading to Wicket 1.3 the GET is causing a ClassCastException:
[Ljava.lang.String; cannot be cast to java.lang.String
 
I didn't read anything about PageParameters in
http://cwiki.apache.org/WICKET/migrate-13.html
 
What change should I make to my code?  Would I simply replace "(String)
pp.get(x)" with "pp.getString(x)"?

RE: How to indicate dependency on a .war file?

[Frank Silbermann]

OK, so I need to package my dependency as a JAR file because I need to
add it to my classpath in Eclipse.

I am not sure how the war overlay tool will help me; it seems to be used
for getting resources out of a .war file, and we've concluded that I
need a JAR file, right?  Is there an easy way to tell Maven to create
both a JAR and a WAR file from the same codebase?

Or, perhaps if I am satisfied to test the common code in Eclipse via
Jetty I don't need to create a WAR file at all? 

-Original Message-
From: Brill Pappin [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 19, 2008 11:06 AM
To: users@wicket.apache.org
Subject: Re: How to indicate dependency on a .war file?

if you need to do that, then John was right, package it as a JAR file.  
In your case you presumably don't need all the webapp metadata that
usually goes along with a war.


However, it still might be worth using the overlay feature because it
means you can easily run the separate wars for debugging and development
(which it sounds like you are doing). The result however will pretty
much be the same.

1) if you *are not* "running" the common war code for independent
debugging, package it as a jar.
2) if you *are* independently running the common code, then use the war
overlay.

there is *no* way to get eclipse to see your war as a dependency in the
eclipse classpath (as John pointed out) because a war is a packaged
application, not a library.

- Brill Pappin


On 19-Jun-08, at 11:55 AM, Frank Silbermann wrote:

> That satisfies Maven, thanks!  I'm not looking to add any resources or

> pages from the dependency, just the java classes and HTML files, so I 
> don't think I need the "war overlay" feature.  But now I have another 
> problem.
>
> For debugging in eclipse, how do I tell Eclipse about this dependency?
> When I ran "mvn eclipse:eclipse" it did not produce a classpath 
> reference for the .war file.  When I hand coded the path to the .war 
> file in my local Maven repository, Eclipse couldn't use it -- perhaps 
> because the .war file places the .class and .html files inside the 
> WEB-INF/classes folder.
>
> Is there a way I can expose the classes in the .war file to Eclipse?
>
> -Original Message-
> From: Brill Pappin [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 19, 2008 10:10 AM
> To: users@wicket.apache.org
> Subject: Re: How to indicate dependency on a .war file?
>
> Look up "war overlay" in the maven-war-plugin that will give you some 
> useful information on what you want to do beyond your original 
> questions.
>
> as for dep types.
> A war can be depended upon just like a jar (or anything else for that
> matter) you simply specify the type:
> 
>   com.mypackage
>   mywebapp
>   1.0.0XXX
>   war
> 
>
> - Brill Pappin
>
>
> On 19-Jun-08, at 10:59 AM, Frank Silbermann wrote:
>
>> I have a question about packaging.  I have two Wicket web 
>> applications that display data for two different corporate areas, but

>> the look-and-feel are similar.  Therefore, I coded in Wicket a tool 
>> project consisting of a bunch of higher-level problem-specific 
>> components that my two projects should depend upon.
>>
>> In my tool project I built a web page that I use to test (display and

>> play with) these components.  Therefore, the output of my tool 
>> project
>
>> is also .war.  How do I tell Maven that my two business applications 
>> depend upon a .war and not a .jar?  I'd rather not have to partition 
>> my tool project into separate .war and .jar projects.
>>
>>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: How to indicate dependency on a .war file?

[Frank Silbermann]

That satisfies Maven, thanks!  I'm not looking to add any resources or
pages from the dependency, just the java classes and HTML files, so I
don't think I need the "war overlay" feature.  But now I have another
problem.

For debugging in eclipse, how do I tell Eclipse about this dependency?
When I ran "mvn eclipse:eclipse" it did not produce a classpath
reference for the .war file.  When I hand coded the path to the .war
file in my local Maven repository, Eclipse couldn't use it -- perhaps
because the .war file places the .class and .html files inside the
WEB-INF/classes folder.

Is there a way I can expose the classes in the .war file to Eclipse?

-Original Message-
From: Brill Pappin [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 19, 2008 10:10 AM
To: users@wicket.apache.org
Subject: Re: How to indicate dependency on a .war file?

Look up "war overlay" in the maven-war-plugin that will give you some
useful information on what you want to do beyond your original
questions.

as for dep types.
A war can be depended upon just like a jar (or anything else for that
matter) you simply specify the type:

com.mypackage
mywebapp
1.0.0XXX
war


- Brill Pappin


On 19-Jun-08, at 10:59 AM, Frank Silbermann wrote:

> I have a question about packaging.  I have two Wicket web   
> applications
> that display data for two different corporate areas, but the 
> look-and-feel are similar.  Therefore, I coded in Wicket a tool 
> project consisting of a bunch of higher-level problem-specific 
> components that my two projects should depend upon.
>
> In my tool project I built a web page that I use to test (display and 
> play with) these components.  Therefore, the output of my tool project

> is also .war.  How do I tell Maven that my two business applications 
> depend upon a .war and not a .jar?  I'd rather not have to partition 
> my tool project into separate .war and .jar projects.
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

How to indicate dependency on a .war file?

[Frank Silbermann]

I have a question about packaging.  I have two Wicket web  applications
that display data for two different corporate areas, but the
look-and-feel are similar.  Therefore, I coded in Wicket a tool project
consisting of a bunch of higher-level problem-specific components that
my two projects should depend upon.
 
In my tool project I built a web page that I use to test (display and
play with) these components.  Therefore, the output of my tool project
is also .war.  How do I tell Maven that my two business applications
depend upon a .war and not a .jar?  I'd rather not have to partition my
tool project into separate .war and .jar projects.
 
 

RE: compilation question

[Frank Silbermann]

org/maven2/commons-digester/commons-digester/1.6
/commons-digester-1.6.jar
164K downloaded
Downloading:
http://repo1.maven.org/maven2/commons-collections/commons-collectio
ns/2.0/commons-collections-2.0.jar
88K downloaded
Downloading: http://repo1.maven.org/maven2/oro/oro/2.0.7/oro-2.0.7.jar
63K downloaded
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-core/1.0
-alpha-7/doxia-core-1.0-alpha-7.jar
225K downloaded
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-site-ren
derer/1.0-alpha-8/doxia-site-renderer-1.0-alpha-8.jar
33K downloaded
Downloading:
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-i18n/1.0-b
eta-6/plexus-i18n-1.0-beta-6.jar
11K downloaded
Downloading:
http://repo1.maven.org/maven2/velocity/velocity/1.4/velocity-1.4.ja
r
352K downloaded
Downloading:
http://repo1.maven.org/maven2/velocity/velocity-dep/1.4/velocity-de
p-1.4.jar
505K downloaded
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-decorati
on-model/1.0-alpha-8/doxia-decoration-model-1.0-alpha-8.jar
39K downloaded
[INFO] [dependency:list]
[INFO]
[INFO] The following files have been resolved:
[INFO]commons-collections:commons-collections:jar:3.2:compile
[INFO]geronimo-spec:geronimo-spec-jta:jar:1.0.1B-rc4:provided
[INFO]javax.activation:activation:jar:1.1:provided
[INFO]javax.mail:mail:jar:1.4:provided
[INFO]joda-time:joda-time:jar:1.4:compile
[INFO]junit:junit:jar:3.8.2:test
[INFO]log4j:log4j:jar:1.2.14:compile
[INFO]mx4j:mx4j:jar:3.0.1:provided
[INFO]mx4j:mx4j-tools:jar:3.0.1:provided
[INFO]net.sourceforge.jtds:jtds:jar:1.2.2:compile
[INFO]org.apache.wicket:wicket:jar:1.3.3:compile
[INFO]org.apache.wicket:wicket-datetime:jar:1.3.3:compile
[INFO]org.apache.wicket:wicket-extensions:jar:1.3.3:compile
[INFO]org.mortbay.jetty:jetty:jar:6.1.4:provided
[INFO]org.mortbay.jetty:jetty-management:jar:6.1.4:provided
[INFO]org.mortbay.jetty:jetty-naming:jar:6.1.4:provided
[INFO]org.mortbay.jetty:jetty-plus:jar:6.1.4:provided
[INFO]org.mortbay.jetty:jetty-util:jar:6.1.4:provided
[INFO]org.mortbay.jetty:servlet-api-2.5:jar:6.1.4:provided
[INFO]org.slf4j:slf4j-api:jar:1.4.2:compile
[INFO]org.slf4j:slf4j-log4j12:jar:1.4.2:compile
[INFO]
[INFO]

[INFO] BUILD SUCCESSFUL
[INFO]

[INFO] Total time: 29 seconds
[INFO] Finished at: Wed Jun 18 16:17:19 CDT 2008
[INFO] Final Memory: 10M/20M
[INFO]


C:\webReports\web applications\WebCommon> 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of James Carman
Sent: Wednesday, June 18, 2008 3:56 PM
To: users@wicket.apache.org
Subject: Re: compilation question

Forget the pom.  Paste the output from "mvn dependency:list"

On Wed, Jun 18, 2008 at 4:33 PM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> I am having a weird compilation issue.  I built an application working

> from the QuickStart which used wicket-extensions_1.3 and 
> wicket-datetime_1.3.  To download the dependencies I added the 
> necessary lines to my pom.xml and I entered "mvn eclipse:eclipse" to 
> be sure that the dependencies would be provided to Eclipse.  After 
> setting the M2_REPO variable I can compile in Eclipse just fine.  When

> I open a DOS window, navigate to my project, and enter "mvn compile" 
> it ends successfully saying that there is nothing to compile.
>
> However, when I enter "mvn clean" and then "mvn compile" I get this 
> very peculiar error:
>
> C:\webReports\web
> applications\WebCommon\src\main\java\common\components\DatePickerManua
> lS
> ubmitPanel.java:[10,0] package
> org.apache.wicket.extensions.yui.calendar.assets.skins.sam does not 
> exist
>
> Any clues?  Would it help if I posted my pom.xml file?
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

compilation question

[Frank Silbermann]

I am having a weird compilation issue.  I built an application working
from the QuickStart which used wicket-extensions_1.3 and
wicket-datetime_1.3.  To download the dependencies I added the necessary
lines to my pom.xml and I entered "mvn eclipse:eclipse" to be sure that
the dependencies would be provided to Eclipse.  After setting the
M2_REPO variable I can compile in Eclipse just fine.  When I open a DOS
window, navigate to my project, and enter "mvn compile" it ends
successfully saying that there is nothing to compile.  
 
However, when I enter "mvn clean" and then "mvn compile" I get this very
peculiar error:
 
C:\webReports\web
applications\WebCommon\src\main\java\common\components\DatePickerManualS
ubmitPanel.java:[10,0] package
org.apache.wicket.extensions.yui.calendar.assets.skins.sam does not
exist
 
Any clues?  Would it help if I posted my pom.xml file?

Controlling the application name

[Frank Silbermann]

This question pertains to the infrastructure provided with the
QuickStart, but not specifically with Wicket, so you might want to
replay via e-mail rather than to the list.
 
When I use Maven to package my application, it appends a version number
(or SNAPSHOT indicator) into the name of my .war file.  When I drop my
.war file into Tomcat's webapp folder, the .war filename becomes the
application name, part of the URL that users must enter.
 
I do not want the version number to be part of the web application's
URL.  I want to be able to change the version without making the user
update all bookmarks.  One way to do this is to manually change the name
of the .war file to eliminate the version information before providing
it to Tomcat, but that seems clumsy.  Is there some way I can tell Maven
to deploy the .war file to my Tomcat directory without the version
number?  Alternately, is there something I can put in my application's
context.xml file to tell Tomcat to use something other than the .war
filename as the application name?
 
What is the right way to do this?  Is this a Maven question or a Tomcat
question?
 

RE: Wicket 1.2 -> 1.3 upgrade question

[Frank Silbermann]

Do any of the examples (or other documentation) illustrate its use? 

-Original Message-
From: Martijn Dashorst [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 16, 2008 10:15 AM
To: users@wicket.apache.org
Subject: Re: Wicket 1.2 -> 1.3 upgrade question

see ContextImage.

Martijn

On Mon, Jun 16, 2008 at 5:07 PM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> I did a few more experiments with static images in Wicket 1.3 and 
> narrowed the problem down to my use of AttributeModifier:
>
> Consider a Wicket home page with no components that displays a static 
> image via the following HTML:
>
> 
>
>Wicket Quickstart Archetype Homepage
>
>
>Wicket Quickstart Archetype Homepage
>
>
>
> 
>
> The image appears, and with the QuickStart's filter URL of "/*" the 
> HTML delivered to my browser is essentially the same as the HTML of my

> Wicket home page.  However, when I changed the Wicket filter's URL 
> from "/*" to "/test/*" then the source HTML of the delivered page 
> changes the  tag to:
>
>  
>
> Notice the "../" prepended to "imageName.png".
>
> The code that gives me trouble sets the image name via 
> AttributeModifier and WebComponent.  Change the home page HTML to:
>
> 
>
>Wicket Quickstart Archetype Homepage
>
>
>Wicket Quickstart Archetype Homepage
>
> src="imageNameGoesHere.png"/>
>
> 
>
> Adding a component, the constructor of my HomePage becomes:
>
>public HomePage(final PageParameters parameters) {
>WebComponent wmc = new WebComponent("picture");
>wmc.add( new AttributeModifier( "src", true, new
> Model("imageName.png") )  );
>add( wmc );
>}
>
> Whether or not I re-map the filter's URL, the HTML delivered to my 
> browser is:
>
> 
>
>Wicket Quickstart Archetype Homepage
>
>
>Wicket Quickstart Archetype Homepage
>
>
>
> 
>
> The image is found using the "/*" URL that comes with the QuickStart, 
> but if I change the URL of the filter to "/test/*" then it no longer 
> finds the image -- because no "../" is prepended to "imageName.png", 
> as was the case with the purely static reference.
>
> However, re-mapping the Wicket filter to "/test/*", I can get the 
> image to appear if I change the model of my AttributeModifier as
follows:
>
>public HomePage(final PageParameters parameters) {
>WebComponent wmc = new WebComponent("picture");
>wmc.add( new AttributeModifier( "src", true, new
> Model("../imageName.png") )  );
>add( wmc );
>}
>
> Now, the HTML is delivered with an image source of "../imageName.png".
>
> With Wicket 1.2, my use of AttributeModifier worked no matter what URL

> I used to deploy the application.  Is there an better way of coding 
> this that will work with whatever URL I use in my web.xml, or do I 
> still need to create a JIRA issue?
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 13, 2008 4:52 PM
> To: users@wicket.apache.org
> Subject: Re: Wicket 1.2 -> 1.3 upgrade question
>
> well, package an example project that demonstrates it and attach it to

> jira
>
> -igor
>
> On Fri, Jun 13, 2008 at 1:19 PM, Frank Silbermann 
> <[EMAIL PROTECTED]> wrote:
>> Adding the filterMappingUrlPattern didn't seem to make any
difference.
>> When both are set to "/*" I see the image; when both are set to 
>> "/test/*" then I don't see the image.
>>
>> -Original Message-
>> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>> Sent: Friday, June 13, 2008 3:10 PM
>> To: users@wicket.apache.org
>> Subject: Re: Wicket 1.2 -> 1.3 upgrade question
>>
>> guess so
>>
>> -igor
>>
>> On Fri, Jun 13, 2008 at 1:04 PM, Frank Silbermann 
>> <[EMAIL PROTECTED]> wrote:
>>> Like this?
>>>
>>>  >> xmlns="http://java.sun.com/xml/ns/j2ee";
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
>>> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"; version="2.4">
>>>
>>>myproject
>>>
>>>
>>>wicket.myproject
>>>
>>> org.apache.wicket.prot

RE: Wicket 1.2 -> 1.3 upgrade question

[Frank Silbermann]

I did a few more experiments with static images in Wicket 1.3 and
narrowed the problem down to my use of AttributeModifier:

Consider a Wicket home page with no components that displays a static
image via the following HTML:



Wicket Quickstart Archetype Homepage


Wicket Quickstart Archetype Homepage





The image appears, and with the QuickStart's filter URL of "/*" the HTML
delivered to my browser is essentially the same as the HTML of my Wicket
home page.  However, when I changed the Wicket filter's URL from "/*" to
"/test/*" then the source HTML of the delivered page changes the 
tag to:

  

Notice the "../" prepended to "imageName.png".

The code that gives me trouble sets the image name via AttributeModifier
and WebComponent.  Change the home page HTML to:



Wicket Quickstart Archetype Homepage


Wicket Quickstart Archetype Homepage





Adding a component, the constructor of my HomePage becomes: 

public HomePage(final PageParameters parameters) {
WebComponent wmc = new WebComponent("picture");
wmc.add( new AttributeModifier( "src", true, new
Model("imageName.png") )  );
add( wmc );
}

Whether or not I re-map the filter's URL, the HTML delivered to my
browser is:



Wicket Quickstart Archetype Homepage


Wicket Quickstart Archetype Homepage





The image is found using the "/*" URL that comes with the QuickStart,
but if I change the URL of the filter to "/test/*" then it no longer
finds the image -- because no "../" is prepended to "imageName.png", as
was the case with the purely static reference.

However, re-mapping the Wicket filter to "/test/*", I can get the image
to appear if I change the model of my AttributeModifier as follows:

public HomePage(final PageParameters parameters) {
WebComponent wmc = new WebComponent("picture");
wmc.add( new AttributeModifier( "src", true, new
Model("../imageName.png") )  );
add( wmc );
}

Now, the HTML is delivered with an image source of "../imageName.png".

With Wicket 1.2, my use of AttributeModifier worked no matter what URL I
used to deploy the application.  Is there an better way of coding this
that will work with whatever URL I use in my web.xml, or do I still need
to create a JIRA issue?  

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 13, 2008 4:52 PM
To: users@wicket.apache.org
Subject: Re: Wicket 1.2 -> 1.3 upgrade question

well, package an example project that demonstrates it and attach it to
jira

-igor

On Fri, Jun 13, 2008 at 1:19 PM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> Adding the filterMappingUrlPattern didn't seem to make any difference.
> When both are set to "/*" I see the image; when both are set to 
> "/test/*" then I don't see the image.
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 13, 2008 3:10 PM
> To: users@wicket.apache.org
> Subject: Re: Wicket 1.2 -> 1.3 upgrade question
>
> guess so
>
> -igor
>
> On Fri, Jun 13, 2008 at 1:04 PM, Frank Silbermann 
> <[EMAIL PROTECTED]> wrote:
>> Like this?
>>
>>  > xmlns="http://java.sun.com/xml/ns/j2ee";
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
>> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"; version="2.4">
>>
>>myproject
>>
>>
>>wicket.myproject
>>
>> org.apache.wicket.protocol.http.WicketFilter> a
>> ss
>>>
>>
>>applicationClassName
>>
>> com.mycompany.WicketApplication
>>
>>
>>
> filterMappingUrlPattern
>>/test/*
>>
>>
>>
>>  
>>  wicket.myproject
>>/test/*
>>  
>>
>> 
>>
>> -Original Message-
>> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>> Sent: Friday, June 13, 2008 2:45 PM
>> To: users@wicket.apache.org
>> Subject: Re: Wicket 1.2 -> 1.3 upgrade question
>>
>> the filter itself takes a configuration param where you have to 
>> repeat
>
>> the mapping...
>>
>> class WicketFilter {
>>   /**
>> * The name of the root path parameter that specifies the root

>> dir of the app.
>>  

RE: Using Java 1.5 features with Wicket 1.3

[Frank Silbermann]

Never mind.  I rebooted my machine and everything is back to normal.
Sigh. 

-Original Message-
From: Frank Silbermann [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 13, 2008 4:19 PM
To: users@wicket.apache.org
Subject: RE: Using Java 1.5 features with Wicket 1.3

No, I do not compile Wicket myself -- at least.  I merely have
dependencies to Wicket in the pom.xml. 

-Original Message-
From: Timm Helbig [mailto:[EMAIL PROTECTED]
Sent: Friday, June 13, 2008 4:06 PM
To: users@wicket.apache.org
Subject: Re: Using Java 1.5 features with Wicket 1.3

Do you compile Wicket yourself? If so, this should be compiled using
--source 1.4. Your own code can stay with --source 1.5. 

Timm


Am Freitag, 13. Juni 2008 22:58:53 schrieb Frank Silbermann:
> In my Wicket 1.2 application I used a Java 1.5 JDK.  Wicket didn't 
> seem to mind that I used annotations, etc. in my own code.  I did the 
> same in code that I upgraded to Wicket 1.3.  Also, my Wicket 1.2 
> application was built from scratch using JBuilder 2006; but the 
> stop-server/modify-code/compile/re-deploy/start-server cycle was 
> laborious, so this time I've been trying to work from the QuickStart, 
> using Maven2 and Eclipse, with Jetty in process for debugging.  But 
> for some reason I keep messing up.
>
> I was able to compile my code using either Maven2 or Eclipse.  Then, 
> when rebuilding with Maven2 I had the bright idea of calling "mvn
clean"
> first.  Well, my compilation is failing all over the place now, with 
> comments of the form:
>
> ...annotations are not supported in -source 1.3 (use -source 5 or 
> higher to enable annotations)
>
> I googled the error and found a page
> http://vikashazrati.wordpress.com/2008/05/13/maven2-annotations-not-su
> pp orted/ that suggested I add to my pom.xml
>
> 
> 
> ...
>   
> maven-compiler-plugin
> 
>   1.5
>   1.5
> 
>   
>
> 
>   
>
> I did so, and now I'm getting an error:
>
> C:\webReports\web
> applications\WebCommon\src\main\java\common\components\DatePickerManua
> lS
> ubmitPanel.java:[10,0] package
> org.apache.wicket.extensions.yui.calendar.assets.skins.sam does not 
> exist
>
> When I go back to Eclipse, it doesn't tell me it cannot build, but 
> when I try to run I get a tab saying:
>
> "URLClassLoader$1.run() line: not availableSource not
found
>
>
> I am getting very frustrated.  Does anyone recognize these symptoms?  
> Is my only choice to start over?



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Using Java 1.5 features with Wicket 1.3

[Frank Silbermann]

No, I do not compile Wicket myself -- at least.  I merely have
dependencies to Wicket in the pom.xml. 

-Original Message-
From: Timm Helbig [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 13, 2008 4:06 PM
To: users@wicket.apache.org
Subject: Re: Using Java 1.5 features with Wicket 1.3

Do you compile Wicket yourself? If so, this should be compiled using
--source 1.4. Your own code can stay with --source 1.5. 

Timm


Am Freitag, 13. Juni 2008 22:58:53 schrieb Frank Silbermann:
> In my Wicket 1.2 application I used a Java 1.5 JDK.  Wicket didn't 
> seem to mind that I used annotations, etc. in my own code.  I did the 
> same in code that I upgraded to Wicket 1.3.  Also, my Wicket 1.2 
> application was built from scratch using JBuilder 2006; but the 
> stop-server/modify-code/compile/re-deploy/start-server cycle was 
> laborious, so this time I've been trying to work from the QuickStart, 
> using Maven2 and Eclipse, with Jetty in process for debugging.  But 
> for some reason I keep messing up.
>
> I was able to compile my code using either Maven2 or Eclipse.  Then, 
> when rebuilding with Maven2 I had the bright idea of calling "mvn
clean"
> first.  Well, my compilation is failing all over the place now, with 
> comments of the form:
>
> ...annotations are not supported in -source 1.3 (use -source 5 or 
> higher to enable annotations)
>
> I googled the error and found a page
> http://vikashazrati.wordpress.com/2008/05/13/maven2-annotations-not-su
> pp orted/ that suggested I add to my pom.xml
>
> 
> 
> ...
>   
> maven-compiler-plugin
> 
>   1.5
>   1.5
> 
>   
>
> 
>   
>
> I did so, and now I'm getting an error:
>
> C:\webReports\web
> applications\WebCommon\src\main\java\common\components\DatePickerManua
> lS
> ubmitPanel.java:[10,0] package
> org.apache.wicket.extensions.yui.calendar.assets.skins.sam does not 
> exist
>
> When I go back to Eclipse, it doesn't tell me it cannot build, but 
> when I try to run I get a tab saying:
>
> "URLClassLoader$1.run() line: not availableSource not
found
>
>
> I am getting very frustrated.  Does anyone recognize these symptoms?  
> Is my only choice to start over?



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Using Java 1.5 features with Wicket 1.3

[Frank Silbermann]

In my Wicket 1.2 application I used a Java 1.5 JDK.  Wicket didn't seem
to mind that I used annotations, etc. in my own code.  I did the same in
code that I upgraded to Wicket 1.3.  Also, my Wicket 1.2 application was
built from scratch using JBuilder 2006; but the
stop-server/modify-code/compile/re-deploy/start-server cycle was
laborious, so this time I've been trying to work from the QuickStart,
using Maven2 and Eclipse, with Jetty in process for debugging.  But for
some reason I keep messing up.
 
I was able to compile my code using either Maven2 or Eclipse.  Then,
when rebuilding with Maven2 I had the bright idea of calling "mvn clean"
first.  Well, my compilation is failing all over the place now, with
comments of the form:
 
...annotations are not supported in -source 1.3 (use -source 5 or higher
to enable annotations)
 
I googled the error and found a page
http://vikashazrati.wordpress.com/2008/05/13/maven2-annotations-not-supp
orted/ that suggested I add to my pom.xml
 


...
  
maven-compiler-plugin

  1.5
  1.5

  
   

  

I did so, and now I'm getting an error:
 
C:\webReports\web
applications\WebCommon\src\main\java\common\components\DatePickerManualS
ubmitPanel.java:[10,0] package
org.apache.wicket.extensions.yui.calendar.assets.skins.sam does not
exist
 
When I go back to Eclipse, it doesn't tell me it cannot build, but when
I try to run I get a tab saying:
 
"URLClassLoader$1.run() line: not availableSource not found
 
 
I am getting very frustrated.  Does anyone recognize these symptoms?  Is
my only choice to start over?
 

RE: Wicket 1.2 -> 1.3 upgrade question

[Frank Silbermann]

Adding the filterMappingUrlPattern didn't seem to make any difference.
When both are set to "/*" I see the image; when both are set to
"/test/*" then I don't see the image. 

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 13, 2008 3:10 PM
To: users@wicket.apache.org
Subject: Re: Wicket 1.2 -> 1.3 upgrade question

guess so

-igor

On Fri, Jun 13, 2008 at 1:04 PM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> Like this?
>
>   xmlns="http://java.sun.com/xml/ns/j2ee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"; version="2.4">
>
>myproject
>
>
>wicket.myproject
>
> org.apache.wicket.protocol.http.WicketFilter ss
>>
>
>applicationClassName
>
> com.mycompany.WicketApplication
>
>
>
filterMappingUrlPattern
>/test/*
>
>
>
>  
>  wicket.myproject
>/test/*
>  
>
> 
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 13, 2008 2:45 PM
> To: users@wicket.apache.org
> Subject: Re: Wicket 1.2 -> 1.3 upgrade question
>
> the filter itself takes a configuration param where you have to repeat

> the mapping...
>
> class WicketFilter {
>   /**
> * The name of the root path parameter that specifies the root 
> dir of the app.
> */
>public static final String FILTER_MAPPING_PARAM = 
> "filterMappingUrlPattern";
>
>   String filterMapping =
> filterConfig.getInitParameter(WicketFilter.FILTER_MAPPING_PARAM);
> }
>
> -igor
>
> On Fri, Jun 13, 2008 at 11:09 AM, Frank Silbermann 
> <[EMAIL PROTECTED]> wrote:
>> Yes, there is a  element that maps  to 
>> .
>>
>> However, as I mentioned in
>> http://www.nabble.com/Re%3A-%28Class%3C--extends-Page%3C-%3E%3E%29-ca
>> s ti ng-troubles-td17640954i40.html#a17824049, when I changed the 
>>  from "/*" to "/something/*" -- my static images 
>> (referenced by the HTML such as
>>
>>  < img wicket:id="picture" src="image1.png" alt="Picture"/ >
>>
>> where "image1.png" was set via AttributeModifyer) no longer appeared.
>>
>> That suggested to me that perhaps I wasn't supposed to change the 
>>  of the filter.  Should I submit this as a JIRA issue?
>>
>> -Original Message-
>> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>> Sent: Friday, June 13, 2008 12:53 PM
>> To: users@wicket.apache.org
>> Subject: Re: Wicket 1.2 -> 1.3 upgrade question
>>
>> you have to give the mapping as a config param to the filter also, i 
>> forget the exact name right now...
>>
>> -igor
>>
>> On Fri, Jun 13, 2008 at 10:00 AM, Frank Silbermann 
>> <[EMAIL PROTECTED]> wrote:
>>> Wicket 1.3 is configured as a filter rather than as a servlet.  The 
>>> Quickstart shows a filter whose URL-PATTERN is "/*".
>>>
>>> The project that I wish to upgrade contains two Wicket 1.2 
>>> application
>>
>>> servlets (two different home-pages accessed via different URLs), and

>>> one plain-vanilla non-Wicket servlet.  They are deployed together 
>>> because they share the same code-base.
>>>
>>> This is my Wicket 1.2 project's web.xml file.  How do I do this sort

>>> of thing in Wicket 1.3?
>>>
>>>  >> xmlns="http://java.sun.com/xml/ns/j2ee
>>> <http://java.sun.com/xml/ns/j2ee> "
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
>>> <http://www.w3.org/2001/XMLSchema-instance> "
>>> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
>>> <http://java.sun.com/xml/ns/j2ee>
>>> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd
>>> <http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd> " version="2.4"> 
>>> MEMSpssWebModule
>>>  
>>>configuration
>>>development
>>>  
>>>  
>>>MEM_Application
>>>wicket.protocol.http.WicketServlet
>>>
>>>  applicationClassName
>>>  mem.MEM_Application
>>>
>>>1
>>>  
>>>  
>>>MEM_Application
>>>/mem/* 

RE: Wicket 1.2 -> 1.3 upgrade question

[Frank Silbermann]

Like this?


http://java.sun.com/xml/ns/j2ee";
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"; version="2.4">

myproject


wicket.myproject
 
org.apache.wicket.protocol.http.WicketFilter

applicationClassName

com.mycompany.WicketApplication


filterMappingUrlPattern
/test/*



 
  wicket.myproject
/test/*
 

  

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 13, 2008 2:45 PM
To: users@wicket.apache.org
Subject: Re: Wicket 1.2 -> 1.3 upgrade question

the filter itself takes a configuration param where you have to repeat
the mapping...

class WicketFilter {
   /**
 * The name of the root path parameter that specifies the root
dir of the app.
 */
public static final String FILTER_MAPPING_PARAM =
"filterMappingUrlPattern";

   String filterMapping =
filterConfig.getInitParameter(WicketFilter.FILTER_MAPPING_PARAM);
}

-igor

On Fri, Jun 13, 2008 at 11:09 AM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> Yes, there is a  element that maps  to 
> .
>
> However, as I mentioned in
> http://www.nabble.com/Re%3A-%28Class%3C--extends-Page%3C-%3E%3E%29-cas
> ti ng-troubles-td17640954i40.html#a17824049, when I changed the 
>  from "/*" to "/something/*" -- my static images 
> (referenced by the HTML such as
>
>  < img wicket:id="picture" src="image1.png" alt="Picture"/ >
>
> where "image1.png" was set via AttributeModifyer) no longer appeared.
>
> That suggested to me that perhaps I wasn't supposed to change the 
>  of the filter.  Should I submit this as a JIRA issue?
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 13, 2008 12:53 PM
> To: users@wicket.apache.org
> Subject: Re: Wicket 1.2 -> 1.3 upgrade question
>
> you have to give the mapping as a config param to the filter also, i 
> forget the exact name right now...
>
> -igor
>
> On Fri, Jun 13, 2008 at 10:00 AM, Frank Silbermann 
> <[EMAIL PROTECTED]> wrote:
>> Wicket 1.3 is configured as a filter rather than as a servlet.  The 
>> Quickstart shows a filter whose URL-PATTERN is "/*".
>>
>> The project that I wish to upgrade contains two Wicket 1.2 
>> application
>
>> servlets (two different home-pages accessed via different URLs), and 
>> one plain-vanilla non-Wicket servlet.  They are deployed together 
>> because they share the same code-base.
>>
>> This is my Wicket 1.2 project's web.xml file.  How do I do this sort 
>> of thing in Wicket 1.3?
>>
>>  > xmlns="http://java.sun.com/xml/ns/j2ee
>> <http://java.sun.com/xml/ns/j2ee> "
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
>> <http://www.w3.org/2001/XMLSchema-instance> "
>> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
>> <http://java.sun.com/xml/ns/j2ee>
>> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd
>> <http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd> " version="2.4"> 
>> MEMSpssWebModule
>>  
>>configuration
>>development
>>  
>>  
>>MEM_Application
>>wicket.protocol.http.WicketServlet
>>
>>  applicationClassName
>>  mem.MEM_Application
>>
>>1
>>  
>>  
>>MEM_Application
>>/mem/*
>>  
>>
>>  
>>MEMTestApplication
>>wicket.protocol.http.WicketServlet
>>
>>  applicationClassName
>>  mem.TestApplication
>>
>>1
>>  
>>  
>>MEMTestApplication
>>/MEMTest/*
>>  
>>
>>
>>  
>>trackingnumbers
>>mem.TrackingNumbers
>>  
>>  
>>trackingnumbers
>>/trackingnumbers
>>  
>>
>>  
>>Resource reference to a factory for
> java.sql.Connection
>>  instances that may be used for talking to a particular
>>  database that is configured in the server.xml
file.
>>jdbc/database
>>javax.sql.DataSource
>>Container
>>  
>> 
>>
>>
>>
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Wicket 1.2 -> 1.3 upgrade question

[Frank Silbermann]

Yes, there is a  element that maps  to
.

However, as I mentioned in
http://www.nabble.com/Re%3A-%28Class%3C--extends-Page%3C-%3E%3E%29-casti
ng-troubles-td17640954i40.html#a17824049, when I changed the
 from "/*" to "/something/*" -- my static images
(referenced by the HTML such as

 < img wicket:id="picture" src="image1.png" alt="Picture"/ >

where "image1.png" was set via AttributeModifyer) no longer appeared.

That suggested to me that perhaps I wasn't supposed to change the
 of the filter.  Should I submit this as a JIRA issue?

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 13, 2008 12:53 PM
To: users@wicket.apache.org
Subject: Re: Wicket 1.2 -> 1.3 upgrade question

you have to give the mapping as a config param to the filter also, i
forget the exact name right now...

-igor

On Fri, Jun 13, 2008 at 10:00 AM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> Wicket 1.3 is configured as a filter rather than as a servlet.  The 
> Quickstart shows a filter whose URL-PATTERN is "/*".
>
> The project that I wish to upgrade contains two Wicket 1.2 application

> servlets (two different home-pages accessed via different URLs), and 
> one plain-vanilla non-Wicket servlet.  They are deployed together 
> because they share the same code-base.
>
> This is my Wicket 1.2 project's web.xml file.  How do I do this sort 
> of thing in Wicket 1.3?
>
>   xmlns="http://java.sun.com/xml/ns/j2ee
> <http://java.sun.com/xml/ns/j2ee> "
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
> <http://www.w3.org/2001/XMLSchema-instance> "
> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> <http://java.sun.com/xml/ns/j2ee>
> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd
> <http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd> " version="2.4">  
> MEMSpssWebModule
>  
>configuration
>development
>  
>  
>MEM_Application
>wicket.protocol.http.WicketServlet
>
>  applicationClassName
>  mem.MEM_Application
>
>1
>  
>  
>MEM_Application
>/mem/*
>  
>
>  
>MEMTestApplication
>wicket.protocol.http.WicketServlet
>
>  applicationClassName
>  mem.TestApplication
>
>1
>  
>  
>MEMTestApplication
>/MEMTest/*
>  
>
>
>  
>trackingnumbers
>mem.TrackingNumbers
>  
>  
>trackingnumbers
>/trackingnumbers
>  
>
>  
>Resource reference to a factory for
java.sql.Connection
>  instances that may be used for talking to a particular
>  database that is configured in the server.xml file.
>jdbc/database
>javax.sql.DataSource
>Container
>  
> 
>
>
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Wicket 1.2 -> 1.3 upgrade question

[Frank Silbermann]

Wicket 1.3 is configured as a filter rather than as a servlet.  The
Quickstart shows a filter whose URL-PATTERN is "/*".
 
The project that I wish to upgrade contains two Wicket 1.2 application
servlets (two different home-pages accessed via different URLs), and one
plain-vanilla non-Wicket servlet.  They are deployed together because
they share the same code-base.
 
This is my Wicket 1.2 project's web.xml file.  How do I do this sort of
thing in Wicket 1.3?
 

http://java.sun.com/xml/ns/j2ee
 "
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
 "
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee

http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd
 " version="2.4">
  MEMSpssWebModule
  
configuration
development
  
  
MEM_Application
wicket.protocol.http.WicketServlet

  applicationClassName
  mem.MEM_Application

1
  
  
MEM_Application
/mem/*
  

  
MEMTestApplication
wicket.protocol.http.WicketServlet

  applicationClassName
  mem.TestApplication

1
  
  
MEMTestApplication
/MEMTest/*
  


  
trackingnumbers
mem.TrackingNumbers
  
  
trackingnumbers
/trackingnumbers
  
 
  
Resource reference to a factory for java.sql.Connection
  instances that may be used for talking to a particular
  database that is configured in the server.xml file.
jdbc/database
javax.sql.DataSource
Container
  

 
 
 

RE: Modifying QuickStart to serve static content in embedded Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart)

[Frank Silbermann]

OK, I did some experiments starting with a clean quicksort project.  The
images did appear.  However, when I modified the web.xml to change from:

 
  wicket.myproject
/*
 

to this:

 
  wicket.myproject
/test/*
 

then the image no longer appeared.

In Wicket 1.2 I could define to Wicket applications in the same .war
file, giving them different URLs.  I assumed that in Wicket 1.3 I could
simply define two filters in my web.xml, using different filter mappings
to distinguish the URLs, but changing the URL like this is clearly not
appropriate.

What, then, is the proper way in Wicket 1.3 to define multiple Wicket
applications -- i.e., different home-pages?

Or was my original plan sound, provided I add something (what?) to my
web.xml for the default URL that is used when linking static resources?

-Original Message-
From: Martijn Dashorst [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 12, 2008 9:11 AM
To: users@wicket.apache.org
Subject: Re: Modifying QuickStart to serve static content in embedded
Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart)

No, because the JSP servlet is needed to compile JSPs into servlet code.
An unmodified configuration generated by the Wicket quickstart on our
website serves static images perfectly well. You really are doing
something funky.

Martijn

On Thu, Jun 12, 2008 at 4:07 PM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> Yes, the QuickStart itself works.  As for your ability to serve 
> images, it might depend whether these are images stored with the .html

> and .java files for Wicket to pick up, versus images that are stored 
> as static objects.  I googled the INFO - log warning " - NO JSP 
> Support for /, did not find org.apache.jasper.servlet.JspServlet"
>
> and found http://code.google.com/p/run-jetty-run/wiki/GettingStarted
> about running Wicket projects with Jetty in Eclipse.  It contains the 
> following comments:
>
> Comment by angelo.mariano, Jan 02, 2008
>   When I try to launch it, I get the following error: 2008-01-02
> 10:11:55.191::INFO: Logging to STDERR
>   via org.mortbay.log.StdErrLog? 2008-01-02 10:11:55.300::INFO:
> jetty-6.1.6 2008-01-02
>   10:11:55.441::INFO: NO JSP Support for /, did not find 
> org.apache.jasper.servlet.JspServlet?
>   2008-01-02 10:11:55.659:/:INFO: default: init 2008-01-02
> 10:11:55.659:/:INFO: jsp: init 2008-01-02
>   10:11:55.691::INFO: Started [EMAIL PROTECTED]:8080
>
>   and then I am not able to compile jsp. Do you know how to solve this

> problem? Thank you
>
> Comment by eelco.hillenius, Jan 02, 2008
>   Ah, I probably have to include the appropriate libs to turn JSP 
> support on. Could you please file a
>   ticket? I'll get to it shortly.
>
>
>
> Eelco, could that discussion have anything to do with my problem?
>
> -Original Message-
> From: Martijn Dashorst [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 12, 2008 1:23 AM
> To: users@wicket.apache.org
> Subject: Re: Tomcat 5.5.9 isn't running Quickstart
>
> The quickstart works for me without modifications. It serves images, 
> etc. out of the box, every time.
>
> Martijn
>
> On Thu, Jun 12, 2008 at 12:54 AM, Frank Silbermann 
> <[EMAIL PROTECTED]> wrote:
>> Searching for some clue as to why my modification of the QuickStart 
>> application is serving images when run in Tomcat but not when running

>> in embedded Jetty via Eclipse, I found:
>>
>> http://osdir.com/ml/java.jetty.support/2003-03/msg00045.html -- 
>> titled
>> "Re: Re: jetty can't find images: msg#00045"
>>
>> It says, "You need the webdefaults file because it sets up the 
>> Default
>
>> servlet which is what serves static resources like images.  You can 
>> also manually add the Default servlet if you want to avoid a 
>> webdefaults.xml file."
>>
>> I think this is a clue.  Looking at the console log when running 
>> Jetty
>
>> in Eclipse I see:
>>
>> INFO  - log- NO JSP Support for /, did not
> find
>> org.apache.jasper.servlet.JspServlet
>>
>> So what do I need to do to make it set up the Default servlet?  Is 
>> there a line I need to insert into Start.java to make it read the 
>> webdefaults.xml file?  I don't even have a webdefaults.xml file -- 
>> unless it's buried somewhere inside one of the Jetty jars.
>>
>> Here's the complete console log when debugging Start.java to bring up

>> Jetty (as demonstrated in 
>> http://herebebeasties.com/2007-10-07/wicket-quickstart/).
>>
>> INFO  - log- Logging to
>> org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via 
>> org.mortbay.log.Slf4jLog
&g

RE: Modifying QuickStart to serve static content in embedded Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart)

[Frank Silbermann]

Well, I guess the only thing to do is try and minimally modify the
QuickStart project with code that exhibits the problem and let others
try it.  Should I submit it as a JIRA issue (to be closed when it is
determined what I'm doing wrong), or should I attach the .zip to a
mailing list message?  Should I "mvn clean" it before zipping it to save
space?

-Original Message-
From: Martijn Dashorst [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 12, 2008 9:11 AM
To: users@wicket.apache.org
Subject: Re: Modifying QuickStart to serve static content in embedded
Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart)

No, because the JSP servlet is needed to compile JSPs into servlet code.
An unmodified configuration generated by the Wicket quickstart on our
website serves static images perfectly well. You really are doing
something funky.

Martijn

On Thu, Jun 12, 2008 at 4:07 PM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> Yes, the QuickStart itself works.  As for your ability to serve 
> images, it might depend whether these are images stored with the .html

> and .java files for Wicket to pick up, versus images that are stored 
> as static objects.  I googled the INFO - log warning " - NO JSP 
> Support for /, did not find org.apache.jasper.servlet.JspServlet"
>
> and found http://code.google.com/p/run-jetty-run/wiki/GettingStarted
> about running Wicket projects with Jetty in Eclipse.  It contains the 
> following comments:
>
> Comment by angelo.mariano, Jan 02, 2008
>   When I try to launch it, I get the following error: 2008-01-02
> 10:11:55.191::INFO: Logging to STDERR
>   via org.mortbay.log.StdErrLog? 2008-01-02 10:11:55.300::INFO:
> jetty-6.1.6 2008-01-02
>   10:11:55.441::INFO: NO JSP Support for /, did not find 
> org.apache.jasper.servlet.JspServlet?
>   2008-01-02 10:11:55.659:/:INFO: default: init 2008-01-02
> 10:11:55.659:/:INFO: jsp: init 2008-01-02
>   10:11:55.691::INFO: Started [EMAIL PROTECTED]:8080
>
>   and then I am not able to compile jsp. Do you know how to solve this

> problem? Thank you
>
> Comment by eelco.hillenius, Jan 02, 2008
>   Ah, I probably have to include the appropriate libs to turn JSP 
> support on. Could you please file a
>   ticket? I'll get to it shortly.
>
>
>
> Eelco, could that discussion have anything to do with my problem?
>
> -Original Message-
> From: Martijn Dashorst [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 12, 2008 1:23 AM
> To: users@wicket.apache.org
> Subject: Re: Tomcat 5.5.9 isn't running Quickstart
>
> The quickstart works for me without modifications. It serves images, 
> etc. out of the box, every time.
>
> Martijn
>
> On Thu, Jun 12, 2008 at 12:54 AM, Frank Silbermann 
> <[EMAIL PROTECTED]> wrote:
>> Searching for some clue as to why my modification of the QuickStart 
>> application is serving images when run in Tomcat but not when running

>> in embedded Jetty via Eclipse, I found:
>>
>> http://osdir.com/ml/java.jetty.support/2003-03/msg00045.html -- 
>> titled
>> "Re: Re: jetty can't find images: msg#00045"
>>
>> It says, "You need the webdefaults file because it sets up the 
>> Default
>
>> servlet which is what serves static resources like images.  You can 
>> also manually add the Default servlet if you want to avoid a 
>> webdefaults.xml file."
>>
>> I think this is a clue.  Looking at the console log when running 
>> Jetty
>
>> in Eclipse I see:
>>
>> INFO  - log- NO JSP Support for /, did not
> find
>> org.apache.jasper.servlet.JspServlet
>>
>> So what do I need to do to make it set up the Default servlet?  Is 
>> there a line I need to insert into Start.java to make it read the 
>> webdefaults.xml file?  I don't even have a webdefaults.xml file -- 
>> unless it's buried somewhere inside one of the Jetty jars.
>>
>> Here's the complete console log when debugging Start.java to bring up

>> Jetty (as demonstrated in 
>> http://herebebeasties.com/2007-10-07/wicket-quickstart/).
>>
>> INFO  - log- Logging to
>> org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via 
>> org.mortbay.log.Slf4jLog
>>>>> STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP
>> INFO  - log- jetty-6.1.4
>> INFO  - log- NO JSP Support for /, did not
> find
>> org.apache.jasper.servlet.JspServlet
>> INFO  - log- No Transaction manager found -
if
>> your webapp requires one, please configure one.
>> INFO  - Application- [TestAp

Modifying QuickStart to serve static content in embedded Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart)

[Frank Silbermann]

Yes, the QuickStart itself works.  As for your ability to serve images,
it might depend whether these are images stored with the .html and .java
files for Wicket to pick up, versus images that are stored as static
objects.  I googled the INFO - log warning " - NO JSP Support for /, did
not find org.apache.jasper.servlet.JspServlet"

and found http://code.google.com/p/run-jetty-run/wiki/GettingStarted
about running Wicket projects with Jetty in Eclipse.  It contains the
following comments:

Comment by angelo.mariano, Jan 02, 2008 
   When I try to launch it, I get the following error: 2008-01-02
10:11:55.191::INFO: Logging to STDERR  
   via org.mortbay.log.StdErrLog? 2008-01-02 10:11:55.300::INFO:
jetty-6.1.6 2008-01-02 
   10:11:55.441::INFO: NO JSP Support for /, did not find
org.apache.jasper.servlet.JspServlet? 
   2008-01-02 10:11:55.659:/:INFO: default: init 2008-01-02
10:11:55.659:/:INFO: jsp: init 2008-01-02 
   10:11:55.691::INFO: Started [EMAIL PROTECTED]:8080 

   and then I am not able to compile jsp. Do you know how to solve this
problem? Thank you 

Comment by eelco.hillenius, Jan 02, 2008 
   Ah, I probably have to include the appropriate libs to turn JSP
support on. Could you please file a 
   ticket? I'll get to it shortly. 



Eelco, could that discussion have anything to do with my problem?

-Original Message-
From: Martijn Dashorst [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 12, 2008 1:23 AM
To: users@wicket.apache.org
Subject: Re: Tomcat 5.5.9 isn't running Quickstart

The quickstart works for me without modifications. It serves images,
etc. out of the box, every time.

Martijn

On Thu, Jun 12, 2008 at 12:54 AM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> Searching for some clue as to why my modification of the QuickStart 
> application is serving images when run in Tomcat but not when running 
> in embedded Jetty via Eclipse, I found:
>
> http://osdir.com/ml/java.jetty.support/2003-03/msg00045.html -- titled
> "Re: Re: jetty can't find images: msg#00045"
>
> It says, "You need the webdefaults file because it sets up the Default

> servlet which is what serves static resources like images.  You can 
> also manually add the Default servlet if you want to avoid a 
> webdefaults.xml file."
>
> I think this is a clue.  Looking at the console log when running Jetty

> in Eclipse I see:
>
> INFO  - log- NO JSP Support for /, did not
find
> org.apache.jasper.servlet.JspServlet
>
> So what do I need to do to make it set up the Default servlet?  Is 
> there a line I need to insert into Start.java to make it read the 
> webdefaults.xml file?  I don't even have a webdefaults.xml file -- 
> unless it's buried somewhere inside one of the Jetty jars.
>
> Here's the complete console log when debugging Start.java to bring up 
> Jetty (as demonstrated in 
> http://herebebeasties.com/2007-10-07/wicket-quickstart/).
>
> INFO  - log- Logging to
> org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via 
> org.mortbay.log.Slf4jLog
>>>> STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP
> INFO  - log- jetty-6.1.4
> INFO  - log- NO JSP Support for /, did not
find
> org.apache.jasper.servlet.JspServlet
> INFO  - log- No Transaction manager found - if
> your webapp requires one, please configure one.
> INFO  - Application- [TestApplication] init: Wicket
core
> library initializer
> INFO  - RequestListenerInterface   - registered listener interface
> [RequestListenerInterface name=IBehaviorListener, method=public 
> abstract void
org.apache.wicket.behavior.IBehaviorListener.onRequest()]
> INFO  - RequestListenerInterface   - registered listener interface
> [RequestListenerInterface name=IBehaviorListener, method=public 
> abstract void
org.apache.wicket.behavior.IBehaviorListener.onRequest()]
> INFO  - RequestListenerInterface   - registered listener interface
> [RequestListenerInterface name=IFormSubmitListener, method=public 
> abstract void
> org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted
> ()
> ]
> INFO  - RequestListenerInterface   - registered listener interface
> [RequestListenerInterface name=IFormSubmitListener, method=public 
> abstract void
> org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted
> ()
> ]
> INFO  - RequestListenerInterface   - registered listener interface
> [RequestListenerInterface name=ILinkListener, method=public abstract 
> void org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
> INFO  - RequestListenerInterface   - registered listener interface
> [RequestListenerInterface name=ILink

RE: Tomcat 5.5.9 isn't running Quickstart

[Frank Silbermann]

Searching for some clue as to why my modification of the QuickStart
application is serving images when run in Tomcat but not when running in
embedded Jetty via Eclipse, I found:

http://osdir.com/ml/java.jetty.support/2003-03/msg00045.html -- titled
"Re: Re: jetty can't find images: msg#00045"

It says, "You need the webdefaults file because it sets up the Default
servlet which is what serves static resources like images.  You can also
manually add the Default servlet if you want to avoid
a webdefaults.xml file."

I think this is a clue.  Looking at the console log when running Jetty
in Eclipse I see:

INFO  - log- NO JSP Support for /, did not find
org.apache.jasper.servlet.JspServlet

So what do I need to do to make it set up the Default servlet?  Is there
a line I need to insert into Start.java to make it read the
webdefaults.xml file?  I don't even have a webdefaults.xml file --
unless it's buried somewhere inside one of the Jetty jars. 

Here's the complete console log when debugging Start.java to bring up
Jetty (as demonstrated in
http://herebebeasties.com/2007-10-07/wicket-quickstart/).

INFO  - log- Logging to
org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via
org.mortbay.log.Slf4jLog
>>> STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP
INFO  - log- jetty-6.1.4
INFO  - log- NO JSP Support for /, did not find
org.apache.jasper.servlet.JspServlet
INFO  - log- No Transaction manager found - if
your webapp requires one, please configure one.
INFO  - Application- [TestApplication] init: Wicket core
library initializer
INFO  - RequestListenerInterface   - registered listener interface
[RequestListenerInterface name=IBehaviorListener, method=public abstract
void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
INFO  - RequestListenerInterface   - registered listener interface
[RequestListenerInterface name=IBehaviorListener, method=public abstract
void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
INFO  - RequestListenerInterface   - registered listener interface
[RequestListenerInterface name=IFormSubmitListener, method=public
abstract void
org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted()
]
INFO  - RequestListenerInterface   - registered listener interface
[RequestListenerInterface name=IFormSubmitListener, method=public
abstract void
org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted()
]
INFO  - RequestListenerInterface   - registered listener interface
[RequestListenerInterface name=ILinkListener, method=public abstract
void org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
INFO  - RequestListenerInterface   - registered listener interface
[RequestListenerInterface name=ILinkListener, method=public abstract
void org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
INFO  - RequestListenerInterface   - registered listener interface
[RequestListenerInterface name=IOnChangeListener, method=public abstract
void
org.apache.wicket.markup.html.form.IOnChangeListener.onSelectionChanged(
)]
INFO  - RequestListenerInterface   - registered listener interface
[RequestListenerInterface name=IOnChangeListener, method=public abstract
void
org.apache.wicket.markup.html.form.IOnChangeListener.onSelectionChanged(
)]
INFO  - RequestListenerInterface   - registered listener interface
[RequestListenerInterface name=IRedirectListener, method=public abstract
void org.apache.wicket.IRedirectListener.onRedirect()]
INFO  - RequestListenerInterface   - registered listener interface
[RequestListenerInterface name=IRedirectListener, method=public abstract
void org.apache.wicket.IRedirectListener.onRedirect()]
INFO  - RequestListenerInterface   - registered listener interface
[RequestListenerInterface name=IResourceListener, method=public abstract
void org.apache.wicket.IResourceListener.onResourceRequested()]
INFO  - RequestListenerInterface   - registered listener interface
[RequestListenerInterface name=IResourceListener, method=public abstract
void org.apache.wicket.IResourceListener.onResourceRequested()]
INFO  - Application- [TestApplication] init: Wicket
extensions initializer
INFO  - WebApplication - [TestApplication] Started Wicket
version 1.3.3 in development mode

*** WARNING: Wicket is running in DEVELOPMENT mode.  ***
***   ^^^***
*** Do NOT deploy to your live server(s) without changing this.  ***
*** See Application#getConfigurationType() for more information. ***

INFO  - log- Started
[EMAIL PROTECTED]:8080 





-Original Message-
From: Frank Silbermann [mailto:[EMAIL PROT

RE: Tomcat 5.5.9 isn't running Quickstart

[Frank Silbermann]

It's the identical .war file which shows the images when run in Tomcat 6
but not when run in Jetty configured as per the QuickStart application.
The actual HTML in the rendered pages is exactly what I showed you --
Wicket generated it using AttributeModifier, and I copied the generated
HTML by doing "show source" in my browser.

I'm guessing the Jetty has some default security not done in Tomcat that
is "protecting" my image files, which I need to override somehow.  Or
maybe it is not automatically recognizing .png files as a MIME-type.  Or
maybe there's something else that must be configured in Jetty to tell it
to look in the webapp folder for static content.  I posted about this on
the jetty-support mailing list last week
(http://www.nabble.com/-Jetty-support--Embedded-jetty-td8400457.html#a17
679320), but no one answered it.

-Original Message-
From: Gwyn Evans [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 11, 2008 3:51 PM
To: users@wicket.apache.org
Subject: Re: Tomcat 5.5.9 isn't running Quickstart

On Wed, Jun 11, 2008 at 9:00 PM, Frank Silbermann <
[EMAIL PROTECTED]> wrote:


> My application uses images much as does in Wicket's "images" example.

> I have some image files (e.g. "image1.png") stored directly inside the

> "webapp" folder, and my application references the images by 
> generating HTML like so:
>
...

>  < img wicket:id="picture" src="image1.png" alt="Picture"/ >
>
> The image appears when I run the application in Tomcat, but not when I

> run it in Eclipse with Jetty

...

That seems odd to me - the same web-app?  I'm probably way off base, but
I'd be double-checking where it's actually serving it from & the HTML in
the rendered pages...

/Gwyn


> ...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat 5.5.9 isn't running Quickstart

[Frank Silbermann]

I downloaded Tomcat 6 this morning, and the QuickStart project runs in
it without the logging conflict I had with Tomcat 5.5.9.  Perhaps a
newer release of Tomcat 5.5 would also work, but I'll just go to Tomcat
6.  However, I have a couple of follow-up questions:



(*) My old Wicket 1.2 application, which ran in Tomcat 5.5.9, doesn't
run in Tomcat 6!  My guess is that Tomcat 6 removed the logging .jar
that was interfering with the logging classes deployed with Wicket 1.3
applications, but now my Wicket 1.2 application on Tomcat 6 is lacking a
logging implementation.  Though I plan to upgrade all my Wicket 1.2
applications to Wicket 1.3, is there a recommended .jar I should add to
the lib directory of my Wicket 1.2 application so it runs in Tomcat 6?
(My Wicket 1.3 QuickStart adds log4j-1.2.14.jar, slf4j-api-1.4.2.jar,
and slf4j-log4j12-1.4.2.jar to the application's lib directory; my
Wicket 1.2 application does not add these.) 



(*) I really like the idea of debugging in Eclipse using in-process
Jetty, even if I do deploy to Tomcat.  Thanks to posts I found in the
archive of this mailing list, I was able to modify the QuickStart
configuration of Jetty to read the J2EE and Jetty configuration .xml
files that configure my data source.  However, I have another problem.
My application uses images much as does in Wicket's "images" example.  I
have some image files (e.g. "image1.png") stored directly inside the
"webapp" folder, and my application references the images by generating
HTML like so: 

http://www.w3.org/1999/xhtml";
xmlns:wicket="http://wicket.sourceforge.net/"; xml:lang="en" lang="en"> 
 
 
  < img wicket:id="picture" src="image1.png" alt="Picture"/ > 
 
 

The image appears when I run the application in Tomcat, but not when I
run it in Eclipse with Jetty (following the process described in
http://herebebeasties.com/2007-10-07/wicket-quickstart/).  What do I
need to change to the QuickStart's Jetty configuration so that this HTML
will be able to access the image?



-Original Message-
From: Frank Silbermann [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 3:08 PM
To: users@wicket.apache.org
Subject: RE: Tomcat 5.5.9 isn't running Quickstart

I did a Windows search for files with names containing "log4j" and came
up with nothing.  I wonder whether it could be bundled into other Tomcat
jars.  I'm using Tomcat 5.5.9, so maybe I should try a fresh install of
Tomcat, version 6, when I get back on Wednesday. 

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2008 2:57 PM
To: users@wicket.apache.org
Subject: Re: Tomcat 5.5.9 isn't running Quickstart

it doesnt sound right. tomcat itself is writing out logs and i dont
think it uses jdk logging. so there must be at least a log4j jar
somewhere in tomcat install..

we have deployed in 5.5 and 6.0 previously and everything works fine.

-igor

On Fri, Jun 6, 2008 at 9:31 AM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> The lib directory in the QuickStart's WEB-INF contains:
>
>log4j-1.2.14.jar
>slf4j-api-1.4.2.jar
>slf4j-log4j12-1.4.2.jar
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2008 11:27 AM
> To: users@wicket.apache.org
> Subject: Re: Tomcat 5.5.9 isn't running Quickstart
>
> you have to at least also have log4j in there somewhere.
> commons-logging is just the pipeline..
>
> -igor
>
> On Fri, Jun 6, 2008 at 9:15 AM, Frank Silbermann 
> <[EMAIL PROTECTED]> wrote:
>> Well, aside from the logging-oriented jars that maven packs into the 
>> QuickStart's lib folder, the only logging jar I can see in Tomcat is 
>> in Tomcat's bin folder, named
>>
>> commons-logging-api.jar
>>
>> dated 3/26/2005.
>>
>> Do I need to replace that with a more recent version?  Would you 
>> recommend moving to the current version of Tomcat to avoid
> side-effects?
>>
>>
>> -Original Message-
>> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>> Sent: Friday, June 06, 2008 11:07 AM
>> To: users@wicket.apache.org
>> Subject: Re: Tomcat 5.5.9 isn't running Quickstart
>>
>> well, there you go, something funky with your logger jars
>>
>> -igor
>>
>> On Fri, Jun 6, 2008 at 9:03 AM, Frank Silbermann 
>> <[EMAIL PROTECTED]> wrote:
>>> Ah, yes, I thought I had checked those, but I must have missed the 
>>> right log.  The error messages are:
>>>
>>> The catalina.log file contains:
>>>
>>> INFO: Stopping service Catalina
>>> Jun 6, 2008 10:58:23 AM org.apache.catalina.l

RE: Tomcat 5.5.9 isn't running Quickstart

[Frank Silbermann]

I did a Windows search for files with names containing "log4j" and came
up with nothing.  I wonder whether it could be bundled into other Tomcat
jars.  I'm using Tomcat 5.5.9, so maybe I should try a fresh install of
Tomcat, version 6, when I get back on Wednesday. 

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 2:57 PM
To: users@wicket.apache.org
Subject: Re: Tomcat 5.5.9 isn't running Quickstart

it doesnt sound right. tomcat itself is writing out logs and i dont
think it uses jdk logging. so there must be at least a log4j jar
somewhere in tomcat install..

we have deployed in 5.5 and 6.0 previously and everything works fine.

-igor

On Fri, Jun 6, 2008 at 9:31 AM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> The lib directory in the QuickStart's WEB-INF contains:
>
>log4j-1.2.14.jar
>slf4j-api-1.4.2.jar
>slf4j-log4j12-1.4.2.jar
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2008 11:27 AM
> To: users@wicket.apache.org
> Subject: Re: Tomcat 5.5.9 isn't running Quickstart
>
> you have to at least also have log4j in there somewhere.
> commons-logging is just the pipeline..
>
> -igor
>
> On Fri, Jun 6, 2008 at 9:15 AM, Frank Silbermann 
> <[EMAIL PROTECTED]> wrote:
>> Well, aside from the logging-oriented jars that maven packs into the 
>> QuickStart's lib folder, the only logging jar I can see in Tomcat is 
>> in Tomcat's bin folder, named
>>
>> commons-logging-api.jar
>>
>> dated 3/26/2005.
>>
>> Do I need to replace that with a more recent version?  Would you 
>> recommend moving to the current version of Tomcat to avoid
> side-effects?
>>
>>
>> -Original Message-
>> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>> Sent: Friday, June 06, 2008 11:07 AM
>> To: users@wicket.apache.org
>> Subject: Re: Tomcat 5.5.9 isn't running Quickstart
>>
>> well, there you go, something funky with your logger jars
>>
>> -igor
>>
>> On Fri, Jun 6, 2008 at 9:03 AM, Frank Silbermann 
>> <[EMAIL PROTECTED]> wrote:
>>> Ah, yes, I thought I had checked those, but I must have missed the 
>>> right log.  The error messages are:
>>>
>>> The catalina.log file contains:
>>>
>>> INFO: Stopping service Catalina
>>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>>> findResourceInternal
>>> INFO: Illegal access: this web application instance has been stopped

>>> already.  Could not load commons-logging.properties.  The eventual 
>>> following stack trace is caused by an error thrown for debugging 
>>> purposes as well as to attempt to terminate the thread which caused 
>>> the illegal access, and has no functional impact.
>>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>>> findResourceInternal
>>> INFO: Illegal access: this web application instance has been stopped

>>> already.  Could not load 
>>> META-INF/services/org.apache.commons.logging.LogFactory.  The 
>>> eventual
>>
>>> following stack trace is caused by an error thrown for debugging 
>>> purposes as well as to attempt to terminate the thread which caused 
>>> the illegal access, and has no functional impact.
>>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>>> loadClass
>>> INFO: Illegal access: this web application instance has been stopped

>>> already.  Could not load org.apache.log4j.Logger.  The eventual 
>>> following stack trace is caused by an error thrown for debugging 
>>> purposes as well as to attempt to terminate the thread which caused 
>>> the illegal access, and has no functional impact.
>>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>>> loadClass
>>> INFO: Illegal access: this web application instance has been stopped

>>> already.  Could not load java.util.logging.Logger.  The eventual 
>>> following stack trace is caused by an error thrown for debugging 
>>> purposes as well as to attempt to terminate the thread which caused 
>>> the illegal access, and has no functional impact.
>>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>>> loadClass
>>> INFO: Illegal access: this web application instance has been stopped

>>> already.  Could not load org.apache.log4j.Logger.  The eventual 
>>> following stack trace is caused by an error thrown for debugging 
>>

RE: Tomcat 5.5.9 isn't running Quickstart

[Frank Silbermann]

Well, it suggests I should replace commons-logging-api.jar with
commons-logging-1.1-api.jar, but when I tried that Tomcat failed to
start up.  Is there something else I need to do at the same time?

-- 
At the current date, Tomcat 5.5.16 is the current release. All releases
from version 4.1.x through 5.5.16 have a startup process that places
jarfile ${tomcat.home}/bin/commons-logging-api.jar in the system
classpath and then prevents any webapp from overriding the classes in
that jarfile. Effectively, all webapps behave as if "parent-first"
classloading were enabled for those classes. 

This has some benefits; in particular it means that there are no
problems in these Tomcat versions with having multiple copies of the
commons-logging Log interface in the classpath (which avoids the "Log
does not implement Log" problem described elsewhere). 

However it also means that no webapp can override the core
commons-logging classes by including an updated commons-logging jarfile
in WEB-INF/lib; any class already loaded via the container takes
priority. In particular, as Tomcat bundles logging 1.0.4 only, the new
diagnostics and memory-leak-prevention features of the 1.1 release will
not be available unless the container's library version is updated. 

Because the commons-logging-api.jar in the container does not contain
any log-library-adapter classes, updated behaviour for these will be
seen when logging 1.1 is bundled in WEB-INF/lib. In particular, the
support for log4j's TRACE level will take effect without having to
update the container. 

If you do wish to update Tomcat's version of commons-logging, then you
must use the commons-logging-1.1-api jar only, not the full jar. Classes
in the webapp cannot override classes loaded from the system classpath
set up during Tomcat's startup process, and logging adapters can only
see their matching concrete logging library if that library is available
in the same classpath. Bundling the full commons-logging jarfile (with
adapters) into the system classpath therefore means that logging
libraries (eg log4j) within WEB-INF/lib are not accessable. 

Note that the behaviour described here only applies if the standard
Tomcat startup process is run. When Tomcat is embedded in a larger
framework (eg run embedded within an IDE) this may not apply. 
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of James Carman
Sent: Friday, June 06, 2008 2:50 PM
To: users@wicket.apache.org
Subject: Re: Tomcat 5.5.9 isn't running Quickstart

Our test/production servers are running Tomcat just fine.  Check this
out and I think it'll help you:

http://commons.apache.org/logging/troubleshooting.html#Apache%20Tomcat


On Fri, Jun 6, 2008 at 3:44 PM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
>
>
> Documentation for the jcl-over-slf4j.jar () says it replaces 
> commons-logging.jar -- which I cannot find anywhere in my Tomcat 
> installation.  All I've found is commons-logging-api.jar in the 
> {Tomcat installation}/bin directory.  When I do the replacement, 
> Tomcat fails to start.
>
> I'm having trouble finding any documentation that specifically speaks 
> of configuring Tomcat for this purpose.  Hasn't _anyone_ made the 
> Wicket
> 1.3 QuickStart project run in Tomcat?  Yes, I plan to use Jetty for 
> development, but I don't think my company's architecture committee has

> approved Jetty for deployment.  It seems to me that I ought to be able

> to run a Java web application in any J2EE-compliant webserver.
>
>So, does this so
>
>-Original Message-
>From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of James Carman
>Sent: Friday, June 06, 2008 1:01 PM
>To: users@wicket.apache.org
>Subject: Re: Tomcat 5.5.9 isn't running Quickstart
>
>I would also check the tomcat/JCL documentation.  I seem to 
> remember there being some very specific instructions on one of their 
> sites about this issue.
>
>On Fri, Jun 6, 2008 at 1:54 PM, Gwyn Evans 
> <[EMAIL PROTECTED]> wrote:
>> That's a bit odd then...  One thing you could try is adding 
> in SLF4J's
>> jcl-over-slf4j.jar instead of any commons-logging jars.  That

> would
>> redirect any Commons-Logging logging to SLF4J.
>>
>> (Personally I'd also be looking to go with James' suggestion 
> of
>> switching to Jetty, as I find that to be both clearer to 
> debug and
>> more forgiving in terms of class-loading issues, but that may

> not be
>> possible...)
>>
>> /Gwyn
>>
>> On Fri, Jun 6, 2008 at 5:31 PM, Frank 

RE: Tomcat 5.5.9 isn't running Quickstart

[Frank Silbermann]

Yes, there do seem to be classloading problems with Tomcat 5.5 that
prevent it from finding the application's classes, but I haven't found a
solution for it.  

No, I haven't tried Tomcat 6.  Has anyone tried running the Wicket 1.3
QuickStart program in Tomcat 6?

-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 1:48 PM
To: users@wicket.apache.org
Subject: Re: Tomcat 5.5.9 isn't running Quickstart

And if you use toimcat 6?

It could be classloading problems one (commons) cant find the stuff in
the web folder

On 6/6/08, Frank Silbermann <[EMAIL PROTECTED]> wrote:
> Well, aside from the logging-oriented jars that maven packs into the 
> QuickStart's lib folder, the only logging jar I can see in Tomcat is 
> in Tomcat's bin folder, named
>
> commons-logging-api.jar
>
> dated 3/26/2005.
>
> Do I need to replace that with a more recent version?  Would you 
> recommend moving to the current version of Tomcat to avoid
side-effects?
>
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2008 11:07 AM
> To: users@wicket.apache.org
> Subject: Re: Tomcat 5.5.9 isn't running Quickstart
>
> well, there you go, something funky with your logger jars
>
> -igor
>
> On Fri, Jun 6, 2008 at 9:03 AM, Frank Silbermann 
> <[EMAIL PROTECTED]> wrote:
>> Ah, yes, I thought I had checked those, but I must have missed the 
>> right log.  The error messages are:
>>
>> The catalina.log file contains:
>>
>> INFO: Stopping service Catalina
>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>> findResourceInternal
>> INFO: Illegal access: this web application instance has been stopped 
>> already.  Could not load commons-logging.properties.  The eventual 
>> following stack trace is caused by an error thrown for debugging 
>> purposes as well as to attempt to terminate the thread which caused 
>> the illegal access, and has no functional impact.
>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>> findResourceInternal
>> INFO: Illegal access: this web application instance has been stopped 
>> already.  Could not load 
>> META-INF/services/org.apache.commons.logging.LogFactory.  The 
>> eventual
>
>> following stack trace is caused by an error thrown for debugging 
>> purposes as well as to attempt to terminate the thread which caused 
>> the illegal access, and has no functional impact.
>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>> loadClass
>> INFO: Illegal access: this web application instance has been stopped 
>> already.  Could not load org.apache.log4j.Logger.  The eventual 
>> following stack trace is caused by an error thrown for debugging 
>> purposes as well as to attempt to terminate the thread which caused 
>> the illegal access, and has no functional impact.
>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>> loadClass
>> INFO: Illegal access: this web application instance has been stopped 
>> already.  Could not load java.util.logging.Logger.  The eventual 
>> following stack trace is caused by an error thrown for debugging 
>> purposes as well as to attempt to terminate the thread which caused 
>> the illegal access, and has no functional impact.
>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>> loadClass
>> INFO: Illegal access: this web application instance has been stopped 
>> already.  Could not load org.apache.log4j.Logger.  The eventual 
>> following stack trace is caused by an error thrown for debugging 
>> purposes as well as to attempt to terminate the thread which caused 
>> the illegal access, and has no functional impact.
>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>> loadClass
>> INFO: Illegal access: this web application instance has been stopped 
>> already.  Could not load java.util.logging.Logger.  The eventual 
>> following stack trace is caused by an error thrown for debugging 
>> purposes as well as to attempt to terminate the thread which caused 
>> the illegal access, and has no functional impact.
>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>> loadClass
>> INFO: Illegal access: this web application instance has been stopped 
>> already.  Could not load java.util.logging.Logger.  The eventual 
>> following stack trace is caused by an error thrown for debugging 
>> purposes as well as to attempt to terminate the thread which caused 
>> the illegal access, and has no func

RE: Tomcat 5.5.9 isn't running Quickstart

[Frank Silbermann]

Documentation for the jcl-over-slf4j.jar () says it replaces
commons-logging.jar -- which I cannot find anywhere in my Tomcat
installation.  All I've found is commons-logging-api.jar in the {Tomcat
installation}/bin directory.  When I do the replacement, Tomcat fails to
start.

I'm having trouble finding any documentation that specifically speaks of
configuring Tomcat for this purpose.  Hasn't _anyone_ made the Wicket
1.3 QuickStart project run in Tomcat?  Yes, I plan to use Jetty for
development, but I don't think my company's architecture committee has
approved Jetty for deployment.  It seems to me that I ought to be able
to run a Java web application in any J2EE-compliant webserver.  

So, does this so

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James Carman
Sent: Friday, June 06, 2008 1:01 PM
To: users@wicket.apache.org
Subject: Re: Tomcat 5.5.9 isn't running Quickstart

I would also check the tomcat/JCL documentation.  I seem to
remember there being some very specific instructions on one of their
sites about this issue.

On Fri, Jun 6, 2008 at 1:54 PM, Gwyn Evans
<[EMAIL PROTECTED]> wrote:
> That's a bit odd then...  One thing you could try is adding in
SLF4J's
> jcl-over-slf4j.jar instead of any commons-logging jars.  That
would
> redirect any Commons-Logging logging to SLF4J.
>
> (Personally I'd also be looking to go with James' suggestion
of
> switching to Jetty, as I find that to be both clearer to debug
and
> more forgiving in terms of class-loading issues, but that may
not be
> possible...)
    >
    > /Gwyn
>
> On Fri, Jun 6, 2008 at 5:31 PM, Frank Silbermann
> <[EMAIL PROTECTED]> wrote:
>> The lib directory in the QuickStart's WEB-INF contains:
>>
>>log4j-1.2.14.jar
>>slf4j-api-1.4.2.jar
>>slf4j-log4j12-1.4.2.jar
>>
>> -Original Message-
>> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>> Sent: Friday, June 06, 2008 11:27 AM
>> To: users@wicket.apache.org
>> Subject: Re: Tomcat 5.5.9 isn't running Quickstart
>>
>> you have to at least also have log4j in there somewhere.
>> commons-logging is just the pipeline..
>>
>> -igor
>>
>> On Fri, Jun 6, 2008 at 9:15 AM, Frank Silbermann
>> <[EMAIL PROTECTED]> wrote:
>>> Well, aside from the logging-oriented jars that maven packs
into the
>>> QuickStart's lib folder, the only logging jar I can see in
Tomcat is
>>> in Tomcat's bin folder, named
>>>
>>> commons-logging-api.jar
>>>
>>> dated 3/26/2005.
>>>
>>> Do I need to replace that with a more recent version?  Would
you
>>> recommend moving to the current version of Tomcat to avoid
>> side-effects?
>>>
>>>
>>> -Original Message-
>>> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>>> Sent: Friday, June 06, 2008 11:07 AM
>>> To: users@wicket.apache.org
>>> Subject: Re: Tomcat 5.5.9 isn't running Quickstart
>>>
>>> well, there you go, something funky with your logger jars
>>>
>>> -igor
>>>
>>> On Fri, Jun 6, 2008 at 9:03 AM, Frank Silbermann
>>> <[EMAIL PROTECTED]> wrote:
>>>> Ah, yes, I thought I had checked those, but I must have
missed the
>>>> right log.  The error messages are:
>>>>
>>>> The catalina.log file contains:
>>>>
>>>> INFO: Stopping service Catalina
>>>> Jun 6, 2008 10:58:23 AM
>>>> org.apache.catalina.loader.WebappClassLoader
>>>> findResourceInternal
>>>> INFO: Illegal access: this web application instance has
been
>>>> stopped already.  Could not load
commons-logging.properties.  The
>>>> eventual following stack trace is caused by an error thrown
for
>>>> debugging purposes as well as to attempt to terminate the
thread
>>>> which caused the illegal access, and has no functional
impact.
>>>> Jun 6,

RE: Tomcat 5.5.9 isn't running Quickstart

[Frank Silbermann]

The lib directory in the QuickStart's WEB-INF contains:

log4j-1.2.14.jar
slf4j-api-1.4.2.jar
slf4j-log4j12-1.4.2.jar

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 11:27 AM
To: users@wicket.apache.org
Subject: Re: Tomcat 5.5.9 isn't running Quickstart

you have to at least also have log4j in there somewhere.
commons-logging is just the pipeline..

-igor

On Fri, Jun 6, 2008 at 9:15 AM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> Well, aside from the logging-oriented jars that maven packs into the 
> QuickStart's lib folder, the only logging jar I can see in Tomcat is 
> in Tomcat's bin folder, named
>
> commons-logging-api.jar
>
> dated 3/26/2005.
>
> Do I need to replace that with a more recent version?  Would you 
> recommend moving to the current version of Tomcat to avoid
side-effects?
>
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2008 11:07 AM
> To: users@wicket.apache.org
> Subject: Re: Tomcat 5.5.9 isn't running Quickstart
>
> well, there you go, something funky with your logger jars
>
> -igor
>
> On Fri, Jun 6, 2008 at 9:03 AM, Frank Silbermann 
> <[EMAIL PROTECTED]> wrote:
>> Ah, yes, I thought I had checked those, but I must have missed the 
>> right log.  The error messages are:
>>
>> The catalina.log file contains:
>>
>> INFO: Stopping service Catalina
>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>> findResourceInternal
>> INFO: Illegal access: this web application instance has been stopped 
>> already.  Could not load commons-logging.properties.  The eventual 
>> following stack trace is caused by an error thrown for debugging 
>> purposes as well as to attempt to terminate the thread which caused 
>> the illegal access, and has no functional impact.
>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>> findResourceInternal
>> INFO: Illegal access: this web application instance has been stopped 
>> already.  Could not load 
>> META-INF/services/org.apache.commons.logging.LogFactory.  The 
>> eventual
>
>> following stack trace is caused by an error thrown for debugging 
>> purposes as well as to attempt to terminate the thread which caused 
>> the illegal access, and has no functional impact.
>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>> loadClass
>> INFO: Illegal access: this web application instance has been stopped 
>> already.  Could not load org.apache.log4j.Logger.  The eventual 
>> following stack trace is caused by an error thrown for debugging 
>> purposes as well as to attempt to terminate the thread which caused 
>> the illegal access, and has no functional impact.
>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>> loadClass
>> INFO: Illegal access: this web application instance has been stopped 
>> already.  Could not load java.util.logging.Logger.  The eventual 
>> following stack trace is caused by an error thrown for debugging 
>> purposes as well as to attempt to terminate the thread which caused 
>> the illegal access, and has no functional impact.
>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>> loadClass
>> INFO: Illegal access: this web application instance has been stopped 
>> already.  Could not load org.apache.log4j.Logger.  The eventual 
>> following stack trace is caused by an error thrown for debugging 
>> purposes as well as to attempt to terminate the thread which caused 
>> the illegal access, and has no functional impact.
>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>> loadClass
>> INFO: Illegal access: this web application instance has been stopped 
>> already.  Could not load java.util.logging.Logger.  The eventual 
>> following stack trace is caused by an error thrown for debugging 
>> purposes as well as to attempt to terminate the thread which caused 
>> the illegal access, and has no functional impact.
>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>> loadClass
>> INFO: Illegal access: this web application instance has been stopped 
>> already.  Could not load java.util.logging.Logger.  The eventual 
>> following stack trace is caused by an error thrown for debugging 
>> purposes as well as to attempt to terminate the thread which caused 
>> the illegal access, and has no functional impact.
>> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
>> loadClass
>>

RE: Tomcat 5.5.9 isn't running Quickstart

[Frank Silbermann]

Well, aside from the logging-oriented jars that maven packs into the
QuickStart's lib folder, the only logging jar I can see in Tomcat is in
Tomcat's bin folder, named 

commons-logging-api.jar 

dated 3/26/2005.

Do I need to replace that with a more recent version?  Would you
recommend moving to the current version of Tomcat to avoid side-effects?


-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 11:07 AM
To: users@wicket.apache.org
Subject: Re: Tomcat 5.5.9 isn't running Quickstart

well, there you go, something funky with your logger jars

-igor

On Fri, Jun 6, 2008 at 9:03 AM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> Ah, yes, I thought I had checked those, but I must have missed the 
> right log.  The error messages are:
>
> The catalina.log file contains:
>
> INFO: Stopping service Catalina
> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
> findResourceInternal
> INFO: Illegal access: this web application instance has been stopped 
> already.  Could not load commons-logging.properties.  The eventual 
> following stack trace is caused by an error thrown for debugging 
> purposes as well as to attempt to terminate the thread which caused 
> the illegal access, and has no functional impact.
> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
> findResourceInternal
> INFO: Illegal access: this web application instance has been stopped 
> already.  Could not load 
> META-INF/services/org.apache.commons.logging.LogFactory.  The eventual

> following stack trace is caused by an error thrown for debugging 
> purposes as well as to attempt to terminate the thread which caused 
> the illegal access, and has no functional impact.
> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
> loadClass
> INFO: Illegal access: this web application instance has been stopped 
> already.  Could not load org.apache.log4j.Logger.  The eventual 
> following stack trace is caused by an error thrown for debugging 
> purposes as well as to attempt to terminate the thread which caused 
> the illegal access, and has no functional impact.
> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
> loadClass
> INFO: Illegal access: this web application instance has been stopped 
> already.  Could not load java.util.logging.Logger.  The eventual 
> following stack trace is caused by an error thrown for debugging 
> purposes as well as to attempt to terminate the thread which caused 
> the illegal access, and has no functional impact.
> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
> loadClass
> INFO: Illegal access: this web application instance has been stopped 
> already.  Could not load org.apache.log4j.Logger.  The eventual 
> following stack trace is caused by an error thrown for debugging 
> purposes as well as to attempt to terminate the thread which caused 
> the illegal access, and has no functional impact.
> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
> loadClass
> INFO: Illegal access: this web application instance has been stopped 
> already.  Could not load java.util.logging.Logger.  The eventual 
> following stack trace is caused by an error thrown for debugging 
> purposes as well as to attempt to terminate the thread which caused 
> the illegal access, and has no functional impact.
> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
> loadClass
> INFO: Illegal access: this web application instance has been stopped 
> already.  Could not load java.util.logging.Logger.  The eventual 
> following stack trace is caused by an error thrown for debugging 
> purposes as well as to attempt to terminate the thread which caused 
> the illegal access, and has no functional impact.
> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
> loadClass
> INFO: Illegal access: this web application instance has been stopped 
> already.  Could not load org.apache.commons.logging.impl.SimpleLog.  
> The eventual following stack trace is caused by an error thrown for 
> debugging purposes as well as to attempt to terminate the thread which

> caused the illegal access, and has no functional impact.
> Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
> loadClass
> INFO: Illegal access: this web application instance has been stopped 
> already.  Could not load org.apache.commons.logging.impl.SimpleLog.  
> The eventual following stack trace is caused by an error thrown for 
> debugging purposes as well as to attempt to terminate the thread which

> caused the illegal access, and has no functional impact.
> Jun 6, 2008 10:58:23 AM org.apache.coyote.http11.Http11Protocol 
> destro

RE: Tomcat 5.5.9 isn't running Quickstart

[Frank Silbermann]

Ah, yes, I thought I had checked those, but I must have missed the right
log.  The error messages are:

The catalina.log file contains:

INFO: Stopping service Catalina
Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
findResourceInternal
INFO: Illegal access: this web application instance has been stopped
already.  Could not load commons-logging.properties.  The eventual
following stack trace is caused by an error thrown for debugging
purposes as well as to attempt to terminate the thread which caused the
illegal access, and has no functional impact.
Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
findResourceInternal
INFO: Illegal access: this web application instance has been stopped
already.  Could not load
META-INF/services/org.apache.commons.logging.LogFactory.  The eventual
following stack trace is caused by an error thrown for debugging
purposes as well as to attempt to terminate the thread which caused the
illegal access, and has no functional impact.
Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
loadClass
INFO: Illegal access: this web application instance has been stopped
already.  Could not load org.apache.log4j.Logger.  The eventual
following stack trace is caused by an error thrown for debugging
purposes as well as to attempt to terminate the thread which caused the
illegal access, and has no functional impact.
Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
loadClass
INFO: Illegal access: this web application instance has been stopped
already.  Could not load java.util.logging.Logger.  The eventual
following stack trace is caused by an error thrown for debugging
purposes as well as to attempt to terminate the thread which caused the
illegal access, and has no functional impact.
Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
loadClass
INFO: Illegal access: this web application instance has been stopped
already.  Could not load org.apache.log4j.Logger.  The eventual
following stack trace is caused by an error thrown for debugging
purposes as well as to attempt to terminate the thread which caused the
illegal access, and has no functional impact.
Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
loadClass
INFO: Illegal access: this web application instance has been stopped
already.  Could not load java.util.logging.Logger.  The eventual
following stack trace is caused by an error thrown for debugging
purposes as well as to attempt to terminate the thread which caused the
illegal access, and has no functional impact.
Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
loadClass
INFO: Illegal access: this web application instance has been stopped
already.  Could not load java.util.logging.Logger.  The eventual
following stack trace is caused by an error thrown for debugging
purposes as well as to attempt to terminate the thread which caused the
illegal access, and has no functional impact.
Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
loadClass
INFO: Illegal access: this web application instance has been stopped
already.  Could not load org.apache.commons.logging.impl.SimpleLog.  The
eventual following stack trace is caused by an error thrown for
debugging purposes as well as to attempt to terminate the thread which
caused the illegal access, and has no functional impact.
Jun 6, 2008 10:58:23 AM org.apache.catalina.loader.WebappClassLoader
loadClass
INFO: Illegal access: this web application instance has been stopped
already.  Could not load org.apache.commons.logging.impl.SimpleLog.  The
eventual following stack trace is caused by an error thrown for
debugging purposes as well as to attempt to terminate the thread which
caused the illegal access, and has no functional impact.
Jun 6, 2008 10:58:23 AM org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8080

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 10:50 AM
To: users@wicket.apache.org
Subject: Re: Tomcat 5.5.9 isn't running Quickstart

how about the tomcat log...

-igor

On Fri, Jun 6, 2008 at 8:49 AM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> Any suggestions as to where I should look for clues?
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2008 10:46 AM
> To: users@wicket.apache.org
> Subject: Re: Tomcat 5.5.9 isn't running Quickstart
>
> correct course of action is to figure out why its not running in 
> tomcat
>
> -igor
>
> On Fri, Jun 6, 2008 at 8:39 AM, Frank Silbermann 
> <[EMAIL PROTECTED]> wrote:
>> I have the quickstart program and have been able to run it in Eclipse

>> following the directions in 
>> http://herebebeasties.com/2007-10-07/wicket-quickstart/
>>
>> Also, I used "mvn package" to build the web appli

RE: Tomcat 5.5.9 isn't running Quickstart

[Frank Silbermann]

Any suggestions as to where I should look for clues? 

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 10:46 AM
To: users@wicket.apache.org
Subject: Re: Tomcat 5.5.9 isn't running Quickstart

correct course of action is to figure out why its not running in tomcat

-igor

On Fri, Jun 6, 2008 at 8:39 AM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> I have the quickstart program and have been able to run it in Eclipse 
> following the directions in 
> http://herebebeasties.com/2007-10-07/wicket-quickstart/
>
> Also, I used "mvn package" to build the web application and .war
>
> I tried copying the myproject-1.0-SNAPSHOT folder (and I also tried 
> the .war file) into the webapps folder to Tomcat 5.5.9 and started up 
> Tomcat.  When I entered http://127.0.0.1:8080/myproject/ (or
> http://localhost:8080/myproject/) it failed to serve the quickstart 
> project.  Do I need a more recent version of Tomcat for running Wicket

> 1.3, or is there something else I need to do to configure it for
Tomcat?
> This is what it told me:
>
> HTTP Status 404 - /myproject/
>
> --
> --
> 
>
> type Status report
>
> message /myproject/
>
> description The requested resource (/myproject/) is not available.
>
>
> --
> --
> 
>
> Apache Tomcat/5.5.9
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tomcat 5.5.9 isn't running Quickstart

[Frank Silbermann]

I have the quickstart program and have been able to run it in Eclipse
following the directions in
http://herebebeasties.com/2007-10-07/wicket-quickstart/

Also, I used "mvn package" to build the web application and .war

I tried copying the myproject-1.0-SNAPSHOT folder (and I also tried the
.war file) into the webapps folder to Tomcat 5.5.9 and started up
Tomcat.  When I entered http://127.0.0.1:8080/myproject/ (or
http://localhost:8080/myproject/) it failed to serve the quickstart
project.  Do I need a more recent version of Tomcat for running Wicket
1.3, or is there something else I need to do to configure it for Tomcat?
This is what it told me:

HTTP Status 404 - /myproject/




type Status report

message /myproject/

description The requested resource (/myproject/) is not available.





Apache Tomcat/5.5.9



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Bug introduced somewhere after 1.2.2 is still in 1.3.3

[Frank Silbermann]

I added https://issues.apache.org/jira/browse/WICKET-1621 to say that
the Component Example for RadioGroup, which contains a ListView of Form
components, ought to call #setReuseItems(true).

The example as written works, of course, but not when I put two such
RadioGroups on the page.  A person who adapts the examples without
reading the JavaDoc can get into trouble, as I did.

/Frank 

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 09, 2008 12:52 PM
To: users@wicket.apache.org
Subject: Re: Bug introduced somewhere after 1.2.2 is still in 1.3.3

call setReuseItems(true) on the listview that contains radio components.
javadoc of listview recommends this for listviews inside forms that
contain formcomponents.

-igor


On Thu, May 8, 2008 at 1:49 PM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> Here's the URL of my jira issue.
>
> https://issues.apache.org/jira/browse/WICKET-1601
>
> The issue has attached a quickstart project and a screen print.
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 08, 2008 12:13 PM
> To: users@wicket.apache.org
> Subject: Re: Bug introduced somewhere after 1.2.2 is still in 1.3.3
>
> On Thu, May 8, 2008 at 10:06 AM, Frank Silbermann 
> <[EMAIL PROTECTED]> wrote:
>> I wrote earlier about my problems going from Wicket 1.2.2 to Wicket 
>> 1.2.6.  This has to do with a RadioGroup component that I built; 
>> whenever I used it on more than one page, clicking on one RadioGroup 
>> caused the marker to disapper from all the other RadioGroups on the 
>> page.
>>
>>  I wasn't given much help because Wicket 1.2 is end-of-life.  Today I
>
>> tried the example on Wicked 1.3.3.  I downloaded the QuickStart 
>> application for Wicket 1.3.3, installed an upgraded version of my 
>> RadioGroup component, modified the home page to show my RadioGroup 
>> panel  twice, and the bad behavior is still there.
>>
>>  By the way, the only change in the generated HTML that I could see 
>> was  that in Wicket 1.2.2 the buttons were defined:
>>
>> >
>>  -- with the numbers starting over again for each RadioGroup, whereas

>> in  Wicket 1.2.6 and Wicket 1.3.3 it was more like:
>>
>> >
>>  with the numbers _not_ starting over for each RadioGroup.  Clicking 
>> on  one radio group causes the marker to disappear from the other 
>> radio  group -- as if part of Wicket were treating the buttons as 
>> though they  all belonged to the same radio group.
>>
>>  I'd like the Wicket 1.3 developers either to fix the bug in a future
>
>> release (after which I'll upgrade my entire application to 1.3), or 
>> tell  me what I'm doing wrong.  How do I get the process started?
>
> the usual way, create a jira issue and attach a quickstart project 
> that demonstrates the problem. than post the jira url back into this
thread.
> it is not very helpful when you post huge fragments of code and markup

> into an email.
>
> -igor
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Bug introduced somewhere after 1.2.2 is still in 1.3.3

[Frank Silbermann]

That sounds convenient.  But what if someone wants his Form to contain a
ListView that _doesn't_ contain form components?  

-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 09, 2008 1:57 PM
To: users@wicket.apache.org
Subject: Re: Bug introduced somewhere after 1.2.2 is still in 1.3.3

we could make this automatic?
search for a parent that is a Form?

johan


On Fri, May 9, 2008 at 7:52 PM, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:

> call setReuseItems(true) on the listview that contains radio 
> components. javadoc of listview recommends this for listviews inside 
> forms that contain formcomponents.
>
> -igor
>
>
> On Thu, May 8, 2008 at 1:49 PM, Frank Silbermann 
> <[EMAIL PROTECTED]> wrote:
> > Here's the URL of my jira issue.
> >
> > https://issues.apache.org/jira/browse/WICKET-1601
> >
> > The issue has attached a quickstart project and a screen print.
> >
> > -Original Message-
> > From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, May 08, 2008 12:13 PM
> > To: users@wicket.apache.org
> > Subject: Re: Bug introduced somewhere after 1.2.2 is still in 1.3.3
> >
> > On Thu, May 8, 2008 at 10:06 AM, Frank Silbermann 
> > <[EMAIL PROTECTED]> wrote:
> >> I wrote earlier about my problems going from Wicket 1.2.2 to Wicket

> >> 1.2.6.  This has to do with a RadioGroup component that I built; 
> >> whenever I used it on more than one page, clicking on one 
> >> RadioGroup caused the marker to disapper from all the other 
> >> RadioGroups on the page.
> >>
> >>  I wasn't given much help because Wicket 1.2 is end-of-life.  Today

> >> I
> >
> >> tried the example on Wicked 1.3.3.  I downloaded the QuickStart 
> >> application for Wicket 1.3.3, installed an upgraded version of my 
> >> RadioGroup component, modified the home page to show my RadioGroup 
> >> panel  twice, and the bad behavior is still there.
> >>
> >>  By the way, the only change in the generated HTML that I could see

> >> was  that in Wicket 1.2.2 the buttons were defined:
> >>
> >>  >>
> >>  -- with the numbers starting over again for each RadioGroup, 
> >> whereas in  Wicket 1.2.6 and Wicket 1.3.3 it was more like:
> >>
> >>  >>
> >>  with the numbers _not_ starting over for each RadioGroup.  
> >> Clicking on  one radio group causes the marker to disappear from 
> >> the other radio  group -- as if part of Wicket were treating the 
> >> buttons as though they  all belonged to the same radio group.
> >>
> >>  I'd like the Wicket 1.3 developers either to fix the bug in a 
> >> future
> >
> >> release (after which I'll upgrade my entire application to 1.3), or

> >> tell  me what I'm doing wrong.  How do I get the process started?
> >
> > the usual way, create a jira issue and attach a quickstart project 
> > that demonstrates the problem. than post the jira url back into this
thread.
> > it is not very helpful when you post huge fragments of code and 
> > markup into an email.
> >
> > -igor
> >
> >
> > 
> > - To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Bug introduced somewhere after 1.2.2 is still in 1.3.3

[Frank Silbermann]

I can search my application for ListView occuring in a form and do this.
Are there any other components that require something like this when
used in a Form?  E.g. in Wicket Extensions?

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 09, 2008 12:52 PM
To: users@wicket.apache.org
Subject: Re: Bug introduced somewhere after 1.2.2 is still in 1.3.3

call setReuseItems(true) on the listview that contains radio components.
javadoc of listview recommends this for listviews inside forms that
contain formcomponents.

-igor


On Thu, May 8, 2008 at 1:49 PM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> Here's the URL of my jira issue.
>
> https://issues.apache.org/jira/browse/WICKET-1601
>
> The issue has attached a quickstart project and a screen print.
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 08, 2008 12:13 PM
> To: users@wicket.apache.org
> Subject: Re: Bug introduced somewhere after 1.2.2 is still in 1.3.3
>
> On Thu, May 8, 2008 at 10:06 AM, Frank Silbermann 
> <[EMAIL PROTECTED]> wrote:
>> I wrote earlier about my problems going from Wicket 1.2.2 to Wicket 
>> 1.2.6.  This has to do with a RadioGroup component that I built; 
>> whenever I used it on more than one page, clicking on one RadioGroup 
>> caused the marker to disapper from all the other RadioGroups on the 
>> page.
>>
>>  I wasn't given much help because Wicket 1.2 is end-of-life.  Today I
>
>> tried the example on Wicked 1.3.3.  I downloaded the QuickStart 
>> application for Wicket 1.3.3, installed an upgraded version of my 
>> RadioGroup component, modified the home page to show my RadioGroup 
>> panel  twice, and the bad behavior is still there.
>>
>>  By the way, the only change in the generated HTML that I could see 
>> was  that in Wicket 1.2.2 the buttons were defined:
>>
>> >
>>  -- with the numbers starting over again for each RadioGroup, whereas

>> in  Wicket 1.2.6 and Wicket 1.3.3 it was more like:
>>
>> >
>>  with the numbers _not_ starting over for each RadioGroup.  Clicking 
>> on  one radio group causes the marker to disappear from the other 
>> radio  group -- as if part of Wicket were treating the buttons as 
>> though they  all belonged to the same radio group.
>>
>>  I'd like the Wicket 1.3 developers either to fix the bug in a future
>
>> release (after which I'll upgrade my entire application to 1.3), or 
>> tell  me what I'm doing wrong.  How do I get the process started?
>
> the usual way, create a jira issue and attach a quickstart project 
> that demonstrates the problem. than post the jira url back into this
thread.
> it is not very helpful when you post huge fragments of code and markup

> into an email.
>
> -igor
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Bug introduced somewhere after 1.2.2 is still in 1.3.3

[Frank Silbermann]

Here's the URL of my jira issue.  

https://issues.apache.org/jira/browse/WICKET-1601

The issue has attached a quickstart project and a screen print. 

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 08, 2008 12:13 PM
To: users@wicket.apache.org
Subject: Re: Bug introduced somewhere after 1.2.2 is still in 1.3.3

On Thu, May 8, 2008 at 10:06 AM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> I wrote earlier about my problems going from Wicket 1.2.2 to Wicket  
> 1.2.6.  This has to do with a RadioGroup component that I built;  
> whenever I used it on more than one page, clicking on one RadioGroup  
> caused the marker to disapper from all the other RadioGroups on the  
> page.
>
>  I wasn't given much help because Wicket 1.2 is end-of-life.  Today I

> tried the example on Wicked 1.3.3.  I downloaded the QuickStart  
> application for Wicket 1.3.3, installed an upgraded version of my  
> RadioGroup component, modified the home page to show my RadioGroup 
> panel  twice, and the bad behavior is still there.
>
>  By the way, the only change in the generated HTML that I could see 
> was  that in Wicket 1.2.2 the buttons were defined:
>
> 
>  -- with the numbers starting over again for each RadioGroup, whereas 
> in  Wicket 1.2.6 and Wicket 1.3.3 it was more like:
>
> 
>  with the numbers _not_ starting over for each RadioGroup.  Clicking 
> on  one radio group causes the marker to disappear from the other 
> radio  group -- as if part of Wicket were treating the buttons as 
> though they  all belonged to the same radio group.
>
>  I'd like the Wicket 1.3 developers either to fix the bug in a future

> release (after which I'll upgrade my entire application to 1.3), or 
> tell  me what I'm doing wrong.  How do I get the process started?

the usual way, create a jira issue and attach a quickstart project that
demonstrates the problem. than post the jira url back into this thread.
it is not very helpful when you post huge fragments of code and markup
into an email.

-igor


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Bug introduced somewhere after 1.2.2 is still in 1.3.3

[Frank Silbermann]

Well, then, as I am a beginner who hasn't worked much with open source,
could you please point me to a reference that explains what a jira issue
is and how to create one?  (I'm guessing that it's an entry into some
sort of bug tracking database.)

Also, by "attaching a quickstart Project" do you mean simply a zipped
archive of a project directory that was created by installing the
quickstart project and minimally modifying it to create a web
application that exhibits the bug?

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 08, 2008 12:13 PM
To: users@wicket.apache.org
Subject: Re: Bug introduced somewhere after 1.2.2 is still in 1.3.3

On Thu, May 8, 2008 at 10:06 AM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> I wrote earlier about my problems going from Wicket 1.2.2 to Wicket  
> 1.2.6.  This has to do with a RadioGroup component that I built;  
> whenever I used it on more than one page, clicking on one RadioGroup  
> caused the marker to disapper from all the other RadioGroups on the  
> page.
>
>  I wasn't given much help because Wicket 1.2 is end-of-life.  Today I

> tried the example on Wicked 1.3.3.  I downloaded the QuickStart  
> application for Wicket 1.3.3, installed an upgraded version of my  
> RadioGroup component, modified the home page to show my RadioGroup 
> panel  twice, and the bad behavior is still there.
>
>  By the way, the only change in the generated HTML that I could see 
> was  that in Wicket 1.2.2 the buttons were defined:
>
> 
>  -- with the numbers starting over again for each RadioGroup, whereas 
> in  Wicket 1.2.6 and Wicket 1.3.3 it was more like:
>
> 
>  with the numbers _not_ starting over for each RadioGroup.  Clicking 
> on  one radio group causes the marker to disappear from the other 
> radio  group -- as if part of Wicket were treating the buttons as 
> though they  all belonged to the same radio group.
>
>  I'd like the Wicket 1.3 developers either to fix the bug in a future

> release (after which I'll upgrade my entire application to 1.3), or 
> tell  me what I'm doing wrong.  How do I get the process started?

the usual way, create a jira issue and attach a quickstart project that
demonstrates the problem. than post the jira url back into this thread.
it is not very helpful when you post huge fragments of code and markup
into an email.

-igor



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Bug introduced somewhere after 1.2.2 is still in 1.3.3

[Frank Silbermann]

I wrote earlier about my problems going from Wicket 1.2.2 to Wicket
1.2.6.  This has to do with a RadioGroup component that I built;
whenever I used it on more than one page, clicking on one RadioGroup
caused the marker to disapper from all the other RadioGroups on the
page.

I wasn't given much help because Wicket 1.2 is end-of-life.  Today I
tried the example on Wicked 1.3.3.  I downloaded the QuickStart
application for Wicket 1.3.3, installed an upgraded version of my
RadioGroup component, modified the home page to show my RadioGroup panel
twice, and the bad behavior is still there.  

By the way, the only change in the generated HTML that I could see was
that in Wicket 1.2.2 the buttons were defined: 

mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 29, 2008 12:31 PM
To: users@wicket.apache.org
Subject: Re: Change to API between Wicket 1.2 releases?

I dont know what this is, but 1.2 is pretty much end of life, so you
should try to debug what it is and patch your version Or just use a 1.2
version that works for you

On 4/29/08, Frank Silbermann <[EMAIL PROTECTED]> wrote:
> I'm not sure what you mean by "what part it really is"?  Are you 
> asking me to find a simpler example exhibiting the problem?  I mean, 
> the panel class follows the RadioGroup component example quite
closely:
>
> http://wicketstuff.org/wicket13/compref/;jsessionid=C6F7701B6426601795
> 63 
> 84008732211C?wicket:bookmarkablePage=%3Aorg.apache.wicket.examples.com
> pr
> ef.RadioGroupPage
>
> The only significant difference is that instead of using a submit 
> button I override wantOnSelectionChangedNotification() to return true.
>
>  public class MyPanel extends Panel {
>
>  public MyPanel( String id,
>  String caption,
>  PropertyModel groupModel,
>  ChoiceOption[] options ) {
>
>   super(id, groupModel);
>
>   add( new Label("caption", caption) );
>
>   final RadioGroup group = new RadioGroup("group", groupModel)
{
>  //THIS IS THE ONLY PART THAT CHANGED FROM THE
> COMPONENT EXAMPLE
>  protected boolean 
> wantOnSelectionChangedNotifications()
> {
>  return true;
>  }
>  //IT POSTS BACK ON ANY SELECTION
>   };
>   add(group);
>
>   List optionList = Arrays.asList( options );
>
>   ListView radios = new ListView("radios", optionList) {
>protected void populateItem(ListItem listItem) {
>  listItem.add( new Radio("radio",
>new PropertyModel( 
> listItem.getModel(),
>   "value")
>)
>  );
>  listItem.add( new Label("option",
>new PropertyModel( 
> listItem.getModel(), "label" )
> )
>  );
>}
>   };
>
>   group.add(radios);
>  }
>
> Did I do something wrong, or is that feature of RadioGroup indeed 
> broken in current releases of Wicket 1.2?
>
> I really don't know enough about the Wicket internals to debug Wicket.
> Can you suggest anything simpler that I could try to narrow down the 
> location of the problem?  Would it work in Wicket 1.3?
>
>
> -Original Message-
> From: Johan Compagner [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 29, 2008 3:54 AM
> To: users@wicket.apache.org
> Subject: Re: Change to API between Wicket 1.2 releases?
>
> 1.2 is a long time ago
> I have no idea what change did break yours (and what did it fix) If 
> you could figure out what part it really is?
>
> johan
>
>
> On Tue, Apr 29, 2008 at 12:09 AM, Frank Silbermann < 
> [EMAIL PROTECTED]> wrote:
>
> > I completed a Wicket 1.2 project a couple of years ago, and I've 
> > been maintaining it since then. I've been using Version 1.2.2 
> > successfully,
>
> > and figured I might as well use the lastest release of that version 
> > (1.2.7). Well, I'm trying to figure out why Wicket 1.2.7 broke my
> code.
> > (I scrounged up a Wicket 1.2.6 release, and that also breaks it.)
> >
> > Am I using the Wicket 1.2 API incorrectly?  When it works in Wicket 
> > 1.2.2, am I using it in an unintended way?  Let me illustrate what 
> > I've been doing with a small example.
> >
> > This is a simplified version of a co

RE: Difficulty getting QuickStart

[Frank Silbermann]

Warren provided a link
(http://herebebeasties.com/2007-10-07/wicket-quickstart/) to a very
helpful site that demonstrates:

1.  Using Maven2 to download the Wicket Quickstart project,
2.  Downloading the Eclipse plug-in for Maven2,
3.  Configuring Eclipse to find Maven2, and
4.  Running the Quickstart application in Eclipse.

I'm a bit confused as to the relationship between these three.  The
Maven2 documentation says that this plug-in allows maven to be run from
within Eclipse, rather than using the command-line.  But in the demo it
seems to be doing more than that.  In the demo, Eclipse complains about
unknown dependencies in the Quickstart project until a a configuration
variable in Eclipse is set to a Maven2 directory; then Eclipse finds the
Quickstart's dependencies.  What exactly is the relationship between
Maven2 and Eclipse when using this plug-in?  Does it tell Eclipse to
forgo its normal project description format and instead rely on Maven2
to describe the project and replace Eclipse' native build commands?
 
When the demonstrator downloads the Eclipse plug-in for Maven2 (or is it
rather a Maven2 plug-in for Eclipse?), Maven downloads a bunch of stuff
including a Wicket jar.  That surprised me.  Why would it assume that a
user of Maven2 with Eclipse would need Wicket?  Is Maven2 actually smart
enough to look in the Quickstart project to see what Eclipse needs to
run it?  What if I had installed Maven2 and the Eclipse plug-in _before_
downloading the Quickstart project to begin developing in Wicket?
 
Please for give my naivite, but Eclipse, Maven2 and the Wicket
Quickstart project are all new to me, and I'm getting as to what exactly
is the flow of information between these components as we set up the
environment.
 
/Frank
 

-Original Message-
From: Warren [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 01, 2008 3:58 PM
To: users@wicket.apache.org
Subject: RE: Difficulty getting QuickStart

I was having some problems until I went to this site:

http://herebebeasties.com/2007-10-07/wicket-quickstart/

There is a screencast there that will show you everything. It was real
helpful.

> -Original Message-
> From: Frank Silbermann [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 01, 2008 1:52 PM
> To: users@wicket.apache.org
> Subject: Difficulty getting QuickStart
>
>
> I wrote in earlier about a problem I had in less-old releases of
> Wicket 1.2.  Since no more work is being done on that version, I
> thought I'd try the sample on Wicket 1.2.  I figured the easiest
> approach was to download the Wicket 1.3 QuickStart application.  That
> requires Maven, which I've never before used.  I downloaded and
> installed Maven (I assume correctly) and then followed the
> instructions to get the QuckStart application, but the Maven command
> failed with the following output.  Can anyone tell me what I did
> wrong?  (I apologize if this is really a Maven question, but obtaining
> QuickStart is my only reason for messing with Maven.)
>
>  C:\>mvn archetype:create -DarchetypeGroupId=org.apache.wicket
> -DarchetypeArtifactId=wicket-archetype-quickstart
> -DarchetypeVersion=1.3.3 -DgroupId=com.mycompany
> -DartifactId=myproject [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'archetype'.
> [INFO] org.apache.maven.plugins: checking for updates from central
> [WARNING] repository metadata for: 'org.apache.maven.plugins' could
> not be retrieved from repository: central due to an error: Error
> transferring file [INFO] Repository 'central' will be blacklisted
> [INFO]
> --
> --
> [ERROR] BUILD ERROR
> [INFO]
> --
> -- [INFO] The plugin 'org.apache.maven.plugins:maven-archetype-plugin'
> does not exist or no valid version could be found [INFO]
> --
> -- [INFO] For more information, run Maven with the -e switch [INFO]
> --
> --
> [INFO] Total time: 21 seconds
> [INFO] Finished at: Thu May 01 15:42:12 CDT 2008 [INFO] Final Memory:
> 1M/2M [INFO]
> --
> --
>
>
>
> /Frank
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Pros and cons of WicketBench

[Frank Silbermann]

 
When I was developing in Wicket 1.2 I used Jbuilder 2006; it was what
the employer provided.  Other developers, however, use Eclipse for their
(non-Wicket) projects, and Jbuilder 2007/8 are Eclipse-based, so I
figured might might as well start my Wicket 1.3 experiments using
Eclipse.

What are the pros and (if any) cons of using the Wicket Bench plug-in?
Is it worth setting up if all I'm really going to be doing is (perhaps)
to upgrade a Wicket 1.2 application to Wicket 1.3?  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Advisory question

[Frank Silbermann]

So when do we get the Addison-Wesley book on _Wicket_Patterns_?  :-) 

-Original Message-
From: Maurice Marrink [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 02, 2008 5:51 AM
To: users@wicket.apache.org
Subject: Re: Advisory question

The nice thing about wicket is that it will give you freedom to choose
whatever you like.
You can create individual pages but if you markup is mostly the same it
is easy to to use markup inheritance from a single basepage.
You can also have just one page and replace panels as required.
It is all a matter of personal preference / application needs.
>From what you are describing you might want to take a look at
http://cwiki.apache.org/WICKET/markup-inheritance.html

Maurice

On Fri, May 2, 2008 at 12:36 PM, Martijn Lindhout
<[EMAIL PROTECTED]> wrote:
> Hi,
>
>  My web app background is from page oriented frameworks, and now while

> using wicket, I find myself creating pages over and over.
>  I think I can miss many of them, because most of the time all I do is

> adding an intelligent reusable component to it.
>
>  How do you guys handle this? Are you creating some basepage that is  
> suitable to contain more than one functional part of your application?
>  Or just create page by page?
>
>  --
>  Martijn Lindhout
>  JointEffort IT Services
>  http://www.jointeffort.nl
>  [EMAIL PROTECTED]
>  +31 (0)6 18 47 25 29
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Difficulty getting QuickStart

[Frank Silbermann]

Of course I am.  Who isn't, these days?  /Frank 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of James Carman
Sent: Thursday, May 01, 2008 4:16 PM
To: users@wicket.apache.org
Subject: Re: Difficulty getting QuickStart

Are you behind a firewall of some sort?  Or, perhaps an HTTP proxy
server?

On Thu, May 1, 2008 at 4:51 PM, Frank Silbermann
<[EMAIL PROTECTED]> wrote:
> I wrote in earlier about a problem I had in less-old releases of 
> Wicket  1.2.  Since no more work is being done on that version, I 
> thought I'd  try the sample on Wicket 1.2.  I figured the easiest 
> approach was to  download the Wicket 1.3 QuickStart application.  That

> requires Maven,  which I've never before used.  I downloaded and 
> installed Maven (I  assume correctly) and then followed the 
> instructions to get the  QuckStart application, but the Maven command 
> failed with the following  output.  Can anyone tell me what I did 
> wrong?  (I apologize if this is  really a Maven question, but 
> obtaining QuickStart is my only reason for  messing with Maven.)
>
>   C:\>mvn archetype:create -DarchetypeGroupId=org.apache.wicket
>  -DarchetypeArtifactId=wicket-archetype-quickstart
>  -DarchetypeVersion=1.3.3 -DgroupId=com.mycompany 
> -DartifactId=myproject  [INFO] Scanning for projects...
>  [INFO] Searching repository for plugin with prefix: 'archetype'.
>  [INFO] org.apache.maven.plugins: checking for updates from central  
> [WARNING] repository metadata for: 'org.apache.maven.plugins' could 
> not  be retrieved from repository: central due to an error: Error  
> transferring file  [INFO] Repository 'central' will be blacklisted  
> [INFO]
>  
> --
> --
>  [ERROR] BUILD ERROR
>  [INFO]
>  
> --
> --  [INFO] The plugin 
> 'org.apache.maven.plugins:maven-archetype-plugin' does  not exist or 
> no valid version could be found  [INFO]
>  
> --
> --  [INFO] For more information, run Maven with the -e switch  [INFO]
>  
> --
> --
>  [INFO] Total time: 21 seconds
>  [INFO] Finished at: Thu May 01 15:42:12 CDT 2008  [INFO] Final 
> Memory: 1M/2M  [INFO]
>  
> --
> --
>
>
>
>  /Frank
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Difficulty getting QuickStart

[Frank Silbermann]

I wrote in earlier about a problem I had in less-old releases of Wicket
1.2.  Since no more work is being done on that version, I thought I'd
try the sample on Wicket 1.2.  I figured the easiest approach was to
download the Wicket 1.3 QuickStart application.  That requires Maven,
which I've never before used.  I downloaded and installed Maven (I
assume correctly) and then followed the instructions to get the
QuckStart application, but the Maven command failed with the following
output.  Can anyone tell me what I did wrong?  (I apologize if this is
really a Maven question, but obtaining QuickStart is my only reason for
messing with Maven.)

 C:\>mvn archetype:create -DarchetypeGroupId=org.apache.wicket
-DarchetypeArtifactId=wicket-archetype-quickstart
-DarchetypeVersion=1.3.3 -DgroupId=com.mycompany -DartifactId=myproject
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO] org.apache.maven.plugins: checking for updates from central
[WARNING] repository metadata for: 'org.apache.maven.plugins' could not
be retrieved from repository: central due to an error: Error
transferring file
[INFO] Repository 'central' will be blacklisted
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] The plugin 'org.apache.maven.plugins:maven-archetype-plugin' does
not exist or no valid version could be found
[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]

[INFO] Total time: 21 seconds
[INFO] Finished at: Thu May 01 15:42:12 CDT 2008
[INFO] Final Memory: 1M/2M
[INFO]


 

/Frank

RE: Change to API between Wicket 1.2 releases?

[Frank Silbermann]

I'm not sure what you mean by "what part it really is"?  Are you asking
me to find a simpler example exhibiting the problem?  I mean, the panel
class follows the RadioGroup component example quite closely:

http://wicketstuff.org/wicket13/compref/;jsessionid=C6F7701B642660179563
84008732211C?wicket:bookmarkablePage=%3Aorg.apache.wicket.examples.compr
ef.RadioGroupPage

The only significant difference is that instead of using a submit button
I override wantOnSelectionChangedNotification() to return true.

 public class MyPanel extends Panel {

 public MyPanel( String id,
 String caption,
 PropertyModel groupModel, 
 ChoiceOption[] options ) {

  super(id, groupModel);

  add( new Label("caption", caption) );

  final RadioGroup group = new RadioGroup("group", groupModel) {
 //THIS IS THE ONLY PART THAT CHANGED FROM THE
COMPONENT EXAMPLE
 protected boolean wantOnSelectionChangedNotifications()
{ 
 return true;
 }
 //IT POSTS BACK ON ANY SELECTION
  };
  add(group);

  List optionList = Arrays.asList( options );

  ListView radios = new ListView("radios", optionList) {
   protected void populateItem(ListItem listItem) {
 listItem.add( new Radio("radio",
   new PropertyModel(
listItem.getModel(),
  "value")
   ) 
 );
 listItem.add( new Label("option",
   new PropertyModel(
listItem.getModel(), "label" )
)
 );
   }
  };

  group.add(radios);
 }

Did I do something wrong, or is that feature of RadioGroup indeed broken
in current releases of Wicket 1.2?

I really don't know enough about the Wicket internals to debug Wicket.
Can you suggest anything simpler that I could try to narrow down the
location of the problem?  Would it work in Wicket 1.3?  


-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 29, 2008 3:54 AM
To: users@wicket.apache.org
Subject: Re: Change to API between Wicket 1.2 releases?

1.2 is a long time ago
I have no idea what change did break yours (and what did it fix) If you
could figure out what part it really is?

johan


On Tue, Apr 29, 2008 at 12:09 AM, Frank Silbermann <
[EMAIL PROTECTED]> wrote:

> I completed a Wicket 1.2 project a couple of years ago, and I've been 
> maintaining it since then. I've been using Version 1.2.2 successfully,

> and figured I might as well use the lastest release of that version 
> (1.2.7). Well, I'm trying to figure out why Wicket 1.2.7 broke my
code.
> (I scrounged up a Wicket 1.2.6 release, and that also breaks it.)
>
> Am I using the Wicket 1.2 API incorrectly?  When it works in Wicket 
> 1.2.2, am I using it in an unintended way?  Let me illustrate what 
> I've been doing with a small example.
>
> This is a simplified version of a component for creating and 
> displaying radio button groups without having to write HTML every 
> time.  I give the
> constructor:
>
> (1) a wicket-id,
>
> (2) a PropertyModel that initializes the component and keeps track of 
> the current choice, and
>
> (3) an array of ChoiceOption.  -- The array of choice options defines 
> the set of values offered by the radio buttons, and the corresponding 
> labels to be displayed.
>
> The component posts back immediately when a change is made to the 
> radio button.  (Think fast INTRAnet with a very small number of 
> simulaneous
> users.)  Here is my implementation:
>
> package common.play;
>
> import wicket.markup.html.basic.Label; import wicket.model.IModel; 
> import wicket.markup.html.panel.Panel; import 
> wicket.markup.html.form.Radio; import 
> wicket.markup.html.form.RadioGroup;
> import wicket.markup.html.list.ListItem; import 
> wicket.markup.html.list.ListView; import wicket.model.PropertyModel; 
> import java.util.List; import java.util.Arrays; import 
> common.play.ChoiceOption;
>
> public class MyPanel extends Panel {
>
>  public MyPanel( String id, String caption, PropertyModel groupModel, 
> ChoiceOption[] options) {
>super(id, groupModel);
>
>add( new Label("caption", caption) );
>final RadioGroup group = new RadioGroup("group", groupModel) {
>  protected boolean wantOnSelectionChangedNotifications() { return
true; }
>};
>add(group);
&

Change to API between Wicket 1.2 releases?

[Frank Silbermann]

I completed a Wicket 1.2 project a couple of years ago, and I've been
maintaining it since then. I've been using Version 1.2.2 successfully,
and figured I might as well use the lastest release of that version
(1.2.7). Well, I'm trying to figure out why Wicket 1.2.7 broke my code.
(I scrounged up a Wicket 1.2.6 release, and that also breaks it.)

Am I using the Wicket 1.2 API incorrectly?  When it works in Wicket
1.2.2, am I using it in an unintended way?  Let me illustrate what I've
been doing with a small example.

This is a simplified version of a component for creating and displaying
radio button groups without having to write HTML every time.  I give the
constructor:

(1) a wicket-id, 

(2) a PropertyModel that initializes the component and keeps track of
the current choice, and 

(3) an array of ChoiceOption.  -- The array of choice options defines
the set of values offered by the radio buttons, and the corresponding
labels to be displayed.

The component posts back immediately when a change is made to the radio
button.  (Think fast INTRAnet with a very small number of simulaneous
users.)  Here is my implementation:

package common.play;

import wicket.markup.html.basic.Label;
import wicket.model.IModel;
import wicket.markup.html.panel.Panel;
import wicket.markup.html.form.Radio;
import wicket.markup.html.form.RadioGroup;
import wicket.markup.html.list.ListItem;
import wicket.markup.html.list.ListView;
import wicket.model.PropertyModel;
import java.util.List;
import java.util.Arrays;
import common.play.ChoiceOption;

public class MyPanel extends Panel {

  public MyPanel( String id, String caption, PropertyModel groupModel,
ChoiceOption[] options) {
super(id, groupModel);

add( new Label("caption", caption) );
final RadioGroup group = new RadioGroup("group", groupModel) {
  protected boolean wantOnSelectionChangedNotifications() { return
true; }
};
add(group);

List optionList = Arrays.asList( options );
ListView radios = new ListView("radios", optionList) {
  protected void populateItem(ListItem listItem) {
listItem.add( new Radio("radio",
new PropertyModel( listItem.getModel(),
"value") ) );
listItem.add( new Label("option", new PropertyModel(
listItem.getModel(), "label" )));
  }
};

group.add(radios);
  }



package common.play;

public class ChoiceOption implements java.io.Serializable {
  public String value;
  public String label;

  public ChoiceOption(String value, String label) {
this.value = value;
this.label = label;
  }
}




This is the layout for displaying my component.  It's a divided box that
puts the group caption in one half, and in the other half provides the
set of labeled buttons.  Note that I'm using a ListView, because each
usage may require a different number of choices.

http://www.w3.org/1999/xhtml 
" xmlns:wicket="http://wicket.sourceforge.net/
 " xml:lang="en" lang="en">





  

  
Caption
  
  

  

  

option name
 
  

  

  

  





Here is a page with two intances of this component; one set of radio
buttons below the other, within a form.  Below my form are two labels,
one below the other, which indicate the value currently chosen by the
corresponding radio-button set. 

import wicket.markup.html.WebPage;
import wicket.markup.html.panel.Panel;
import wicket.markup.html.form.Form;
import wicket.model.PropertyModel;
import wicket.markup.html.basic.Label;
import common.play.ChoiceOption;

public class MyPage extends WebPage {

  public String firstProperty = "A";
  public String secondProperty = "A";

  ChoiceOption[] options = {   new ChoiceOption("A", "Ay"),
   new ChoiceOption("B", "Bee"),
   new ChoiceOption("C", "See"),
   new ChoiceOption("D", "Dee") };

  public MyPage() {

  Form form = new Form("form");
  add( form );

  Panel panel1 = new MyPanel( "panel1",
  "1st choice",
  new PropertyModel( this,
"firstProperty"),
  options
);
  form.add( panel1 );


  Panel panel2 = new MyPanel( "panel2",
  "2nd choice",
  new PropertyModel( this,
"secondProperty"),
  options
);
  form.add( panel2 );

  add( new Label( "result1",
  new PropertyModel(this, "firstProperty")
)
 );

  a