RE: Help with Wicket Adoption Numbers

2010-01-12 Thread Loritsch, Berin C.
It's a reference to the American cartoon Dilbert (www.dilbert.com)
that is syndicated in papers.  It has a nice sarcastic look at office
life.

-Original Message-
From: Eyal Golan [mailto:egola...@gmail.com] 
Sent: Monday, January 11, 2010 2:58 AM
To: users@wicket.apache.org
Subject: Re: Help with Wicket Adoption Numbers

As my English is not my mother's tongue, even though I do speak it
pretty
good, what is the meaning of pointy haired bosses?
I think I can understand it, but hey, I want to know if these are the
kinds
of bosses I encountered too often..

Eyal Golan
egola...@gmail.com

Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74

P  Save a tree. Please don't print this e-mail unless it's really
necessary


On Fri, Jan 8, 2010 at 11:26 PM, Jonathan Locke
jonathan.lo...@gmail.comwrote:



 honestly, your response is too thoughtful. these pointy haired bosses
are
 self-serving. they don't care about training costs or developer pain
and
 they don't really care if their org runs efficiently.  what they care
about
 is that if there is a failure, their choice didn't cause it.  which is
why
 the old saying goes nobody ever got fired for buying IBM.  same
seems to
 go for struts.  an idiotic technology choice, but you won't get fired
for
 making the same idiotic choice everyone else is making.


 Loritsch, Berin C. wrote:
 
  But why choose an inferior technology just because of its adoption
  numbers?
 
  The pointy haired bosses that do this believe in their heart of
hearts
  that if you choose the same technology everyone else is using that
they
  can turn thinking developers for mindless drones.  It has more to do
  with avoiding training costs and rational thought, and more to do
with
  trying to turn software development into an assembly line process.
  Reality never fits this mold, but it doesn't stop the pointy haired
boss
  from trying.  In this respect they are eternal optimists.
 
  -Original Message-
  From: leo.erlands...@tyringe.com [mailto:leo.erlands...@tyringe.com]
  Sent: Friday, January 08, 2010 4:09 AM
  To: users@wicket.apache.org
  Subject: Re: Help with Wicket Adoption Numbers
 
  Hi,
 
  We also had the same consideration when we chose Wicket. But why
choose
  an
  inferior technology just because of it's Adoption Numbers? Also,
Wicket
  is
  becoming more and more popular as people see the light :)
 
  Check out Jobs Trends (Relative Growth) here (JSF vs Struts vs
Wicket):
 
http://www.indeed.com/jobtrends?q=Struts%2C+JSF%2C+Wicketl=relative=1
 
  We have a couple of hundred customers and so far the feedback is
great
  both from our Developers and our Software Architects. Customers like
  that
  the GUIs are faster due to the simplicity of Ajax Adoption in
Wicket.
 
  I also know that several large privately held companies in Sweden
are
  using Wicket, as well as large Government Agencies (e.g. the Swedish
  Immigration Office).
 
 
  Sincerely yours
  Leo Erlandsson
 
 
 
-
  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/Help-with-Wicket-Adoption-Numbers-tp27069702p27082
559.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: DiskPageStore file increasing to max size by only refreshing a HomePage

2010-01-08 Thread Loritsch, Berin C.
It's bookmarked pages that avoid new page creation isn't it?

-Original Message-
From: Matej Knopp [mailto:matej.kn...@gmail.com] 
Sent: Thursday, January 07, 2010 3:55 PM
To: users@wicket.apache.org
Subject: Re: DiskPageStore file increasing to max size by only
refreshing a HomePage

SetVersioned(false) does not help with new page instances being created.

-Matej

On Thu, Jan 7, 2010 at 9:46 PM, Wilhelmsen Tor Iver toriv...@arrive.no
wrote:
 about unversioned, i have just done a quick test on wicket-examples

 helloworld, adding serialVersionUID (not informed in the examples)
and
 the
 result is the same: pagestore file increasing to the infinite (max
 size of
 course :)

 I meant Wicket's

 setVersioned(false);

 the serialVersionUID is just for binary serialization, as long as the
fields do not change the computed value the VM generates for you should
be the same.

 -
 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: Wicket session not threadsafe?

2010-01-08 Thread Loritsch, Berin C.
The session object is bound to the HttpSession, so it is as safe as Tomcat or 
whatever servlet container is running your application.

Here are some things to consider that have bit me in the butt, and have nothing 
to do with your local setup:

* Is that happening locally in your test environment?
* Does your client have caching proxies?  (do they even know?)
* Do your response headers have the no-cache entries?

What might be happening is the first person to log in through the caching proxy 
gets their information cached by the proxy.  The second person comes in and 
sees it.  Typically the problem has to do with poorly configured proxy servers 
and they don't properly distinguish the pages with the cache control headers 
you supply.  The only way around it is to turn off client caching completely.

-Original Message-
From: Soumya [mailto:soumya_...@yahoo.co.in] 
Sent: Friday, January 08, 2010 6:18 AM
To: users@wicket.apache.org
Subject: Wicket session not threadsafe?

Hi all,
I am fairly a newbie in wicket and would appreciate your help!

I
have a wicket application which are used on Live by more than 500
users. Now the problem which has arisen is - say User A logs on - he is
able to view details of User B. It has happened for different users and
I am trying to dig the real reason.

Here is my code details -
1) I use Hibernate to fetch 'Account' objects from backend passing on the 
username/password.

2) I use 
MyAppSession extends WebSession
{
private Account account;
    
    public InboundSession(Request request) 
    {
    super(request);
    }

    public void setAccount(Account account)
    {
        this.account = account;
    }
   
 
    public Account getAccount()
    {
        return account;
    }

public boolean isUserLoggedIn()
    {
return account !=null;
}
    
}

So
effectively I check if the Account object in session is null or not and
accordingly decide whether a user is logged in or not.

2) In Login class I pass on the username/password to HibernateAccountDao and 
fetch the Account object.
Account account = accountDao.getAccount(username, password)
MyAppSession session = (MyAppSession )getSession();
session.setAccount(account);
setResponsePage(Home.class);

So effectively I fetch the accout object using hibernate and store it in wicket 
session.
But I am not sure how these account objects are getting mixed up between users.

Please can someone lead me to the route cause of the issue?
 

Thanks in advance!
SSP


  The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. 
http://in.yahoo.com/

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



RE: Wicket session not threadsafe?

2010-01-08 Thread Loritsch, Berin C.
Essentially your response headers should have the following headers:

Cache-Control: no-cache, no-store
Pragma: no-cache


For more details on HTTP response headers and cache controls see this
page:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Not all proxy servers are documented, unfortunately.  If your system
lives in a DMZ (which it sounds like it might), then the proxy server
might be within your ISP.

-Original Message-
From: allgo [mailto:soumya_...@yahoo.co.in] 
Sent: Friday, January 08, 2010 8:44 AM
To: users@wicket.apache.org
Subject: RE: Wicket session not threadsafe?


Hi Berin,

No the users are all from different companies and no way there woudl be
caching of their side. User A belongs to a client X say working in New
York
, while User B may be of client Y working in texas.

It doesnt happen in test environment. but then that is not a multi-user
environment in true sense of teh word. As hardly 3-4 people test it and
we
never got into that situation. For live however there are 500+ users
using
it everyday.

no-cache entry? I am bit sketchy on this one. Can you give an example?

Thanks for ur help.





Loritsch, Berin C. wrote:
 
 The session object is bound to the HttpSession, so it is as safe as
Tomcat
 or whatever servlet container is running your application.
 
 Here are some things to consider that have bit me in the butt, and
have
 nothing to do with your local setup:
 
 * Is that happening locally in your test environment?
 * Does your client have caching proxies?  (do they even know?)
 * Do your response headers have the no-cache entries?
 
 What might be happening is the first person to log in through the
caching
 proxy gets their information cached by the proxy.  The second person
comes
 in and sees it.  Typically the problem has to do with poorly
configured
 proxy servers and they don't properly distinguish the pages with the
cache
 control headers you supply.  The only way around it is to turn off
client
 caching completely.
 
 -Original Message-
 From: Soumya [mailto:soumya_...@yahoo.co.in] 
 Sent: Friday, January 08, 2010 6:18 AM
 To: users@wicket.apache.org
 Subject: Wicket session not threadsafe?
 
 Hi all,
 I am fairly a newbie in wicket and would appreciate your help!
 
 I
 have a wicket application which are used on Live by more than 500
 users. Now the problem which has arisen is - say User A logs on - he
is
 able to view details of User B. It has happened for different users
and
 I am trying to dig the real reason.
 
 Here is my code details -
 1) I use Hibernate to fetch 'Account' objects from backend passing on
the
 username/password.
 
 2) I use 
 MyAppSession extends WebSession
 {
 private Account account;
 
 public InboundSession(Request request) 
 {
 super(request);
 }
 
 public void setAccount(Account account)
 {
 this.account = account;
 }

  
 public Account getAccount()
 {
 return account;
 }
 
 public boolean isUserLoggedIn()
 {
 return account !=null;
 }
 
 }
 
 So
 effectively I check if the Account object in session is null or not
and
 accordingly decide whether a user is logged in or not.
 
 2) In Login class I pass on the username/password to
HibernateAccountDao
 and fetch the Account object.
 Account account = accountDao.getAccount(username, password)
 MyAppSession session = (MyAppSession )getSession();
 session.setAccount(account);
 setResponsePage(Home.class);
 
 So effectively I fetch the accout object using hibernate and store it
in
 wicket session.
 But I am not sure how these account objects are getting mixed up
between
 users.
 
 Please can someone lead me to the route cause of the issue?
  
 
 Thanks in advance!
 SSP
 
 
   The INTERNET now has a personality. YOURS! See your Yahoo!
Homepage.
 http://in.yahoo.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/Wicket-session-not-threadsafe--tp27074491p27076126
.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



Google analytics on home page slowing down access

2010-01-08 Thread Loritsch, Berin C.
Just an FYI, the call to google-analytics on the Wicket home page is
causing the site to crawl as I have to wait for the connection to time
out before I see anything (at least 30s).

That is because the call is in the header, and it should be placed at
the bottom of the body section to avoid this problem.  Most browsers
will be able to display the page as it is loading resources in the order
they are declared.  For things like google analytics and populating ads,
it's best to incorporate those javascript goodies after the page is
rendered.

Example:

Move the following snippet:

html
head
!-- ... --
  SCRIPT type=text/javascript
_uacct = UA-2350632-1;
urchinTracker();
/SCRIPT
!-- ... --
/head
/html

To the following location:

html
body
!-- ... --
  SCRIPT type=text/javascript
_uacct = UA-2350632-1;
urchinTracker();
/SCRIPT
/body
/html



RE: Modal Popups and Forms

2009-12-29 Thread Loritsch, Berin C.
AJAX and forms highlight some issues with HTML forms in general.  Unless
you have declared a brand new form for your modal popup, and are
absolutely sure that you are submitting that new form, you will be
submitting the original form that was on the base page.  Keep in mind
that to the browser, the modal popup is part of the same DOM as the
information beneath what the user sees--unless you actually created a
new window.

Browsers do not do well with forms embedded in forms, and they cause all
kinds of issues.  Make sure that YUI did not manufacture a DIV inside
the original form.  If it did, then your browser is defaulting to
sending the outermost form.  Use Firebug to inspect the DOM.

-Original Message-
From: Corbin, James [mailto:jcor...@iqnavigator.com] 
Sent: Tuesday, December 29, 2009 1:43 PM
To: users@wicket.apache.org
Subject: Modal Popups and Forms

Hi,

 

I have a modal popup (implemented using YUI 2.8).  The modal popup
contains a form and the popup's markup is rendered (via YUI js)
explicitly to document.body.

 

The reasoning for rendering the YUI javascript to document.body is to
address some issue we had with css inheritance that was causing
rendering issues (conflicts with default YUI skinning) when we render
the markup inline.

 

If I change the YUI popup javascript to render inline, the issue doesn't
happen, but I don't want to render the markup for the popup inline,
because it potentially inherits styling that interferes with the YUI
styling for the popup.  Rendering the markup to document.body solves
that issue.

 

So what I know so far that I cannot change, or don't want to change, is
that the YUI popup implementation needs to render its markup to
document.body.  

 

I verified that the markup generated for the popup's form is indeed a
div element (outside of the form tags as I would have expected)  In this
case, there is only one form tag (parent form where popup is initiated
from) on the page and it is indeed has its encoding set to multi-part
(verified in the generated markup).

 

Note the markup for the popup dialog does not have any elements that
should require multi-part encoding, but the parent form from which the
popup was initiated, does.

 

How come when I submit the dialog, I get the following exception?  I
guess I'm not sure what is going on and how Wicket is handling this
case.

 

java.lang.IllegalStateException: ServletRequest does not contain
multipart content
at
org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init
(MultipartServletWebRequest.java:113)
at
org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init
(MultipartServletWebRequest.java:83)
at
org.apache.wicket.protocol.http.servlet.ServletWebRequest.newMultipartWe
bRequest(ServletWebRequest.java:500)
at
org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1651)
at
org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:850)
at
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmi
tBehavior.java:135)

 

 

 

Ideas?

 

 

 

 

 

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: Tag Oriented Development

2009-12-29 Thread Loritsch, Berin C.
The good thing about standards is that there are so many to choose from.

.Net is a standard, Java is a standard, PERL is a standard, JavaScript is a 
standard.  As are CSS, HTML, etc.

As we all know, just because something is a standard does not mean that it is 
good, fits the problem, or is implemented properly or in any meaningful way.  
It is important to understand the thinking that goes into one of the standards.

In business, the reason decision makers choose standards is because they want 
easily replaceable cogs that require little training.  They've been trying to 
get software engineers to pay obeisance to this thinking for years, but the 
engineers can always come up with good reasons why a standard is not a good 
fit.  The exceptional engineers can do it in a way that even the decision 
makers see the value in dropping a standard.

-Original Message-
From: Altuğ B. Altıntaş [mailto:alt...@gmail.com] 
Sent: Tuesday, December 29, 2009 2:51 PM
To: users@wicket.apache.org
Subject: Re: Tag Oriented Development

Agreed

2009/12/25 b...@actrix.gen.nz

 JSF == Standard?

 My question is: What should become a standard?

 When I think about standards, then things that come to mind are:

 - SQL
 - ODBC
 - Java
 - JDBC
 - EJB
 - JPA

 but not JSF. And not Spring. And not ... - you name it.

 For some reason, possibly due to the fast evolving nature of the web,
 web frameworks are higher up in the food chain, and I don't think that
 we are ready yet to standardize on that level. People may say JSF is a
 standard, so what? The fact that there are so many others seems to
 prove my point.

 Bernard



 On Tue, 22 Dec 2009 14:59:16 +0200, you wrote:

 In business, decision makers choose standards and JSF is standard so JSF
 is
 good and JSF is the King. But couldn't be The King Is Naked ??
 
 OR
 
 Am i wrong ? JSF is really cool and i don't know the hidden features ??
 
 I don't want to start framework wars, this is useless but I think Wicket
 should be a JSR.
 
 I don't know how a framework like Wicket become a JSR - a standard - but
 it
 should be...
 
 
 2009/12/22 Peter Thomas ptrtho...@gmail.com
 
  On Tue, Dec 22, 2009 at 5:47 PM, Ernesto Reinaldo Barreiro 
  reier...@gmail.com wrote:
 
   @Tomas, @Martin,
  
   I already knew those links... Thanks anyway. Actually I went a bit
  further
   an implemented the same application on different technologies so
 that
   developers could evaluate for themselves the wonders of downsides of
  each
   technology... plus detailed explanations of how the code works
   Unfortunately I cannot share that code as is property of the company I
  work
   for
 
 
  That's a pretty solid approach, pity you can't share the code though.  I
  tried to do something similar as open-source:
  http://code.google.com/p/perfbench/
 
  Maybe you can contribute some analysis or even an implementation or two
 ;)
  I would be interested in your feedback, for e.g. which framework to
 attempt
  next - do let me know offline.
 
 
 
   But the problem is those who will take the final decision will take
   into account more political reasons that things like development
  speed,
   code quality, code re-usability and any other adds you throw at
  them...
  
  
   @Martin,
  
   Congratulations!  Hope I can say the same in  a few months.
  
   Best,
  
   Ernesto
  
   On Tue, Dec 22, 2009 at 12:57 PM, Peter Thomas ptrtho...@gmail.com
   wrote:
  
On Tue, Dec 22, 2009 at 5:22 PM, Ernesto Reinaldo Barreiro 
reier...@gmail.com wrote:
   
 Hi Eelco,

 On Tue, Dec 22, 2009 at 12:38 PM, Eelco Hillenius 
 eelco.hillen...@gmail.com
  wrote:

   I love Wicket and the natural approach it offers to do
 web-development...
   and I have been pushing hard to use it whenever possible...
  but
  on
the
   real world it is not enough to be an excellent product to
 gain
   wide acceptance...  Does last sentence ring a bell?
 
  I think we've gained pretty wide acceptance actually. Wicket In
   Action
  has been a best seller for Manning in the months right after it
  came
  out, and Wicket is by many considered as one of the leading web
  frameworks for Java. We've also had one of the most active email
   lists
  for years now. I'm sure Wicket lags behind JSF and Struts
   considerably
  when it comes to number of users, but hey, why would we care.
 You
   only
  need a bunch of serious users to maintain a framework, and
 Wicket
  has
  many thousands of them :-)
 
  You don't have to convince me about Wicket excellence! I love
  Wicket,
 I've
 been using it for over two years now, and right now I'm doing all
 my
 efforts
 to get it adopted at the company I'm working for... But being
  realistic
 they
 will probably jump to Struts 2, or Seam-JSF...

 After re-reading my message  I see maybe it was bit
 pessimistic..
   maybe
 out of my present frustration.
   

RE: onSubmit() not entered (IE6 and IE7)

2009-12-16 Thread Loritsch, Berin C.
From a strict HTML perspective, the less you have in your form the
better the page performs.  From a few observations in debugging AJAX
functionality that doesn't work on past projects (not Wicket related),
you have to make sure that no Javascript exceptions are thrown at all.
Basically, IE will turn off its Javascript interpreter completely as
soon as the interpreter catches an exception.  If you don't catch it and
handle it in the page properly, no further Javascript will work until
the page is reloaded.

One example is from a tool that used to be available to enable multiple
versions of IE on your Windows machine.  It was a registry hack that
gave you the rendering engine for older versions of IE on your machine
(they are all there).  One of the side effects of using any rendering
engine that was not the current one (IE 7 at the time I ran into the
problem) was that you could not invoke the window.print() function.  If
that happened, the rendering engine threw an exception and killed all
future Javascript functions.  So the popup window we had with a print
and close button would not work properly if the user hit the print
button first.  The print button used window.print() and the close
button used window.close(), so the Javascript was fairly simple.  As
soon as the exception was thrown, the close button ceased to work.  The
multiple IE hack was the cause here, but we saw it on some of our more
complex forms as well.

When Javascript stops working on IE, no further Javascript calls will
work.  Just to make sure you haven't run into this problem, add a simple
little button or link that has the javascript action alert('still
works') to your page.  Once you get to the place where the page
reproducibly does not work, click on that button.  If the little alert
dialog box does not open up, then IE's Javascript engine has completely
crapped out.  My guess is that this is what you are running into,
without actually seeing anything.

-Original Message-
From: Martin Dietze [mailto:d...@fh-wedel.de] 
Sent: Wednesday, December 16, 2009 8:42 AM
To: users@wicket.apache.org
Subject: onSubmit() not entered (IE6 and IE7)

I have repeatedly run into situations like this one:

On very complex pages with lots of Ajax-stuff I sometimes get to
a point where (reproducably) my form's onSubmit() method is
never entered when submitting the form with a simple submit
button. This problem occurs in IE6 and IE7. 

Usually as a workaround I ended up with one of these solutions
(putting the one I like better first):

 (1) attaching the 'onSubmit()' method to the button rather than
 the form

 (2) making the button an AjaxButton with default form submit
 behaviour set to 'true'

The first from these solutions does not work in some solutions,
so that I have to switch to the second one.

In a particular case I had today the submit button which did not
work with IE6 and IE7 was supposed to perform an upload. Due to
some issues still not resolved in wicket 1.4.3 I am currently
unable to use Ajax for uploads in my project. So I ended up with
a third workaround:

 (3) moved the upload stuff to a separate form on the page

Solution (3) now works, but it is not nice, since due to the
page's layout there's no way to place the upload somewhere where
it looks nice.

Unfortunately there's no reliable way to produce this kind of
problem, at some place you'll 'just have it'. And since it
happens in complex pages it is not really possible for me to
provide example code here (commercial project, you know the
story).

Now first of all I would like to hear some comments - anyone
else experienced similar problems? 
Also, as we may (almost) all agree that IE6 (and probably later
versions as well) is brain damaged software that should be
forbidden, it is still in use and needs to be suported. Thus:
is there any chance we can track down problems like this and
fix them within wicket?

Cheers,

M'bert

-- 
--- / http://herbert.the-little-red-haired-girl.org /
-
=+= 
Immer Schwierigkeiten immer gerade so zu schaffen, und so macht man sich
auf
Dauer halt zum Schwierigkeitenaffen, trifft befreundete Primaten in den
Kneipen
und im Garten, wartend auf die grosse Sause oder einfach nur oder besser
noch,
die grosse Pause.  -- Die Sterne

-
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: onSubmit() not entered (IE6 and IE7)

2009-12-16 Thread Loritsch, Berin C.
Check out TotalValidator, a plugin and local JAR file that can be run on 
internal pages to ensure your markup is correct.  If the markup is bad, then 
you will get unexpected behaviors.

-Original Message-
From: Martin Dietze [mailto:d...@fh-wedel.de] 
Sent: Wednesday, December 16, 2009 10:39 AM
To: users@wicket.apache.org
Subject: Re: onSubmit() not entered (IE6 and IE7)

On Wed, December 16, 2009, Loritsch, Berin C. wrote:

 When Javascript stops working on IE, no further Javascript calls will
 work.  Just to make sure you haven't run into this problem, add a simple
 little button or link that has the javascript action alert('still
 works') to your page.  Once you get to the place where the page
 reproducibly does not work, click on that button.  If the little alert
 dialog box does not open up, then IE's Javascript engine has completely
 crapped out.  My guess is that this is what you are running into,
 without actually seeing anything.

Will do, thank you! But just to clarify things, what is not
working is not an Ajax component but an ordinary submit button.

Cheers,

M'bert

-- 
--- / http://herbert.the-little-red-haired-girl.org / -
=+= 
mir gbbet nix !

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



RE: Modal Window Problems On Internet Explorer.

2009-12-15 Thread Loritsch, Berin C.
The question is whether there is a problem with Javascript or not.  Setting up 
the debugger for IE is a pain in the arse, but worth doing when tracking down 
strange behaviors.  Are you also having problems in Chrome or Safari?  Chrome 
also has some javascript debugging tools, and the engine is different enough 
from Firefox that you may catch the offending code.

-Original Message-
From: victorTrapiello [mailto:vic...@trapiello.net] 
Sent: Tuesday, December 15, 2009 1:56 PM
To: users@wicket.apache.org
Subject: Re: Modal Window Problems On Internet Explorer.


hahahahha I knew that someone was going to come up with this, yes it does, it
works fine in the apache wicket offcial page, but when I do the example and
compile it, it only works in Mozilla! maybe I do not have the last Wicket
release, what do you think¿?

Thanks for the reply Johan


Johan Compagner wrote:
 
 Modal windows are working find for me on IE8
 
 http://wicketstuff.org/wicket14/ajax/modal-window
 
 are you saying that above example doesnt work?
 
 
 On Mon, Dec 14, 2009 at 01:41, victorTrapiello vic...@trapiello.net
 wrote:
 

 Hello guyss, I find it anoying as well I´m developing a web app and now I
 realize that the modal window only works in mozilla... when I try to open
 it
 wit I explorer 7 or 8 it comes up with an error page the url does not
 exist

 do you know how to fix that or it means our lovely java framewor
 Wickets
 is becoming oldfashion...

 Thank you very much guys!!


 bgooren wrote:
 
  I don't have this problem with the Modal Window, so my guess is that
 you
  have some custom javascript which tries to set the focus to an element
  which is either invisible or inactive.
 
  Bas
 
 
  carlo c wrote:
 
  Hi,
 
  I keep on experiencing this when I try to open a modal window in IE6,
 7
  and 8.
 
 
  I don't know if any of you encountered it from before.
 
  Can't move focus to the control because it is invisible, not enabled,
  or of a type that does not accept the focus
 
 
  It's happeningd on Internet Explorer only and it's quite annoying.
 
  Thanks A Lot
 
  -
  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/Modal-Window-Problems-On-Internet-Explorer.-tp26572367p26771544.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/Modal-Window-Problems-On-Internet-Explorer.-tp26572367p26799812.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



Wicket Test Harness and HTTP objects

2009-12-08 Thread Loritsch, Berin C.
I discovered as I implemented the SessionListener to clean up user
record locks that the WicketTester object does not behave as expected in
regards to the HttpSession objects.  I expected to have my
MockHttpSession already configured with the application session object
bound in the specified location.  In otherwords I would expect the
following to work:

MySession session = MySession.get();
HttpSession htSession = tester.getHttpSession();

assertEquals(session, htSession.get(wicket:myapp.context: +
Session.SESSION_ATTRIBUTE_NAME)) 


This is a true condition with a deployed application, however the
mapping has to be done manually by my testcase.  Is this by design or is
this a bug?  The mock objects should provide enough imitation of reality
to allow testing integration points like this a bit easier.


RE: Session stealing with wicket-auth-roles

2009-12-02 Thread Loritsch, Berin C.
I too would like to know the Wicket answer.  The problem is that
JSESSIONID is how the Servlet container differentiates the session with
the user.  It's part of the spec since the beginning.  Because it is
well known and certain browsers (Firefox, representing over a third of
browser clients) make it pretty easy to look at the cookies it has
become a known weakness to people who want to do bad things.

Now, if the entire interaction is done with HTTPS, theoretically you
would be able to use the SSL session ID to match sessions.  That would
be a configuration setting on your Servlet container.

The solution that some frameworks and roll your own security folks have
come up with (like Ruby on Rails) is to use a secondary token as a salt
for a secondary token.  Rails uses this token for all POST requests and
uses a constant time comparison for the token (another topic
altogether).  Of course, Rails stores all session data in a Cookie by
default, encrypted and hashed with the secondary token.  It makes it
more difficult to steal a session that way.  An approach similar to this
(without storing session data in a cookie) can be done using a
ServletFilter.

The alternative I've seen is to change the secondary token periodically
or every request.  The problem with this solution is that you break the
back button when the token changes.  At the very least, the secondary
token should be generated based on requestor information (IP address,
user agent, etc.).  That way the token is not simply a matter of simply
matching the JSESSIONID string against a hash.  You are recreating the
master token the same way and comparing it with what you received.

To summarize, I would most likely create a ServletFilter to handle the
secondary token handling.  The secondary token would be a SHA-1 hash of
an application salt (random characters at least the length of an SHA-1),
the user agent, and the requesting IP address, and the Servlet session
ID.  The ServletFilter either throws a 403 response, or invalidates the
session if the newly generated key does not match the secondary token
provided.  Essentially, the user would have to be behind the same
firewall/gateway, have the same exact browser and patch level, and the
session id to successfully steal a session.  Even within an organization
the differences in user agent strings for Internet Explorer at any
version vary greatly.

Additionally, I would use the ServletFilter to actively reject automated
clients.  If the system lives in SSL, this is a valid approach because
you don't necessarily want the contents indexed.  You'd be surprised how
many poorly behaving web crawlers there are out there.  Many of them are
home-brewed scripts that spider your site, ignoring your robots.txt
file--even on private networks.

-Original Message-
From: Andrew Turner [mailto:grim_toas...@hotmail.com] 
Sent: Wednesday, December 02, 2009 4:24 AM
To: users@wicket.apache.org
Subject: Session stealing with wicket-auth-roles



Good morning all,

I'm hoping I've misconfigured something in my application, but we seem
to be prone to session stealing in our wicket application.  We're using
wicket-auth-roles to provide the security, and if you are able to access
the jsessionid you can get another machine to log straight into the
application as the intercepted user.  We're using HTTPS for the
communication, so hopefully the likelihood of this occurring is quite
small, but we are still being forced to contemplate rewriting the
security layer (which I want to avoid if possible).

So, my question, have I misconfigured something, or is it just not
possible to prevent this sort of attack when using wicket-auth-roles?

I've managed to create a completely stripped-down app that still has the
problem, below is the AuthenticatedWhenSession implementation.

public class HelloWorldWebSession extends AuthenticatedWebSession {
public HelloWorldWebSession(Request request) { super(request); }
public boolean authenticate(String username, String password) {
return helloUser.equals(username)  password.equals(password); }
public Roles getRoles() { return isSignedIn() ? new
Roles(Roles.USER) : null; }
}

And the simple page:

@AuthorizeInstantiation(USER)
public class HelloWorldHomePage extends WebPage { }

And the application:

public class HelloWorldApplication extends AuthenticatedWebApplication {
protected void init() {
super.init();
mountBookmarkablePage(home, HelloWorldHomePage.class);
mountBookmarkablePage(signin, SignInPage.class);
}

protected Class? extends WebPage getSignInPageClass() { return
SignInPage.class; }
protected Class? extends AuthenticatedWebSession
getWebSessionClass() { return HelloWorldWebSession.class; }
public Class? extends Page getHomePage() { return
HelloWorldHomePage.class; }
}

The URL below, once logged in on one machine, could then be used on
multiple machines to bypass the security layer.


It may be basic, but... Globally setting date styles for the application?

2009-12-01 Thread Loritsch, Berin C.
It may seem rather basic, but I'm looking for a reasonably simple way to
globally set how the application displays dates.  On rails, it was as
simple as setting that information in the l10n/i18n resource files.
I've been googling and trying to find the answer in the Wicket in
Action book, but it doesn't seem like it's something anyone's cared to
post the answer to.

At first I thought it was setting up a converter registered with the
java.util.Date class.  The instructions on the Wiki provide answers on
how to do that for wicket 1.1, 1.2, and 1.3.  I attempted the 1.3
solution, and my dates are not changed.  Here's what I have:

@Override
protected IConverterLocator newConverterLocator() {
ConverterLocator converterLocator = new ConverterLocator();
converterLocator.set(Date.class, new DateConverter() {
private static final long serialVersionUID =
194715223274764825L;

@Override
public DateFormat getDateFormat(Locale locale) {
return new SimpleDateFormat(-MM-dd);
}
});
return converterLocator;
}

The date still is displayed like: 11/12/09 12:58 PM

Am I missing something?  Even more specifically, I would like to have
three styles I can switch between: date only, time only, and date and
time.  I'm trying not to repeat myself if I can help it.  I'd like to
default to date only and specify time or date/time when needed.  I
can't seem to get the system to recognize my date only solution.

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



RE: It may be basic, but... Globally setting date styles for the application?

2009-12-01 Thread Loritsch, Berin C.
It appears that the newConverterLocator() route is about right, but I
have a slight issue between the Hibernate binding and what I want to
happen.  In order for the converter to work, it looks for the exact
class.  That means that java.util.Date won't work when the subclass
actually used is java.sql.Timestamp.  Problem is that I need to display
just the date at some times, and allow people to see the full timestamp
at others (depending on the context).  For example, on the main page
where I show a record the dates alone are fine, but on the page where I
display the audit history I need the full date.

So, how do I accomplish what I'm after without overcomplicating my
pages?  Are converters set per page?  That may be good enough for now.

Also, is there any real reason why the standard converters don't allow
you to specify a style without subclassing?

-Original Message-
From: Loritsch, Berin C. [mailto:berin.lorit...@gd-ais.com] 
Sent: Tuesday, December 01, 2009 11:54 AM
To: users@wicket.apache.org
Subject: It may be basic, but... Globally setting date styles for the
application?

It may seem rather basic, but I'm looking for a reasonably simple way to
globally set how the application displays dates.  On rails, it was as
simple as setting that information in the l10n/i18n resource files.
I've been googling and trying to find the answer in the Wicket in
Action book, but it doesn't seem like it's something anyone's cared to
post the answer to.

At first I thought it was setting up a converter registered with the
java.util.Date class.  The instructions on the Wiki provide answers on
how to do that for wicket 1.1, 1.2, and 1.3.  I attempted the 1.3
solution, and my dates are not changed.  Here's what I have:

@Override
protected IConverterLocator newConverterLocator() {
ConverterLocator converterLocator = new ConverterLocator();
converterLocator.set(Date.class, new DateConverter() {
private static final long serialVersionUID =
194715223274764825L;

@Override
public DateFormat getDateFormat(Locale locale) {
return new SimpleDateFormat(-MM-dd);
}
});
return converterLocator;
}

The date still is displayed like: 11/12/09 12:58 PM

Am I missing something?  Even more specifically, I would like to have
three styles I can switch between: date only, time only, and date and
time.  I'm trying not to repeat myself if I can help it.  I'd like to
default to date only and specify time or date/time when needed.  I
can't seem to get the system to recognize my date only solution.

-
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: It may be basic, but... Globally setting date styles for the application?

2009-12-01 Thread Loritsch, Berin C.
I think your answer got lost somewhere.

-Original Message-
From: Antoine Angenieux [mailto:aangeni...@clinigrid.com] 
Sent: Tuesday, December 01, 2009 1:06 PM
To: users@wicket.apache.org
Subject: Re: It may be basic, but... Globally setting date styles for the 
application?




--
Antoine Angénieux
Associé

Clinigrid
5, avenue Mozart
75016 Paris, France
+336 60 21 09 18
aangeni...@clinigrid.com

Le 1 déc. 2009 à 18:57, Loritsch, Berin C. berin.lorit...@gd- 
ais.com a écrit :

 It appears that the newConverterLocator() route is about right, but I
 have a slight issue between the Hibernate binding and what I want to
 happen.  In order for the converter to work, it looks for the exact
 class.  That means that java.util.Date won't work when the subclass
 actually used is java.sql.Timestamp.  Problem is that I need to  
 display
 just the date at some times, and allow people to see the full  
 timestamp
 at others (depending on the context).  For example, on the main page
 where I show a record the dates alone are fine, but on the page  
 where I
 display the audit history I need the full date.

 So, how do I accomplish what I'm after without overcomplicating my
 pages?  Are converters set per page? That may be good enough for now.

 Also, is there any real reason why the standard converters don't allow
 you to specify a style without subclassing?

 -Original Message-
 From: Loritsch, Berin C. [mailto:berin.lorit...@gd-ais.com]
 Sent: Tuesday, December 01, 2009 11:54 AM
 To: users@wicket.apache.org
 Subject: It may be basic, but... Globally setting date styles for the
 application?

 It may seem rather basic, but I'm looking for a reasonably simple  
 way to
 globally set how the application displays dates.  On rails, it was as
 simple as setting that information in the l10n/i18n resource files.
 I've been googling and trying to find the answer in the Wicket in
 Action book, but it doesn't seem like it's something anyone's cared  
 to
 post the answer to.

 At first I thought it was setting up a converter registered with the
 java.util.Date class.  The instructions on the Wiki provide answers on
 how to do that for wicket 1.1, 1.2, and 1.3.  I attempted the 1.3
 solution, and my dates are not changed.  Here's what I have:

@Override
protected IConverterLocator newConverterLocator() {
ConverterLocator converterLocator = new ConverterLocator();
converterLocator.set(Date.class, new DateConverter() {
private static final long serialVersionUID =
 194715223274764825L;

@Override
public DateFormat getDateFormat(Locale locale) {
return new SimpleDateFormat(-MM-dd);
}
});
return converterLocator;
}

 The date still is displayed like: 11/12/09 12:58 PM

 Am I missing something?  Even more specifically, I would like to have
 three styles I can switch between: date only, time only, and date and
 time.  I'm trying not to repeat myself if I can help it.  I'd like to
 default to date only and specify time or date/time when needed.  I
 can't seem to get the system to recognize my date only solution.

 -
 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: onclick auto-added to script tags?

2009-11-30 Thread Loritsch, Berin C.
Using Wicket 1.4.3.

Since things are working right now without the wicket:link/ tag, I'm
going to leave it like that.

-Original Message-
From: bgooren [mailto:b...@iswd.nl] 
Sent: Thursday, November 26, 2009 6:26 AM
To: users@wicket.apache.org
Subject: RE: onclick auto-added to script tags?


Well, I don't use Spring integration in my projects, so I cannot tell
you for
sure if that could be the reason for this. I do however find it unlikely
that Spring integration would alter html tags.

What you could try is step through the rendering process with a debugger
and
see what's happening with the wicket:link/ tag. See AutoLinkResolver
and
WicketLinkTagHandler.
Which version of Wicket are you running?


Loritsch, Berin C. wrote:
 
 I'm integrated with Spring/Hibernate, could this be a side effect from
 the SpringInvocationHandler?  I've not added anything of the sort
 directly (i.e. I have not created any ComponentInstantiationListeners
 myself).
 
 I've removed the wicket:link/ blocks for now in my header and things
 are working as expected.  That rules out a browser plugin being at
 fault.

-- 
View this message in context:
http://old.nabble.com/onclick-auto-added-to-%3Cscript%3E-tags--tp2650427
4p26526076.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: onclick auto-added to script tags?

2009-11-25 Thread Loritsch, Berin C.
I'm integrated with Spring/Hibernate, could this be a side effect from
the SpringInvocationHandler?  I've not added anything of the sort
directly (i.e. I have not created any ComponentInstantiationListeners
myself).

I've removed the wicket:link/ blocks for now in my header and things
are working as expected.  That rules out a browser plugin being at
fault.

-Original Message-
From: bgooren [mailto:b...@iswd.nl] 
Sent: Wednesday, November 25, 2009 7:07 AM
To: users@wicket.apache.org
Subject: Re: onclick auto-added to script tags?


I'm using wicket:link/ blocks around javascript references as well and
have
never observed the behavior you describe. Do you auto-add a behavior to
components which adds the onclick value? It's being added from
somewhere,
and is not default Wicket behavior. So it's either a browser plugin or
an
IBehavior added from, say, a ComponentInstantiationListener.

Bas


Loritsch, Berin C. wrote:
 
 I have my HTML header links for CSS and JavaScript surrounded in a
 wicket:link/ block so that it can resolve the context name, etc.
 Problem is that it causes unexpected and peculiar behavior:
 
 script type=text/javascript src=script/prototype.js/script
 
 Becomes
 
 script type=text/javascript src=script/prototype.js
 onclick=window.location.href='script/prototype.js';return
 false;/script
 
 Which is invalid markup, much less causing errors for me.  How do I
get
 rid of the onclick attribute?
 
 -
 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/onclick-auto-added-to-%3Cscript%3E-tags--tp2650427
4p26511542.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



SessionListeners and Wicket?

2009-11-25 Thread Loritsch, Berin C.
I have a requirement to have a queue of items that need work with a pool
of people working on them.  I need to lock the record while someone is
working on it.  Once the item is processed it will be removed
permanently from the list.  Occasionally users open an item and then
close it.  That part I've got taken care of.  I also have the part taken
care of where a user manually logs out and the system releases any locks
the user has.

However, that doesn't catch the problem where users sessions time out.
My best guess is that I need to add a SessionListener to the web.xml to
handle this corner case.  So I have two questions:

* Can I use the IMSSession.get() from my SessionListener and get the one
for the running application?
* Is there a more elegant Wicket way of doing the same thing?

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



RE: Can @SpringBeans be optional?

2009-11-24 Thread Loritsch, Berin C.
Understood.  Just introducing it as a possibility.

-Original Message-
From: James Carman [mailto:jcar...@carmanconsulting.com] 
Sent: Monday, November 23, 2009 3:40 PM
To: users@wicket.apache.org
Subject: Re: Can @SpringBeans be optional?

That's not a dependency injection thing.  It's a design pattern
called the Null Object pattern.

On Mon, Nov 23, 2009 at 12:38 PM, Loritsch, Berin C.
berin.lorit...@gd-ais.com wrote:
 Technically speaking from the Dependency Injection koolaid doctrine, the
 best way to solve the problem is to have a null implementation of your
 service that does nothing.  The code you are writing doesn't have to
 have complex if/else logic as it's able to assume the service is always
 there.  The null implementation is wired in for the app that doesn't use
 it.

 Alternatively, create your accessor (getRememberMeService()) in the
 session that will access the ApplicationContext itself.  It will
 determine if the bean exists or not and return the appropriate value.
 Since it allows for lazy initialization, it also addresses any issues
 from the ApplicationContext not being set up in time during unit
 testing.

 -Original Message-
 From: Anthony DePalma [mailto:fatef...@gmail.com]
 Sent: Monday, November 23, 2009 6:47 AM
 To: users@wicket.apache.org
 Subject: Can @SpringBeans be optional?

 Often with spring I give some of my services extra features if they are
 configured in the xml for it, but otherwise if they are null they are
 simply
 ignored. I'm running into an issue with my websession, that one of my
 apps
 can use the RememberMeService but another cannot. However, I'd like to
 have
 one abstractwebsession they can share, but unfortunately I'll get an
 exception when starting the app without the rememberMeService defined in
 the
 xml. It wouldn't make sense to define one to satisfy the error.

 The only solution I had so far was to inject it into the application
 class,
 where i can do so without @springbeans and thus a service can be null,
 but
 is there any way I can configure springbeans to not throw an error on
 startup for optional services?

 -
 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: Adding markup to ListView containing tag?

2009-11-24 Thread Loritsch, Berin C.
Thank you, that worked.

-Original Message-
From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] 
Sent: Monday, November 23, 2009 7:03 PM
To: users@wicket.apache.org
Subject: Re: Adding markup to ListView containing tag?


 div id=triage-items
 div id=triage-1 wicket:id=listviewfancy markup here/div
/div

class mypage extends webpage implements iheadercontributor {

public mypage() {
  add(new listview(listview,...) {
protected item newitem(string id, int idx) {
 return new item(id, idx) {
  protected oncomponenttag(tag) { tag.put(class,fancyitem); }
 };
   });
}

renderhead(resp) {
resp.renderondomreadyjavascript($(.fancyitem.whatever_jquery_thing_you_want);
}
}

-igor

On Mon, Nov 23, 2009 at 2:41 PM, Loritsch, Berin C.
berin.lorit...@gd-ais.com wrote:
 What I would like is to be able to have markup like this:

 div id=triage-items
  div id=triage-1fancy markup here/div
  div id=triage-2fancy markup here/div
 /div

 Along with this, to provide javascript effects on hover/focus for the
 individual items in the list.  The problem is that I can't do this with
 Wicket easily.  I basically get markup like this:

 divfancy markup here/div
 divfancy markup here/div

 I attempted to create a panel with a panel with the ListView to do what
 I wanted, but it ended up looking like this:

 divdivfancy markup here/div/div
 divdivfancy markup here/div/div

 Which is no-where near what I want.  I'm trying to work with the Wicket
 in Action book and the short section on repeating lists doesn't provide
 enough to help me get it working.  All my attempts at writing the id
 attribute using the examples in the book don't work (no ID is ever
 created).

 Can anyone help my sanity?  While I do care about the markup, it's less
 important than the end target of adding the AJAX effects to the items in
 the list.

 -
 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



onclick auto-added to script tags?

2009-11-24 Thread Loritsch, Berin C.
I have my HTML header links for CSS and JavaScript surrounded in a
wicket:link/ block so that it can resolve the context name, etc.
Problem is that it causes unexpected and peculiar behavior:

script type=text/javascript src=script/prototype.js/script

Becomes

script type=text/javascript src=script/prototype.js
onclick=window.location.href='script/prototype.js';return
false;/script

Which is invalid markup, much less causing errors for me.  How do I get
rid of the onclick attribute?

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



RE: Can @SpringBeans be optional?

2009-11-23 Thread Loritsch, Berin C.
Technically speaking from the Dependency Injection koolaid doctrine, the
best way to solve the problem is to have a null implementation of your
service that does nothing.  The code you are writing doesn't have to
have complex if/else logic as it's able to assume the service is always
there.  The null implementation is wired in for the app that doesn't use
it.

Alternatively, create your accessor (getRememberMeService()) in the
session that will access the ApplicationContext itself.  It will
determine if the bean exists or not and return the appropriate value.
Since it allows for lazy initialization, it also addresses any issues
from the ApplicationContext not being set up in time during unit
testing.

-Original Message-
From: Anthony DePalma [mailto:fatef...@gmail.com] 
Sent: Monday, November 23, 2009 6:47 AM
To: users@wicket.apache.org
Subject: Can @SpringBeans be optional?

Often with spring I give some of my services extra features if they are
configured in the xml for it, but otherwise if they are null they are
simply
ignored. I'm running into an issue with my websession, that one of my
apps
can use the RememberMeService but another cannot. However, I'd like to
have
one abstractwebsession they can share, but unfortunately I'll get an
exception when starting the app without the rememberMeService defined in
the
xml. It wouldn't make sense to define one to satisfy the error.

The only solution I had so far was to inject it into the application
class,
where i can do so without @springbeans and thus a service can be null,
but
is there any way I can configure springbeans to not throw an error on
startup for optional services?

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



Adding markup to ListView containing tag?

2009-11-23 Thread Loritsch, Berin C.
What I would like is to be able to have markup like this:

div id=triage-items
  div id=triage-1fancy markup here/div
  div id=triage-2fancy markup here/div
/div

Along with this, to provide javascript effects on hover/focus for the
individual items in the list.  The problem is that I can't do this with
Wicket easily.  I basically get markup like this:

divfancy markup here/div
divfancy markup here/div

I attempted to create a panel with a panel with the ListView to do what
I wanted, but it ended up looking like this:

divdivfancy markup here/div/div
divdivfancy markup here/div/div

Which is no-where near what I want.  I'm trying to work with the Wicket
in Action book and the short section on repeating lists doesn't provide
enough to help me get it working.  All my attempts at writing the id
attribute using the examples in the book don't work (no ID is ever
created).

Can anyone help my sanity?  While I do care about the markup, it's less
important than the end target of adding the AJAX effects to the items in
the list.

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



Resolving image locations

2009-11-20 Thread Loritsch, Berin C.
I'm using the Wicket Image object, and I'm having a hard time ensuring
that it resolves properly.

I have a base class to set up the UI template for the site, including
the logo image.  I added a new page in a child package, and as a result
the Image declared in the base class is resolving relative to the new
class.  This is counter-intuitive, and violates the expectations of
object oriented programming.  Here is the basic situation:

package.SiteTemplate

Declares Image(Logo)


package.images.Logo
---
Contains the image


package.subsystem.NewPage
-
Uses logo declared in SiteTemplate,
But browser can't find it



What I want to do is tell Wicket to always provide one path for the Logo
image, so I don't have to duplicate the logo in several packages.  I
attempted to hardcode the path in plain HTML, but that URL broke as soon
as the IDE put the app in a context.  I'd like Wicket to take care of
the base path, but not treat it like a resource that needs to be
internationalized.  How do I do that?

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



RE: Resolving image locations

2009-11-20 Thread Loritsch, Berin C.
Never mind.  The problem was using Image instead of ContextImage.  I
guess that's the danger of relying on type-ahead to suggest the right
thing.

-Original Message-
From: Loritsch, Berin C. [mailto:berin.lorit...@gd-ais.com] 
Sent: Friday, November 20, 2009 1:23 PM
To: users@wicket.apache.org
Subject: Resolving image locations

I'm using the Wicket Image object, and I'm having a hard time ensuring
that it resolves properly.

I have a base class to set up the UI template for the site, including
the logo image.  I added a new page in a child package, and as a result
the Image declared in the base class is resolving relative to the new
class.  This is counter-intuitive, and violates the expectations of
object oriented programming.  Here is the basic situation:

package.SiteTemplate

Declares Image(Logo)


package.images.Logo
---
Contains the image


package.subsystem.NewPage
-
Uses logo declared in SiteTemplate,
But browser can't find it



What I want to do is tell Wicket to always provide one path for the Logo
image, so I don't have to duplicate the logo in several packages.  I
attempted to hardcode the path in plain HTML, but that URL broke as soon
as the IDE put the app in a context.  I'd like Wicket to take care of
the base path, but not treat it like a resource that needs to be
internationalized.  How do I do that?

-
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



Generating standards compliant responses

2009-11-20 Thread Loritsch, Berin C.
I've set up in my SiteTemplate base class a call to set the content type
for the response, however it is not making it to the browser.  Any
ideas?  When I inspect the request headers and run the site validator
against my page the server content type is set to text/html even
though I've told it otherwise.  What am I missing here?  If it helps, it
is hosted in Tomcat 6.  I need the Content-Type HTTP response header
to return application/xhtml+xml

public class SiteTemplate extends WebPage {
//
public void onBeforeRender() {  

super.getResponse().setContentType(application/xhtml+xml; utf-8);
super.getResponse().setCharacterEncoding(utf-8);

user = IMSSession.get().getUser();

if (null == user  ! (this instanceof LoginPage)) {
this.redirectToInterceptPage(new
LoginPage(null));
}

if (get(content) == null) {
BookmarkablePageLinkString homeLink = new
BookmarkablePageLinkString(home,
IMSApplication.get().getHomePage());
homeLink.add(new ContextImage(logo,
images/logo.png));
add(homeLink);
add(newUserInfo(userinfo));
add(newContentPanel(content));
add(newUserPanel(userbar));
}

super.onBeforeRender();
}
//  define the newUserInfo, newContentPanel, and newUserPanel
abstract methods
}


RE: Generating standards compliant responses

2009-11-20 Thread Loritsch, Berin C.
I just found this out.  Thank you.



-Original Message-
From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] 
Sent: Friday, November 20, 2009 3:44 PM
To: users@wicket.apache.org
Subject: Re: Generating standards compliant responses

Try setting it in configureresponse()

-igor

On Friday, November 20, 2009, Loritsch, Berin C.
berin.lorit...@gd-ais.com wrote:
 I've set up in my SiteTemplate base class a call to set the content type
 for the response, however it is not making it to the browser.  Any
 ideas?  When I inspect the request headers and run the site validator
 against my page the server content type is set to text/html even
 though I've told it otherwise.  What am I missing here?  If it helps, it
 is hosted in Tomcat 6.  I need the Content-Type HTTP response header
 to return application/xhtml+xml

 public class SiteTemplate extends WebPage {
 //
         public void onBeforeRender() {

 super.getResponse().setContentType(application/xhtml+xml; utf-8);
                 super.getResponse().setCharacterEncoding(utf-8);

                 user = IMSSession.get().getUser();

                 if (null == user  ! (this instanceof LoginPage)) {
                         this.redirectToInterceptPage(new
 LoginPage(null));
                 }

                 if (get(content) == null) {
                         BookmarkablePageLinkString homeLink = new
 BookmarkablePageLinkString(home,
 IMSApplication.get().getHomePage());
                         homeLink.add(new ContextImage(logo,
 images/logo.png));
                         add(homeLink);
                         add(newUserInfo(userinfo));
                         add(newContentPanel(content));
                         add(newUserPanel(userbar));
                 }

                 super.onBeforeRender();
         }
 //  define the newUserInfo, newContentPanel, and newUserPanel
 abstract methods
 }


-
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



Validating markup on non bookmarkable pages?

2009-11-20 Thread Loritsch, Berin C.
I'm using the TotalValidator plugin combined with a local basic
validator installation.  It's a great tool to keep me honest with the
accessibility and standards compliant code.  However certain pages that
aren't linked with a BookmarkableLink can't be validated with the tool.
I end up getting an error like the following:

Nov 20, 2009 3:46:43 PM com.totalvalidator.Validator main
SEVERE: Validation Failed
com.totalvalidator.exceptions.ValidationException: Error retrieving
page: http://localhost:8010/incidents/?wicket:interface=:1 : 404 Not
Found
at com.totalvalidator.utils.FileUtils.getReader(Unknown Source)
at com.totalvalidator.Validator.validate(Unknown Source)
at com.totalvalidator.Validator.main(Unknown Source)


The odd thing is that if I put the same exact URL in my browser the page
renders perfectly fine.  My guess is that because the tool doesn't have
the JSESSIONID cookie and/or has a different browser type that Wicket
expires the page.  Is that correct?  If so, is there any way to work
around it?

If I'm using the redirectToInterceptPage() to get to a login page, is
there a way I can make it bookmarkable?

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



RE: wicket + jdbc template app

2009-11-19 Thread Loritsch, Berin C.
DBCP and C3P0 are implementations of the pooled DataSource interface, so
all you have to do is bind them to JNDI.  Tomcat and other Servlet
container vendors have instructions on how to do this.  Inside your
code, you access it through the JNDI API which looks up the pooled
datasource.

Do be sure to close anything you open, which includes resultsets,
statements, and connections.  Put the close code in finally statements
to ensure that you don't fill up your pool with open resources.  Open
ResultSets also have matching resources on your database server, so you
can introduce scalability problems if you aren't careful.

-Original Message-
From: Clint Checketts [mailto:checke...@gmail.com] 
Sent: Thursday, November 19, 2009 8:35 AM
To: users@wicket.apache.org
Subject: Re: wicket + jdbc template app

My Wicket app I maintain only uses the JdbcTemplate class from Spring.
We
don't use any hibernate or other ORM framework.

I don't have any code I can give, but I can answer any questions. How
far
have you gotten?

-Clint


On Thu, Nov 19, 2009 at 7:23 AM, James Carman
jcar...@carmanconsulting.comwrote:

 Are you saying you don't want to use Spring at all?  But, you do want
 to use DBCP or C3P0?

 On Thu, Nov 19, 2009 at 7:46 AM, Ivan Dudko ivan.du...@gmail.com
wrote:
  Hello, guys!
 
  I am still could not implement wicket application without any
  persistence framework and also spring-jdbc.
  I want to use only connection pooling with dbcp or c3p0.
  May you provide example for this kind of app.
 
  Thank you for answer!
 
 
-
  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: Spring/Wicket/Hibernate testing driving me banana nuts

2009-11-18 Thread Loritsch, Berin C.
OK.  I've got it working again.  The HibernateSession was set up in a hibernate 
Servlet filter.  I found the minimum necessary lines to get the system working 
using my session factory configured in Spring.  For the interested parties, 
here they are:



SessionFactory factory = (SessionFactory) 
getSpringContext().getBean(sessionFactory);
Session session = SessionFactoryUtils.getSession(factory, true);
session.setFlushMode(FlushMode.AUTO);
TransactionSynchronizationManager.bindResource(factory, new 
SessionHolder(session));


I have them set up just after I configured the Spring container.

Thank you for pointing me in the right direction.


-Original Message-
From: Eelco Hillenius [mailto:eelco.hillen...@gmail.com] 
Sent: Tuesday, November 17, 2009 7:06 PM
To: users@wicket.apache.org
Subject: Re: Spring/Wicket/Hibernate testing driving me banana nuts

So in typical web applications, people would install a session filter
(like https://www.hibernate.org/43.html), which would open a session
at the start of a request, and close it afterwards. You probably need
to find an alternative for that filter in your test code.

Eelco

On Tue, Nov 17, 2009 at 4:26 PM, Loritsch, Berin C.
berin.lorit...@gd-ais.com wrote:
 Hmm, OK attachments are stripped here.  Having gone back up through the stack 
 trace, WicketTester extends BaseWicketTester which then extends 
 MockWebApplication.  Essentially MockWebApplication has the base 
 implementations for setting up the WebRequestCycle.

 The @SpringBean is having an effect, because my exception is a 
 HibernateException and not a NullPointerException.  I think it has something 
 to do with how the     tx:annotation-driven transaction-manager=txManager 
 / interacts with the WicketTester that is unclear to me.  The thing that has 
 changed is that while I had that declaration, I introduced using the 
 @Transactional attributes on some of my Hibernate objects.  Spring is giving 
 me a proxied class that is supposed to take care of the hibernate sessions 
 and transactions for me.  It's having a hard time in the JUnit environment.  
 I'm using the following TransactionManager:

    bean id=txManager
        class=org.springframework.orm.hibernate3.HibernateTransactionManager
        property name=sessionFactory ref=sessionFactory /
    /bean


 -Original Message-
 From: Loritsch, Berin C. [mailto:berin.lorit...@gd-ais.com]
 Sent: Tuesday, November 17, 2009 4:15 PM
 To: users@wicket.apache.org
 Subject: RE: Spring/Wicket/Hibernate testing driving me banana nuts

 I've got the part that injects a Spring WebApplicationContext into the 
 WicketTester already (Source attached).  I should be using the application 
 class, if I'm not then something has changed unbeknownst to me.  Is there any 
 place it would swap out what I told it to use for what it decided on its own 
 to use?

 -Original Message-
 From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
 Sent: Tuesday, November 17, 2009 4:05 PM
 To: users@wicket.apache.org
 Subject: Re: Spring/Wicket/Hibernate testing driving me banana nuts

 i see you are using MockWebApplication in your tests. this application does 
 not install the SpringComponentInjector and so @SpringBean has no effect.

 you should either give wickettester an instance of your actual application 
 class, or create a mock one that installs springcomponentinjector.

 -igor

 On Tue, Nov 17, 2009 at 1:00 PM, Loritsch, Berin C.
 berin.lorit...@gd-ais.com wrote:
  application.xml I initially had a setup that worked with both a
 Web context and a JUnit context.  The problem was the amount of hand
 coding and adjusting of the Spring context the approach needed.  I
 finally got the Spring's transaction interceptor working with the
 auto-wiring (the key is using an interface).  So now my problem is
 that while I've saved myself the headache of making changes to a bunch
 of files every time I add a new service, my unit tests are now failing.

 I've traced the failure to a specific class that is decorated with the
 InjectorHolder--although I believe that is merely because it is the
 first component that does any Hibernate requests.  I'll include the
 stacktrace at the bottom of the message.

 I had to remove the line that specified that sessions would be thread
 bound in Hibernate to take advantage of the Spring managed
 transactions, and adding that configuration item back in makes no
 difference for the tests.  I'm hoping I'm just missing something
 simple, but all my Googling is turning up dead ends.  Any help out there?








 org.apache.wicket.WicketRuntimeException: Error attaching this
 container for rendering: [MarkupContainer [Component id = content]]
        at
 org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContain
 er
 .java:1739)
        at
 org.apache.wicket.Component.onBeforeRender(Component.java:3854

RE: Wicket + Spring + Hibernate - Wicket-In-Action

2009-11-17 Thread Loritsch, Berin C.
I'm not sure the purpose of the interceptor, but until you have a need
to extend and use it, you can use the org.hibernate.EmptyInterceptor
class instead of creating your own.  I have had no problems with using
that class.

-Original Message-
From: Jeffrey Schneller [mailto:jeffrey.schnel...@envisa.com] 
Sent: Monday, November 16, 2009 12:38 PM
To: users@wicket.apache.org
Subject: Wicket + Spring + Hibernate - Wicket-In-Action

At the link[1] it describes how to configure wicket to use Spring and
Hibernate.  In the applicationContext.xml file there is reference to a n
interceptor bean.  What is this interceptor bean?  What is the
definition of this bean?  Everything else seems to make sense.

 

Also how would one move the configuration of the jdbc connection to
code?  It is desirable to db connection information reside at the server
level so when deploying code from dev to stage to production, you do not
need change or replace a file.  The configuration is at the server level
[in the server context] and it is pulled from there.

 

Thanks.

 

 

 

[1]
http://wicketinaction.com/2009/06/wicketspringhibernate-configuration/

 


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



Spring/Wicket/Hibernate testing driving me banana nuts

2009-11-17 Thread Loritsch, Berin C.
 application.xml I initially had a setup that worked with both a Web
context and a JUnit context.  The problem was the amount of hand coding
and adjusting of the Spring context the approach needed.  I finally got
the Spring's transaction interceptor working with the auto-wiring (the
key is using an interface).  So now my problem is that while I've saved
myself the headache of making changes to a bunch of files every time I
add a new service, my unit tests are now failing.

I've traced the failure to a specific class that is decorated with the
InjectorHolder--although I believe that is merely because it is the
first component that does any Hibernate requests.  I'll include the
stacktrace at the bottom of the message.

I had to remove the line that specified that sessions would be thread
bound in Hibernate to take advantage of the Spring managed transactions,
and adding that configuration item back in makes no difference for the
tests.  I'm hoping I'm just missing something simple, but all my
Googling is turning up dead ends.  Any help out there?








org.apache.wicket.WicketRuntimeException: Error attaching this container
for rendering: [MarkupContainer [Component id = content]]
at
org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer
.java:1739)
at
org.apache.wicket.Component.onBeforeRender(Component.java:3854)
at
org.apache.wicket.Component.internalBeforeRender(Component.java:1061)
at org.apache.wicket.Component.beforeRender(Component.java:1095)
at
org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer
.java:1727)
at
org.apache.wicket.Component.onBeforeRender(Component.java:3854)
at org.apache.wicket.Page.onBeforeRender(Page.java:1501)
at
com.gdais.incidents.view.SiteTemplate.onBeforeRender(SiteTemplate.java:3
3)
at
org.apache.wicket.Component.internalBeforeRender(Component.java:1061)
at org.apache.wicket.Component.beforeRender(Component.java:1095)
at
org.apache.wicket.Component.prepareForRender(Component.java:2223)
at
org.apache.wicket.Component.prepareForRender(Component.java:2260)
at org.apache.wicket.Page.renderPage(Page.java:893)
at
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget
.respond(BookmarkablePageRequestTarget.java:262)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.respond(Abstract
RequestCycleProcessor.java:105)
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java
:1258)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:594)
at
org.apache.wicket.protocol.http.MockWebApplication.processRequestCycle(M
ockWebApplication.java:478)
at
org.apache.wicket.protocol.http.MockWebApplication.processRequestCycle(M
ockWebApplication.java:390)
at
org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTeste
r.java:301)
at
com.gdais.incidents.view.TestTriagePanel.assertTriageNotAvailableFor(Tes
tTriagePanel.java:33)
at
com.gdais.incidents.view.TestTriagePanel.testTriagePanelNotForAdministra
tor(TestTriagePanel.java:27)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUn
it3TestReference.java:130)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.ja
va:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTe
stRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTe
stRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRun
ner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRu
nner.java:196)
Caused by: org.hibernate.HibernateException: No Hibernate Session bound
to thread, and configuration does not allow creation of
non-transactional one here
at
org.springframework.orm.hibernate3.SpringSessionContext.currentSession(S

RE: Spring/Wicket/Hibernate testing driving me banana nuts

2009-11-17 Thread Loritsch, Berin C.
I've got the part that injects a Spring WebApplicationContext into the 
WicketTester already (Source attached).  I should be using the application 
class, if I'm not then something has changed unbeknownst to me.  Is there any 
place it would swap out what I told it to use for what it decided on its own to 
use?

-Original Message-
From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] 
Sent: Tuesday, November 17, 2009 4:05 PM
To: users@wicket.apache.org
Subject: Re: Spring/Wicket/Hibernate testing driving me banana nuts

i see you are using MockWebApplication in your tests. this application
does not install the SpringComponentInjector and so @SpringBean has no
effect.

you should either give wickettester an instance of your actual
application class, or create a mock one that installs
springcomponentinjector.

-igor

On Tue, Nov 17, 2009 at 1:00 PM, Loritsch, Berin C.
berin.lorit...@gd-ais.com wrote:
  application.xml I initially had a setup that worked with both a Web
 context and a JUnit context.  The problem was the amount of hand coding
 and adjusting of the Spring context the approach needed.  I finally got
 the Spring's transaction interceptor working with the auto-wiring (the
 key is using an interface).  So now my problem is that while I've saved
 myself the headache of making changes to a bunch of files every time I
 add a new service, my unit tests are now failing.

 I've traced the failure to a specific class that is decorated with the
 InjectorHolder--although I believe that is merely because it is the
 first component that does any Hibernate requests.  I'll include the
 stacktrace at the bottom of the message.

 I had to remove the line that specified that sessions would be thread
 bound in Hibernate to take advantage of the Spring managed transactions,
 and adding that configuration item back in makes no difference for the
 tests.  I'm hoping I'm just missing something simple, but all my
 Googling is turning up dead ends.  Any help out there?








 org.apache.wicket.WicketRuntimeException: Error attaching this container
 for rendering: [MarkupContainer [Component id = content]]
        at
 org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer
 .java:1739)
        at
 org.apache.wicket.Component.onBeforeRender(Component.java:3854)
        at
 org.apache.wicket.Component.internalBeforeRender(Component.java:1061)
        at org.apache.wicket.Component.beforeRender(Component.java:1095)
        at
 org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer
 .java:1727)
        at
 org.apache.wicket.Component.onBeforeRender(Component.java:3854)
        at org.apache.wicket.Page.onBeforeRender(Page.java:1501)
        at
 com.gdais.incidents.view.SiteTemplate.onBeforeRender(SiteTemplate.java:3
 3)
        at
 org.apache.wicket.Component.internalBeforeRender(Component.java:1061)
        at org.apache.wicket.Component.beforeRender(Component.java:1095)
        at
 org.apache.wicket.Component.prepareForRender(Component.java:2223)
        at
 org.apache.wicket.Component.prepareForRender(Component.java:2260)
        at org.apache.wicket.Page.renderPage(Page.java:893)
        at
 org.apache.wicket.request.target.component.BookmarkablePageRequestTarget
 .respond(BookmarkablePageRequestTarget.java:262)
        at
 org.apache.wicket.request.AbstractRequestCycleProcessor.respond(Abstract
 RequestCycleProcessor.java:105)
        at
 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java
 :1258)
        at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
        at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
        at org.apache.wicket.RequestCycle.request(RequestCycle.java:594)
        at
 org.apache.wicket.protocol.http.MockWebApplication.processRequestCycle(M
 ockWebApplication.java:478)
        at
 org.apache.wicket.protocol.http.MockWebApplication.processRequestCycle(M
 ockWebApplication.java:390)
        at
 org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTeste
 r.java:301)
        at
 com.gdais.incidents.view.TestTriagePanel.assertTriageNotAvailableFor(Tes
 tTriagePanel.java:33)
        at
 com.gdais.incidents.view.TestTriagePanel.testTriagePanelNotForAdministra
 tor(TestTriagePanel.java:27)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
 a:39)
        at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
 Impl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at junit.framework.TestCase.runTest(TestCase.java:164)
        at junit.framework.TestCase.runBare(TestCase.java:130)
        at junit.framework.TestResult$1.protect(TestResult.java:106)
        at junit.framework.TestResult.runProtected(TestResult.java:124)
        at junit.framework.TestResult.run(TestResult.java:109)
        at junit.framework.TestCase.run(TestCase.java:120

RE: Spring/Wicket/Hibernate testing driving me banana nuts

2009-11-17 Thread Loritsch, Berin C.
Hmm, OK attachments are stripped here.  Having gone back up through the stack 
trace, WicketTester extends BaseWicketTester which then extends 
MockWebApplication.  Essentially MockWebApplication has the base 
implementations for setting up the WebRequestCycle.

The @SpringBean is having an effect, because my exception is a 
HibernateException and not a NullPointerException.  I think it has something to 
do with how the tx:annotation-driven transaction-manager=txManager / 
interacts with the WicketTester that is unclear to me.  The thing that has 
changed is that while I had that declaration, I introduced using the 
@Transactional attributes on some of my Hibernate objects.  Spring is giving me 
a proxied class that is supposed to take care of the hibernate sessions and 
transactions for me.  It's having a hard time in the JUnit environment.  I'm 
using the following TransactionManager:

bean id=txManager
class=org.springframework.orm.hibernate3.HibernateTransactionManager
property name=sessionFactory ref=sessionFactory /
/bean


-Original Message-
From: Loritsch, Berin C. [mailto:berin.lorit...@gd-ais.com] 
Sent: Tuesday, November 17, 2009 4:15 PM
To: users@wicket.apache.org
Subject: RE: Spring/Wicket/Hibernate testing driving me banana nuts

I've got the part that injects a Spring WebApplicationContext into the 
WicketTester already (Source attached).  I should be using the application 
class, if I'm not then something has changed unbeknownst to me.  Is there any 
place it would swap out what I told it to use for what it decided on its own to 
use?

-Original Message-
From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
Sent: Tuesday, November 17, 2009 4:05 PM
To: users@wicket.apache.org
Subject: Re: Spring/Wicket/Hibernate testing driving me banana nuts

i see you are using MockWebApplication in your tests. this application does not 
install the SpringComponentInjector and so @SpringBean has no effect.

you should either give wickettester an instance of your actual application 
class, or create a mock one that installs springcomponentinjector.

-igor

On Tue, Nov 17, 2009 at 1:00 PM, Loritsch, Berin C.
berin.lorit...@gd-ais.com wrote:
  application.xml I initially had a setup that worked with both a 
 Web context and a JUnit context.  The problem was the amount of hand 
 coding and adjusting of the Spring context the approach needed.  I 
 finally got the Spring's transaction interceptor working with the 
 auto-wiring (the key is using an interface).  So now my problem is 
 that while I've saved myself the headache of making changes to a bunch 
 of files every time I add a new service, my unit tests are now failing.

 I've traced the failure to a specific class that is decorated with the 
 InjectorHolder--although I believe that is merely because it is the 
 first component that does any Hibernate requests.  I'll include the 
 stacktrace at the bottom of the message.

 I had to remove the line that specified that sessions would be thread 
 bound in Hibernate to take advantage of the Spring managed 
 transactions, and adding that configuration item back in makes no 
 difference for the tests.  I'm hoping I'm just missing something 
 simple, but all my Googling is turning up dead ends.  Any help out there?








 org.apache.wicket.WicketRuntimeException: Error attaching this 
 container for rendering: [MarkupContainer [Component id = content]]
        at
 org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContain
 er
 .java:1739)
        at
 org.apache.wicket.Component.onBeforeRender(Component.java:3854)
        at
 org.apache.wicket.Component.internalBeforeRender(Component.java:1061)
        at 
 org.apache.wicket.Component.beforeRender(Component.java:1095)
        at
 org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContain
 er
 .java:1727)
        at
 org.apache.wicket.Component.onBeforeRender(Component.java:3854)
        at org.apache.wicket.Page.onBeforeRender(Page.java:1501)
        at
 com.gdais.incidents.view.SiteTemplate.onBeforeRender(SiteTemplate.java
 :3
 3)
        at
 org.apache.wicket.Component.internalBeforeRender(Component.java:1061)
        at 
 org.apache.wicket.Component.beforeRender(Component.java:1095)
        at
 org.apache.wicket.Component.prepareForRender(Component.java:2223)
        at
 org.apache.wicket.Component.prepareForRender(Component.java:2260)
        at org.apache.wicket.Page.renderPage(Page.java:893)
        at
 org.apache.wicket.request.target.component.BookmarkablePageRequestTarg
 et
 .respond(BookmarkablePageRequestTarget.java:262)
        at
 org.apache.wicket.request.AbstractRequestCycleProcessor.respond(Abstra
 ct
 RequestCycleProcessor.java:105)
        at
 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.ja
 va
 :1258)
        at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
        at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428

Wicket Spring API docs?

2009-11-12 Thread Loritsch, Berin C.
Where can I find the wicket-spring module API docs?  It's not clear to
me from the website.


RE: Wicket Spring API docs?

2009-11-12 Thread Loritsch, Berin C.
I did, but that doesn't help me with knowing what classes are available.

For example, I had issues with using the WicketTester to test my Wicket/Spring 
based app.  I finally was able to create my own SpringWicketTester class that 
would load up the SpringWebApplicationContext that is needed for my app to run. 
 However, I had no way of telling if that was duplicate work.

If anyone is interested, I can donate the SpringWicketTester class.  It should 
belong to the wicket-spring subproject.

-Original Message-
From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] 
Sent: Thursday, November 12, 2009 3:16 PM
To: users@wicket.apache.org
Subject: Re: Wicket Spring API docs?

dont you use attach sources in your IDE?

-igor

On Thu, Nov 12, 2009 at 12:09 PM, Loritsch, Berin C.
berin.lorit...@gd-ais.com wrote:
 Where can I find the wicket-spring module API docs?  It's not clear to
 me from the website.


-
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: Wicket Spring API docs?

2009-11-12 Thread Loritsch, Berin C.
I hate to be a smart-butt, but if I'm not familiar with how things are named 
yet search is not very helpful.  Javadocs have their place, and are most useful 
when you are familiarizing yourself with an unfamiliar API.  I've now run the 
mvn target to get the javadocs, which is helpful.

Is there any interest in the SpringWicketTester class I put together?  I'm sure 
there is more than one person who has hit this problem, and all the online 
instructions I've found are for Wicket 1.3 or 1.2.

-Original Message-
From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] 
Sent: Thursday, November 12, 2009 3:42 PM
To: users@wicket.apache.org
Subject: Re: Wicket Spring API docs?

your IDE is much better at browsing and searching for classes then a
javadoc online :)

-igor

On Thu, Nov 12, 2009 at 12:38 PM, Loritsch, Berin C.
berin.lorit...@gd-ais.com wrote:
 I did, but that doesn't help me with knowing what classes are available.

 For example, I had issues with using the WicketTester to test my 
 Wicket/Spring based app.  I finally was able to create my own 
 SpringWicketTester class that would load up the SpringWebApplicationContext 
 that is needed for my app to run.  However, I had no way of telling if that 
 was duplicate work.

 If anyone is interested, I can donate the SpringWicketTester class.  It 
 should belong to the wicket-spring subproject.

 -Original Message-
 From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
 Sent: Thursday, November 12, 2009 3:16 PM
 To: users@wicket.apache.org
 Subject: Re: Wicket Spring API docs?

 dont you use attach sources in your IDE?

 -igor

 On Thu, Nov 12, 2009 at 12:09 PM, Loritsch, Berin C.
 berin.lorit...@gd-ais.com wrote:
 Where can I find the wicket-spring module API docs?  It's not clear to
 me from the website.


 -
 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: Wicket Spring API docs?

2009-11-12 Thread Loritsch, Berin C.
It's fairly small.  I can include it in an email.  If I throw it on the wiki 
where would be the best place?

-Original Message-
From: Pierre Goupil [mailto:goupilpie...@gmail.com] 
Sent: Thursday, November 12, 2009 4:02 PM
To: users@wicket.apache.org
Subject: Re: Wicket Spring API docs?

Hello,

I'd be glad to see it. Is there any place where it would fit? Maybe on the
Wicket wiki?

Regards,

Pierre


SpringWicketTester code (tested with Wicket 1.4 and spring-wicket)

2009-11-12 Thread Loritsch, Berin C.
import javax.servlet.ServletContext;

import org.apache.wicket.protocol.http.MockServletContext;
import org.apache.wicket.protocol.http.WebApplication;
import org.apache.wicket.util.tester.WicketTester;
import org.springframework.web.context.WebApplicationContext;
import org.springframework.web.context.support.XmlWebApplicationContext;

/**
 * Spring enabled WicketTester allows a user to test applications that
have
 * been wired using the SpringComponentInjector.  This subclass of the
 * WicketTester sets up the spring web context, which is normally set up
by
 * the org.springframework.web.context.ContextLoaderListener class.
 */
public class SpringWicketTester extends WicketTester {
/**
 * The Spring web application context
 */
private XmlWebApplicationContext spring;

/**
 * Instantiate the WicketTester with your application and a set
of URLs
 * to find the Spring XML configuration files.  Ex:
 * 
 * pre
 * new SpringWicketTester(new MyApp(),
classpath:application.xml,
 *
classpath:application-test.xml);
 * /pre
 * 
 * @param app   Your Wicket web application
 * @param springConfigURLs  The set of URLs for the
configuration files.
 */
public SpringWicketTester(WebApplication app, String...
springConfigURLs) {
this(app, null, springConfigURLs);
}


/**
 * Instantiate the WicketTester with your application and a set
of URLs
 * to find the Spring XML configuration files.  Ex:
 * 
 * pre
 * new SpringWicketTester(new MyApp(), myapp,
 *
classpath:application.xml,
 *
classpath:application-test.xml);
 * /pre
 * 
 * @param app   Your Wicket web application
 * @param context   The base url for the application
 * @param springConfigURLs  The set of URLs for the
configuration files.
 */
public SpringWicketTester(WebApplication app, String context,
String... springConfigURLs) {
super(app, context);

reconfigure(springConfigURLs);
}

/**
 * Reconfigure the tester with new spring configuration files.
This method
 * also calls the Spring coderefresh/code method to force
the files to
 * load.
 * 
 * @param springConfigURLs  The set of URLs for the
configuration files.
 */
public void reconfigure(String... springConfigURLs) {
getSpringContext().setConfigLocations(springConfigURLs);
getSpringContext().refresh();
}

/**
 * Create the new ServletContext that will be used with this
test session.
 * This method configures the spring web context to be included
in your
 * Servlet context.  It's the magic that makes everything happy.
 * 
 * @param path  the root context path for URLs
 * 
 * @return a configured ServletContext
 */
@Override
public ServletContext newServletContext(final String path) {
ServletContext context = new
MockServletContext(getApplication(), path);
getSpringContext().setServletContext(context);

context.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_
ATTRIBUTE, spring);
return context;
}

/**
 * Lazy loader for the creating the SpringContext.  Required to
work around
 * the initialization in the constructor.
 * 
 * @return the single web application context for this tester
 */
private XmlWebApplicationContext getSpringContext() {
if(null == spring) {
spring = new XmlWebApplicationContext();
}

return spring;
}
}