Ajax ModalWindow - passing value *in*?

2010-03-05 Thread VGJ
I'm using the ModalWindow for the first time (1.4) and am wondering if a
value can be passed into the modal window from the AjaxLink?

I've got a page full of anchor links and I'd like to jump to the anchors
inside of a modal page, depending on which link was clicked in the master
page.


301 Redirect

2010-01-05 Thread VGJ
Along with all of the SEO stuff I'm working on these days - I'm being asked
to use 301 redirects on the sites we're optimizing.  How would this be done
in with Wicket?  Are there alternatives, if not?

Thanks!


Re: 301 Redirect

2010-01-05 Thread VGJ
You'll have to forgive my ignorance - where in your app do you do this?

On Tue, Jan 5, 2010 at 8:55 AM, Martin Makundi 
martin.maku...@koodaripalvelut.com wrote:

 This is what we do with jetty:

try {
  // Force 302 redirect status code into 301 'permanent redirect'
  Field statusField =
 HttpStatus.class.getDeclaredField(__responseLine);
  statusField.setAccessible(true);
  Buffer[] responseLine = (Buffer[]) statusField.get(HttpStatus.class);
  byte[] bytes = responseLine[302].toString().replace(302,
 301).getBytes();
  responseLine[302] = new
 ByteArrayBuffer(bytes,0,bytes.length,Buffer.IMMUTABLE);
} catch (Exception e) {
  Utils.errorLog(getClass(), e);
}


 2010/1/5 VGJ zambi...@gmail.com:
  Along with all of the SEO stuff I'm working on these days - I'm being
 asked
  to use 301 redirects on the sites we're optimizing.  How would this be
 done
  in with Wicket?  Are there alternatives, if not?
 
  Thanks!
 

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




Re: 301 Redirect

2010-01-05 Thread VGJ
Is HttpStatus Jetty-specific?  I'm unable to resolve the class.  I'll see
if I can somehow piece this together on the Glassfish side.

Thanks.

On Tue, Jan 5, 2010 at 9:10 AM, Martin Makundi 
martin.maku...@koodaripalvelut.com wrote:

 In WicketApplication.init()

 2010/1/5 VGJ zambi...@gmail.com:
  You'll have to forgive my ignorance - where in your app do you do this?
 
  On Tue, Jan 5, 2010 at 8:55 AM, Martin Makundi 
  martin.maku...@koodaripalvelut.com wrote:
 
  This is what we do with jetty:
 
 try {
   // Force 302 redirect status code into 301 'permanent redirect'
   Field statusField =
  HttpStatus.class.getDeclaredField(__responseLine);
   statusField.setAccessible(true);
   Buffer[] responseLine = (Buffer[])
 statusField.get(HttpStatus.class);
   byte[] bytes = responseLine[302].toString().replace(302,
  301).getBytes();
   responseLine[302] = new
  ByteArrayBuffer(bytes,0,bytes.length,Buffer.IMMUTABLE);
 } catch (Exception e) {
   Utils.errorLog(getClass(), e);
 }
 
 
  2010/1/5 VGJ zambi...@gmail.com:
   Along with all of the SEO stuff I'm working on these days - I'm being
  asked
   to use 301 redirects on the sites we're optimizing.  How would this be
  done
   in with Wicket?  Are there alternatives, if not?
  
   Thanks!
  
 
  -
  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: 301 Redirect

2010-01-05 Thread VGJ
Hmm...is there a better way?  I don't want to do anything
container/app-server specific, honestly.

I found this:

http://old.nabble.com/302-vs.-301-Redirect-ts14156515.html#a14156515

Is there still no way to perform a 301 redirect?  Any alternatives?

On Tue, Jan 5, 2010 at 9:35 AM, Martin Makundi 
martin.maku...@koodaripalvelut.com wrote:

 It's jetty specific. You have to look at sources if this resolution
 works for you.

 **
 Martin

 2010/1/5 VGJ zambi...@gmail.com:
  Is HttpStatus Jetty-specific?  I'm unable to resolve the class.  I'll
 see
  if I can somehow piece this together on the Glassfish side.
 
  Thanks.
 
  On Tue, Jan 5, 2010 at 9:10 AM, Martin Makundi 
  martin.maku...@koodaripalvelut.com wrote:
 
  In WicketApplication.init()
 
  2010/1/5 VGJ zambi...@gmail.com:
   You'll have to forgive my ignorance - where in your app do you do
 this?
  
   On Tue, Jan 5, 2010 at 8:55 AM, Martin Makundi 
   martin.maku...@koodaripalvelut.com wrote:
  
   This is what we do with jetty:
  
  try {
// Force 302 redirect status code into 301 'permanent redirect'
Field statusField =
   HttpStatus.class.getDeclaredField(__responseLine);
statusField.setAccessible(true);
Buffer[] responseLine = (Buffer[])
  statusField.get(HttpStatus.class);
byte[] bytes = responseLine[302].toString().replace(302,
   301).getBytes();
responseLine[302] = new
   ByteArrayBuffer(bytes,0,bytes.length,Buffer.IMMUTABLE);
  } catch (Exception e) {
Utils.errorLog(getClass(), e);
  }
  
  
   2010/1/5 VGJ zambi...@gmail.com:
Along with all of the SEO stuff I'm working on these days - I'm
 being
   asked
to use 301 redirects on the sites we're optimizing.  How would this
 be
   done
in with Wicket?  Are there alternatives, if not?
   
Thanks!
   
  
   -
   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: @RequireHttps - forms misbehaving

2009-12-22 Thread VGJ
My redirect method isn't overriding anything, it's just there to provide a
shortcut to an external redirect, should I need it.  Could it still be doing
some damage, somehow?

I was using bookmarkable pages just before switching to Hybrids, at the same
time I started using @RequireHttps, so they did work just fine.

On Mon, Dec 21, 2009 at 4:51 PM, Jason Lea ja...@kumachan.net.nz wrote:

 yay!

 But it is odd if setRedirect(true) didn't work when using a page instance.
  I wonder if the there is an issue with HybridUrlCodingStrategy and
 RequireHttps... can you mount the page you redirect to using a simple
 bookmarkable page and see if it works?

 I also noticed you have a method on your BasePage class called
 redirect(url) that disables wicket redirect... does that get called when you
 use setRedirect(true)?



 VGJ wrote:

 Jason...excellent!  setResponsePage(UserAccount.class) did the trick!
 Thanks!  Using setRedirect(true) didn't have any effect however.  I had to
 redirect to the page class rather than a new instance of it.

 This works for me right now...but what happens when I'd like to pass
 parameters into the constructor of the page I'm redirecting to?

 -v


 --
 Jason Lea



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




Re: @RequireHttps - forms misbehaving

2009-12-21 Thread VGJ
I see, I guess I misunderstood you.  I wasn't able to reproduce it in a
separate test application, however.  It has to be encountering something in
this particular application that is causing a problem.  I just can't figure
out what that might be, exactly.

I would submit the small test case I made but it works just fine.  I can't
submit the application with the issue I've described, it's company code.

-v

On Mon, Dec 21, 2009 at 12:45 PM, b...@actrix.gen.nz wrote:

 VGJ,
 You might have discovered a limitation of the system or a bug. As I
 wrote, I would recommend you make a testcase with all distracting
 detail removed and submit it as a jira issue, then post a link to the
 the issue here.

 I understand your frustration, but I think the above would be the best
 investment of your own efforts.

 Regards,

 Bernard.

 On Mon, 21 Dec 2009 11:13:49 -0700, you wrote:

 Well, I'm still unable to spot anything strange.  No matter what page I
 annotate, it doesn't switch to https until the form is submitted.  It then
 goes to https (as if it's redirecting to itself?) and triggers the
 validation on the page, even if the correct fields are filled in.  No
 matter
 what page I annotate on this site, it happens the same way.
 
 Here's an example from this app:
 
 The login or create a new account page:
 
 @RequireHttps
 public class UserAccount extends BasePage
 {
 public UserAccount()
 {
 //get user from session
 User user = ((UserSession)getSession()).getUser();
 
 //pass go, collect $200
 if (user != null)
 throw new RestartResponseException(new ContactInfo());
 
 add(new FeedbackPanel(feedbackPanel));
 
 //get cart in session
 ShoppingCartLocal cart = ((UserSession)getSession()).getCart();
 
 //entities
 Order order = cart.getOrder();
 Customer customer = order.getCustomer();
 String email = (order != null  customer != null) ?
 customer.getEmail()
 : ;
 
 //form model (entity)
 if (user == null) user = new User();
 
 //if email exists, pre-populate form
 if (email != null  !email.equals())
 user.setUsername(email);
 
 final Form returnUserForm = new Form(retUserAccountForm, new
 CompoundPropertyModel(user));
 final Form newUserForm = new Form(newUserAccountForm, new
 CompoundPropertyModel(user));
 
 //add form components
 returnUserForm.add(new TextField(username)
 .setRequired(true)
 .add(EmailAddressPatternValidator.getInstance()));
 returnUserForm.add(new PasswordTextField(password));
 
 returnUserForm.add(new Button(userAcctButton)
 {
   public void onSubmit()
   {
 ShoppingCartLocal  cart = null;
 
 try
 {
   //save form values, redirect
   User user = (User)returnUserForm.getModelObject();
 
   //get cart from session
   cart = ((UserSession)getSession()).getCart();
 
   //create order in session
   cart = CartProxy.authUserAccount(cart, user);
 
   //set cart back to session  log user in
   ((UserSession)getSession()).setCart(cart);
   ((UserSession)getSession()).setUser(
   cart.getOrder().getCustomer().getUser());
 
   //redirect
   setResponsePage(new ContactInfo());
 }
 catch (Exception exp)
 {
   info(exp.getMessage());
   LogProxy.saveEntry(exp);
 }
   }
 });
 
 returnUserForm.add(new Link(forgotPasswordLink)
 {
   public void onClick()
   {
 setResponsePage(new ForgotPassword());
   }
 });
 
 
 //add form components
 newUserForm.add(new TextField(username)
 .setRequired(true)
 .add(EmailAddressPatternValidator.getInstance()));
 
 newUserForm.add(new Button(userAcctButton)
 {
   public void onSubmit()
   {
 ShoppingCartLocal  cart = null;
 
 try
 {
   //save form values, redirect
   User user = (User)newUserForm.getModelObject();
 
   //get cart from session
   cart = ((UserSession)getSession()).getCart();
 
   //create order in session
   cart = CartProxy.createUserAccount(cart, user);
 
   //set cart back to session  log user in
   ((UserSession)getSession()).setCart(cart);
   ((UserSession)getSession()).setUser(
   cart.getOrder().getCustomer().getUser());
 
   //redirect
   setResponsePage(new ContactInfo());
 }
 catch (Exception exp)
 {
   info(exp.getMessage());
   LogProxy.saveEntry(exp);
 }
   }
 });
 
 //add forms
 add(returnUserForm);
 add(newUserForm);
 }
 }
 
 ...the BasePage class:
 
 public abstract class BasePage extends WebPage
 {
   private String pageTitle = My page title!;
 
   public BasePage()
   {
 //add page title
 add(new Label(title, new

Re: @RequireHttps - forms misbehaving

2009-12-21 Thread VGJ
Jason...excellent!  setResponsePage(UserAccount.class) did the trick!
Thanks!  Using setRedirect(true) didn't have any effect however.  I had to
redirect to the page class rather than a new instance of it.

This works for me right now...but what happens when I'd like to pass
parameters into the constructor of the page I'm redirecting to?

-v

On Mon, Dec 21, 2009 at 1:52 PM, Jason Lea ja...@kumachan.net.nz wrote:

 Here are a couple of things to try...

 @RequireHttps checks when the request comes into wicket and issues a
 redirect if it is on the wrong protocol.

 I wonder if it is because you are using setResponsePage(new ContactInfo());
 without a redirect, so the @RequireHttps annotation is not checked but the
 page still renders.
 When you do actually submit the form on the page, wicket can then process
 the @RequireHttps annotation and redirects to the page and maybe loses the
 posted form values?

 If this was happening you would probably see url has not changed from http
 to https.

 Try adding setRedirect(true) or better yet use the
 setResponsePage(ContactInfo.class); method instead which will do a redirect
 for you.

 If the problem is still occuring, try the HttpFox plugin and look at the
 requests and redirects that occur and see if it does issue redirects to
 change to https somewhere.  The other place redirects occur is with your use
 of HybridUrlCodingStrategy... try a different strategy to see if that causes
 the problem to go away.

 If there are still problems, you could check the session id to make sure it
 is not being lost when switching from http-https  (HttpFox is good for
 seeing the cookies, and see if the jsessionid cookie changed or not)


 VGJ wrote:

 I see, I guess I misunderstood you.  I wasn't able to reproduce it in a
 separate test application, however.  It has to be encountering something
 in
 this particular application that is causing a problem.  I just can't
 figure
 out what that might be, exactly.

 I would submit the small test case I made but it works just fine.  I can't
 submit the application with the issue I've described, it's company code.

 -v



 --
 Jason Lea




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




Re: Pretty URLs and sessions

2009-12-18 Thread VGJ
Alex, this was a great help, thank you!

On Thu, Dec 17, 2009 at 3:23 PM, Alex Objelean alex_objel...@yahoo.comwrote:


 Though I didn't use it, there is HttpsRequestCycleProcessor (you should add
 it in your Application) and @RequireHttps annotation (for each WebPage
 which
 must be accessed through SSL) which should make this work.

 Alex


 V. Jenks wrote:
 
  Yes I know, I do this most of the time.  However, I'm redirecting from
  http
  to https.  When I wrote this app, this was what everyone was
 recommending.
  Is there another way?
 
  On Thu, Dec 17, 2009 at 2:45 PM, Alex Objelean
  alex_objel...@yahoo.comwrote:
 
 
  You shouldn't have a code like this:
getRequestCycle().setRedirect(false);
 
  getRequestCycle().setRequestTarget(EmptyRequestTarget.getInstance());
   getResponse().redirect(
  https://mysite/app/?wicket:bookmarkablePage=:com.myapp.UserAccount;);
 
  A more 'wicket way' of doing thins is this:
 
  setResponsePage(UserAccount.class);
 
  That means that a bookmarkable page will be created (a new instance of
  the
  page will be instantiated).
  You can also do something like this:
 
  setResponsePage(new UserAccount(account));
 
  Or you could try to make this page as stateless as possible by passing
  account id or other parameters to the page that depends..
 
  Alex
 
 
  V. Jenks wrote:
  
   Hit a snag!  At the cart page (going into the login page), I redirect
  to
   https like so:
  
 getRequestCycle().setRedirect(false);
  
   getRequestCycle().setRequestTarget(EmptyRequestTarget.getInstance());
 getResponse().redirect(https://mysite/app/account;);
  
   user-account being mapped like so in the app class:
  
   mount(new HybridUrlCodingStrategy(/account, UserAccount.class));
  
   ...gets me this exception:
  
   org.apache.wicket.WicketRuntimeException: Can't instantiate page using
   constructor public com.agribeef.abcommerce.ui.UserAccount()
   at
  
 
 org.apache.wicket.session.DefaultPageFactory.createPage(DefaultPageFactory.java:212)
   at
  
 
 org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:57)
   at
  
 
 org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:299)
   at
  
 
 org.apache.wicket.request.target.coding.HybridUrlCodingStrategy$HybridBookmarkablePageRequestTarget.newPage(HybridUrlCodingStrategy.java:887)
   at
  
 
 org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:321)
   at
  
 
 org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:234)
   at
  
 
 org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
   at
  
 
 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
   ...
   Caused by: java.lang.reflect.InvocationTargetException
   at
  sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
   Method)
   at
  
 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
   at
  
 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
   at
  java.lang.reflect.Constructor.newInstance(Constructor.java:513)
   at
  
 
 org.apache.wicket.session.DefaultPageFactory.createPage(DefaultPageFactory.java:192)
   ... 40 more
   Caused by: java.lang.NullPointerException
   at com.myapp.UserAccount.init(UserAccount.java:44)
   ... 45 more
  
   ...which is of course, where I try to reference the stateful bean
   (ShoppingCartBean) that I'm passing around.
  
   Prior to now, I just did this:
  
 getRequestCycle().setRedirect(false);
  
   getRequestCycle().setRequestTarget(EmptyRequestTarget.getInstance());
 getResponse().redirect(
   https://mysite/app/?wicket:bookmarkablePage=:com.myapp.UserAccount;);
  
   I could stick with that I guess, since it's trackable.  It would have
  been
   nice to use the Hybrid approach consistently, though.
  
   -v
  
  
   On Thu, Dec 17, 2009 at 2:12 PM, Alex Objelean
   alex_objel...@yahoo.comwrote:
  
  
   Also, it could be useful to check this out:
  
  
 
 http://day-to-day-stuff.blogspot.com/2008/10/wicket-extreme-consistent-urls.html
  
   Alex
  
  
   V. Jenks wrote:
   
Excellent, excellent!  This is exactly what I was after!  That
   is...unless
this SEO can find another monkey wrench to throw in it.  But...it
  looks
like
it's exactly what I need.  Thanks!
   
Alex R. - good point on tracking info internally.  I think it'd be
  very
useful but I'm dealing w/ the marketing dept.  They're so wowed by
  GA,
   I
doubt there's any turning back.
   
Thanks guys.
   
On Thu, Dec 17, 2009 at 12:08 PM, 

@RequireHttps - forms misbehaving

2009-12-18 Thread VGJ
I'm now using @RequireHttps to switch to https on certain pages but it's not
quite working right.

In our storefront app, I'm switching to https at the point in the checkout
process where you view your cart, and then proceed to a page to either login
or create an account.  When I submit my username and password, the
validation fires as if I entered nothing into the form.  Enter it a second
time and it works - the validation doesn't trigger.  Everything was entered
correctly the first time around...so it's as if the form is being posted on
its own, when the page loads?  Every page with @RequireHttps that has a
form, does this.

What do I need to do to change to accommodate validation under @RequireHttps
pages?

Currently you just see a lot of forms w/ fields like this:

add(new TextField(username).setRequired(true));

...with a pretty common feedback panel:

div id=feedbackPanel
  span wicket:id=feedbackPanel class=warning /
/div

Thanks!

-v


Re: @RequireHttps - forms misbehaving

2009-12-18 Thread VGJ
I'll create one and post it, if I can.

-v

On Fri, Dec 18, 2009 at 9:21 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 can you recreate in a quickstart?

 -igor

 On Fri, Dec 18, 2009 at 7:56 AM, VGJ zambi...@gmail.com wrote:
  I'm now using @RequireHttps to switch to https on certain pages but it's
 not
  quite working right.
 
  In our storefront app, I'm switching to https at the point in the
 checkout
  process where you view your cart, and then proceed to a page to either
 login
  or create an account.  When I submit my username and password, the
  validation fires as if I entered nothing into the form.  Enter it a
 second
  time and it works - the validation doesn't trigger.  Everything was
 entered
  correctly the first time around...so it's as if the form is being posted
 on
  its own, when the page loads?  Every page with @RequireHttps that has a
  form, does this.
 
  What do I need to do to change to accommodate validation under
 @RequireHttps
  pages?
 
  Currently you just see a lot of forms w/ fields like this:
 
  add(new TextField(username).setRequired(true));
 
  ...with a pretty common feedback panel:
 
 div id=feedbackPanel
   span wicket:id=feedbackPanel class=warning /
 /div
 
  Thanks!
 
  -v
 

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




Re: @RequireHttps - forms misbehaving

2009-12-18 Thread VGJ
I was unable to re-create it in a simple web app w/ a few pages.  However,
no matter where I use it in my storefront app, it happens.

It's very strange because it starts a page late.  I put the annotation on
the User Account page, yet it doesn't switch to https until I reach the
*following* page in the checkout process.  I just stuck it on the general
Login page that exists outside of the checkout process...and when I click
the link from the home page to go to the Login page using
setResponsePage(new Login()), it doesn't switch to https.  Instead, I enter
the user/pass and submit...THEN it goes to https, then I'm able to re-enter
and login.

Very strange behavior...I have no idea what might be causing it.

I use various Panels throughout the side, would that have any influence on
it?  For example, the link in the header to go to the Login page is inside
of a straightforward Panel.  The entire site uses markup inheritance as
well.

On Fri, Dec 18, 2009 at 9:29 AM, VGJ zambi...@gmail.com wrote:

 I'll create one and post it, if I can.

 -v


 On Fri, Dec 18, 2009 at 9:21 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 can you recreate in a quickstart?

 -igor

 On Fri, Dec 18, 2009 at 7:56 AM, VGJ zambi...@gmail.com wrote:
  I'm now using @RequireHttps to switch to https on certain pages but it's
 not
  quite working right.
 
  In our storefront app, I'm switching to https at the point in the
 checkout
  process where you view your cart, and then proceed to a page to either
 login
  or create an account.  When I submit my username and password, the
  validation fires as if I entered nothing into the form.  Enter it a
 second
  time and it works - the validation doesn't trigger.  Everything was
 entered
  correctly the first time around...so it's as if the form is being posted
 on
  its own, when the page loads?  Every page with @RequireHttps that has a
  form, does this.
 
  What do I need to do to change to accommodate validation under
 @RequireHttps
  pages?
 
  Currently you just see a lot of forms w/ fields like this:
 
  add(new TextField(username).setRequired(true));
 
  ...with a pretty common feedback panel:
 
 div id=feedbackPanel
   span wicket:id=feedbackPanel class=warning /
 /div
 
  Thanks!
 
  -v
 

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





Re: Pretty URLs and sessions

2009-12-17 Thread VGJ
Thanks Alex.

I just had another meeting w/ the SEO guy today and the idea is to track
orders moving through our storefront in order go gauge sales based on the
SEO strategy.  In other words, where did our customers come from (Google
search?), what did they buy, and did they make it all the way through the
checkout process.  We need to be able to track pages in Google Analytics.

If we could append/prepend some sort of value to the pages, while keeping
the dynamic Wicket page version parameter info in there, it would be
sufficient.  In Analytics, the Wicket portion of the URL can be removed and
the rest would be used to identify traffic moving through the site.

Is HybridUrlCodingStrategy the way to go, with this in mind?  Where are some
good examples as to how to implement it and do what I'm describing?

Thanks again!

-v

On Tue, Dec 1, 2009 at 6:04 AM, Alex Objelean alex_objel...@yahoo.comwrote:


 You can mount your page with HybridUrlCodingStrategy. This way, even
 session
 relative url's will be SEO friendly.

 But you must be aware of one thing, it makes sense to make SEO only
 bookmarkable pages (stateless pages). It is meaningless to make SEO aware
 session relative pages, because these will be shown as expired when
 somebody
 else will use these links.

 Regards,
 Alex Objelean


 V. Jenks wrote:
 
  I'm working on some changes for our storefront (Wicket 1.4, Java EE 5,
  Glassfish 2.1) based on some recommendations made to us by an SEO
  consultant.  One of them is re-writing some of the URLs so as to have
 them
  indexed by Google, etc.
 
  My concern is the Wicket WebSession that I use to pass around an instance
  of
  a stateful session bean.  If I redirect to a mounted bookmarkable page
  when
  going through pages in the checkout process, vs redirecting to a new
  instances of the page class, will there be any adverse effects on the
  session?  Will customers experience a problem with their shopping cart
  sessions?
 
  Thanks!
 
 

 --
 View this message in context:
 http://old.nabble.com/%22Pretty%22-URLs-and-sessions-tp26581608p26591380.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




Re: Pretty URLs and sessions

2009-12-17 Thread VGJ
Hit a snag!  At the cart page (going into the login page), I redirect to
https like so:

  getRequestCycle().setRedirect(false);
  getRequestCycle().setRequestTarget(EmptyRequestTarget.getInstance());
  getResponse().redirect(https://mysite/app/account;);

user-account being mapped like so in the app class:

mount(new HybridUrlCodingStrategy(/account, UserAccount.class));

...gets me this exception:

org.apache.wicket.WicketRuntimeException: Can't instantiate page using
constructor public com.agribeef.abcommerce.ui.UserAccount()
at
org.apache.wicket.session.DefaultPageFactory.createPage(DefaultPageFactory.java:212)
at
org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:57)
at
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:299)
at
org.apache.wicket.request.target.coding.HybridUrlCodingStrategy$HybridBookmarkablePageRequestTarget.newPage(HybridUrlCodingStrategy.java:887)
at
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:321)
at
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:234)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
...
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.apache.wicket.session.DefaultPageFactory.createPage(DefaultPageFactory.java:192)
... 40 more
Caused by: java.lang.NullPointerException
at com.myapp.UserAccount.init(UserAccount.java:44)
... 45 more

...which is of course, where I try to reference the stateful bean
(ShoppingCartBean) that I'm passing around.

Prior to now, I just did this:

  getRequestCycle().setRedirect(false);
  getRequestCycle().setRequestTarget(EmptyRequestTarget.getInstance());
  getResponse().redirect(
https://mysite/app/?wicket:bookmarkablePage=:com.myapp.UserAccount;);

I could stick with that I guess, since it's trackable.  It would have been
nice to use the Hybrid approach consistently, though.

-v


On Thu, Dec 17, 2009 at 2:12 PM, Alex Objelean alex_objel...@yahoo.comwrote:


 Also, it could be useful to check this out:

 http://day-to-day-stuff.blogspot.com/2008/10/wicket-extreme-consistent-urls.html

 Alex


 V. Jenks wrote:
 
  Excellent, excellent!  This is exactly what I was after!  That
 is...unless
  this SEO can find another monkey wrench to throw in it.  But...it looks
  like
  it's exactly what I need.  Thanks!
 
  Alex R. - good point on tracking info internally.  I think it'd be very
  useful but I'm dealing w/ the marketing dept.  They're so wowed by GA, I
  doubt there's any turning back.
 
  Thanks guys.
 
  On Thu, Dec 17, 2009 at 12:08 PM, Alex Objelean
  alex_objel...@yahoo.comwrote:
 
 
  There are two possibilities:
  1) In your application class add the following:
  mount(new HybridUrlCodingStrategy(/checkout, CheckoutPage.class));
 
  2) If you have wicket-stuff annotation dependency
  (
 
 http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-annotation
  )
  you can annotate your page class with:
 
  @MountPath(path=/checkout)
  @MountHybrid
  public class CheckoutPage extends WebPage {}
 
  Alex
 
 
 
  V. Jenks wrote:
  
   Thanks Alex.
  
   I just had another meeting w/ the SEO guy today and the idea is to
  track
   orders moving through our storefront in order go gauge sales based on
  the
   SEO strategy.  In other words, where did our customers come from
  (Google
   search?), what did they buy, and did they make it all the way through
  the
   checkout process.  We need to be able to track pages in Google
  Analytics.
  
   If we could append/prepend some sort of value to the pages, while
  keeping
   the dynamic Wicket page version parameter info in there, it would be
   sufficient.  In Analytics, the Wicket portion of the URL can be
 removed
   and
   the rest would be used to identify traffic moving through the site.
  
   Is HybridUrlCodingStrategy the way to go, with this in mind?  Where
 are
   some
   good examples as to how to implement it and do what I'm describing?
  
   Thanks again!
  
   -v
  
   On Tue, Dec 1, 2009 at 6:04 AM, Alex Objelean
   alex_objel...@yahoo.comwrote:
  
  
   You can mount your page with HybridUrlCodingStrategy. This way, even
   session
   relative url's will be SEO friendly.
 

Re: Pretty URLs and sessions

2009-12-17 Thread VGJ
Yes I know, I do this most of the time.  However, I'm redirecting from http
to https.  When I wrote this app, this was what everyone was recommending.
Is there another way?

On Thu, Dec 17, 2009 at 2:45 PM, Alex Objelean alex_objel...@yahoo.comwrote:


 You shouldn't have a code like this:
   getRequestCycle().setRedirect(false);
  getRequestCycle().setRequestTarget(EmptyRequestTarget.getInstance());
  getResponse().redirect(
 https://mysite/app/?wicket:bookmarkablePage=:com.myapp.UserAccount;);

 A more 'wicket way' of doing thins is this:

 setResponsePage(UserAccount.class);

 That means that a bookmarkable page will be created (a new instance of the
 page will be instantiated).
 You can also do something like this:

 setResponsePage(new UserAccount(account));

 Or you could try to make this page as stateless as possible by passing
 account id or other parameters to the page that depends..

 Alex


 V. Jenks wrote:
 
  Hit a snag!  At the cart page (going into the login page), I redirect to
  https like so:
 
getRequestCycle().setRedirect(false);
 
  getRequestCycle().setRequestTarget(EmptyRequestTarget.getInstance());
getResponse().redirect(https://mysite/app/account;);
 
  user-account being mapped like so in the app class:
 
  mount(new HybridUrlCodingStrategy(/account, UserAccount.class));
 
  ...gets me this exception:
 
  org.apache.wicket.WicketRuntimeException: Can't instantiate page using
  constructor public com.agribeef.abcommerce.ui.UserAccount()
  at
 
 org.apache.wicket.session.DefaultPageFactory.createPage(DefaultPageFactory.java:212)
  at
 
 org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:57)
  at
 
 org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:299)
  at
 
 org.apache.wicket.request.target.coding.HybridUrlCodingStrategy$HybridBookmarkablePageRequestTarget.newPage(HybridUrlCodingStrategy.java:887)
  at
 
 org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:321)
  at
 
 org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:234)
  at
 
 org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
  at
 
 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
  ...
  Caused by: java.lang.reflect.InvocationTargetException
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
  Method)
  at
 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
  at
 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
  at
 java.lang.reflect.Constructor.newInstance(Constructor.java:513)
  at
 
 org.apache.wicket.session.DefaultPageFactory.createPage(DefaultPageFactory.java:192)
  ... 40 more
  Caused by: java.lang.NullPointerException
  at com.myapp.UserAccount.init(UserAccount.java:44)
  ... 45 more
 
  ...which is of course, where I try to reference the stateful bean
  (ShoppingCartBean) that I'm passing around.
 
  Prior to now, I just did this:
 
getRequestCycle().setRedirect(false);
 
  getRequestCycle().setRequestTarget(EmptyRequestTarget.getInstance());
getResponse().redirect(
  https://mysite/app/?wicket:bookmarkablePage=:com.myapp.UserAccount;);
 
  I could stick with that I guess, since it's trackable.  It would have
 been
  nice to use the Hybrid approach consistently, though.
 
  -v
 
 
  On Thu, Dec 17, 2009 at 2:12 PM, Alex Objelean
  alex_objel...@yahoo.comwrote:
 
 
  Also, it could be useful to check this out:
 
 
 http://day-to-day-stuff.blogspot.com/2008/10/wicket-extreme-consistent-urls.html
 
  Alex
 
 
  V. Jenks wrote:
  
   Excellent, excellent!  This is exactly what I was after!  That
  is...unless
   this SEO can find another monkey wrench to throw in it.  But...it
 looks
   like
   it's exactly what I need.  Thanks!
  
   Alex R. - good point on tracking info internally.  I think it'd be
 very
   useful but I'm dealing w/ the marketing dept.  They're so wowed by GA,
  I
   doubt there's any turning back.
  
   Thanks guys.
  
   On Thu, Dec 17, 2009 at 12:08 PM, Alex Objelean
   alex_objel...@yahoo.comwrote:
  
  
   There are two possibilities:
   1) In your application class add the following:
   mount(new HybridUrlCodingStrategy(/checkout, CheckoutPage.class));
  
   2) If you have wicket-stuff annotation dependency
   (
  
 
 http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-annotation
   )
   you can annotate your page class with:
  
   @MountPath(path=/checkout)
   @MountHybrid
   public class CheckoutPage extends WebPage {}
  
   Alex
  
  
  
   V. Jenks 

Pretty URLs and sessions

2009-11-30 Thread VGJ
I'm working on some changes for our storefront (Wicket 1.4, Java EE 5,
Glassfish 2.1) based on some recommendations made to us by an SEO
consultant.  One of them is re-writing some of the URLs so as to have them
indexed by Google, etc.

My concern is the Wicket WebSession that I use to pass around an instance of
a stateful session bean.  If I redirect to a mounted bookmarkable page when
going through pages in the checkout process, vs redirecting to a new
instances of the page class, will there be any adverse effects on the
session?  Will customers experience a problem with their shopping cart
sessions?

Thanks!


Re: Wicket 1.4 + GF v2.1 causing WicketNotSerializableException

2009-11-19 Thread VGJ
I'm not injecting it directly.  I'm using a proxy class to get a reference
to the stateless bean's interface like so:

public class CartProxy
{
  private static ShoppingCartLocal lookupCartInterface()
  {
ShoppingCartLocal cart = null;

try
{
  InitialContext ctx = new InitialContext();
  cart =
(ShoppingCartLocal)ctx.lookup(java:comp/env/ShoppingCartBean);
}
catch (NamingException exp)
{
  LogProxy.saveEntry(exp);
}

return cart;
  }
}

The reference in web.xml makes this possible:

  ejb-local-ref
ejb-ref-nameShoppingCartBean/ejb-ref-name
ejb-ref-typeSession/ejb-ref-type
localcom.myapp.session.ShoppingCartLocal/local
ejb-linkMyProjectEJB.jar#ShoppingCartBean/ejb-link
  /ejb-local-ref

Is this not supposed to work?  It's been in production for over 3 yrs...so I
hope it does!  :)

The entire app is built this way and this one page is the only one throwing
this exception.  It works, it doesn't stop the show or affect anything
negatively, so far as I can tell.  I would just like to get rid of it and
figure out what it is.

Thanks again,

-v

On Wed, Nov 18, 2009 at 11:49 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 wicket stuff contains a wicket-jee module which supports injecting ejb
 beans into wicket components the same way that wicket-spring injects
 wicket beans.

 -igor

 On Wed, Nov 18, 2009 at 10:37 PM, Pieter Degraeuwe
 pieter.degrae...@systemworks.be wrote:
  Your cart has a reference to the sessionBean ShopingCart. This is not
  allowed, however. The IOC incjectionsupport makes this possible by
 wrapping
  this EJB reference with a serializable proxy.
 
  I only have expecience with wicket-spring end it works great. (In your
 case,
  define your ejb reference in spring and inject it via wicket-spring
 support
  in your page.
  problem solved!
 
  Pieter
 
  On Wed, Nov 18, 2009 at 10:50 PM, VGJ zambi...@gmail.com wrote:
 
  I'm completely at wits end here and I hope someone can point out what's
  wrong.
 
  I've got an e-commerce application that is simply moving between two
 pages
  using setRedirectPage() when going from a product detail page to the
  shopping cart page.  There isn't anything remarkable about either of
 these
  two pages, they're basically like any other in the app.  However, when
 the
  cart page loads, I get the exception at the bottom of this message.
 
  I've tried implementing Serializable on the Cart() page class but it
 makes
  no difference.  It points out
  com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate as the
  culprit.  I use a stateful session bean (ShoppingCart) which is passed
  around the app as part of the session (custom WebSession-derived class)
 
  This is the only page this occurs on.  There are several other steps in
 the
  cart's checkout process that look exactly like this one and the
 exception
  doesn't happen on any of the others
 
  Any ideas?
 
  Exception:
 
  25717 [httpSSLWorkerThread-8080-1] ERROR
  org.apache.wicket.util.lang.Objects
  - Error serializing object class com.myapp.ui.Cart [object=[Page class =
  com.myapp.ui.Cart, id = 3, version = 0]]
 
 
 org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
  Unable to serialize class:
  com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate
  Field hierarchy is:
   3 [class=com.myapp.ui.Cart, path=3]
 private java.lang.Object org.apache.wicket.MarkupContainer.children
  [class=[Ljava.lang.Object;]
   private
  org.apache.wicket.markup.html.ContainerWithAssociatedMarkupHelper
 
 
 org.apache.wicket.markup.html.WebMarkupContainerWithAssociatedMarkup.markupHelper[6]
  [class=org.apache.wicket.markup.html.form.Form, path=3:cartForm]
 private java.lang.Object
 org.apache.wicket.MarkupContainer.children
  [class=[Ljava.lang.Object;]
   private java.lang.Object
  org.apache.wicket.MarkupContainer.children[0]
 [class=com.myapp.ui.Cart$1,
  path=3:cartForm:orderLinesView]
 final com.myapp.session.ShoppingCartLocal
  com.myapp.ui.Cart$1.val$cart [class=$Proxy92]
   protected java.lang.reflect.InvocationHandler
  java.lang.reflect.Proxy.h
  [class=com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate]
  - field that is not serializable
 at
 
 
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:346)
 at
 
 
 org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:615)
 at
 
 
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:538)
 at
 
 
 org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:615)
 at
 
 
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:538)
 at
 
 
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:392)
 at
 
 
 org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:615

Re: Wicket 1.4 + GF v2.1 causing WicketNotSerializableException

2009-11-19 Thread VGJ
One would think...however I tried it and it makes no difference.  None of my
proxy classes implement Serializable and this exception occurs nowhere else,
also.

Just to be certain, I just went through and implemented it on *all* of my
proxy classes in this app.  No change.


On Thu, Nov 19, 2009 at 9:30 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 your CartProxy does not implement serialiazable so it cannot be
 serialized...

 -igor

 On Thu, Nov 19, 2009 at 7:30 AM, VGJ zambi...@gmail.com wrote:
  I'm not injecting it directly.  I'm using a proxy class to get a
 reference
  to the stateless bean's interface like so:
 
  public class CartProxy
  {
   private static ShoppingCartLocal lookupCartInterface()
   {
 ShoppingCartLocal cart = null;
 
 try
 {
   InitialContext ctx = new InitialContext();
   cart =
  (ShoppingCartLocal)ctx.lookup(java:comp/env/ShoppingCartBean);
 }
 catch (NamingException exp)
 {
   LogProxy.saveEntry(exp);
 }
 
 return cart;
   }
  }
 
  The reference in web.xml makes this possible:
 
   ejb-local-ref
 ejb-ref-nameShoppingCartBean/ejb-ref-name
 ejb-ref-typeSession/ejb-ref-type
 localcom.myapp.session.ShoppingCartLocal/local
 ejb-linkMyProjectEJB.jar#ShoppingCartBean/ejb-link
   /ejb-local-ref
 
  Is this not supposed to work?  It's been in production for over 3
 yrs...so I
  hope it does!  :)
 
  The entire app is built this way and this one page is the only one
 throwing
  this exception.  It works, it doesn't stop the show or affect anything
  negatively, so far as I can tell.  I would just like to get rid of it and
  figure out what it is.
 
  Thanks again,
 
  -v
 
  On Wed, Nov 18, 2009 at 11:49 PM, Igor Vaynberg igor.vaynb...@gmail.com
 wrote:
 
  wicket stuff contains a wicket-jee module which supports injecting ejb
  beans into wicket components the same way that wicket-spring injects
  wicket beans.
 
  -igor
 
  On Wed, Nov 18, 2009 at 10:37 PM, Pieter Degraeuwe
  pieter.degrae...@systemworks.be wrote:
   Your cart has a reference to the sessionBean ShopingCart. This is not
   allowed, however. The IOC incjectionsupport makes this possible by
  wrapping
   this EJB reference with a serializable proxy.
  
   I only have expecience with wicket-spring end it works great. (In your
  case,
   define your ejb reference in spring and inject it via wicket-spring
  support
   in your page.
   problem solved!
  
   Pieter
  
   On Wed, Nov 18, 2009 at 10:50 PM, VGJ zambi...@gmail.com wrote:
  
   I'm completely at wits end here and I hope someone can point out
 what's
   wrong.
  
   I've got an e-commerce application that is simply moving between two
  pages
   using setRedirectPage() when going from a product detail page to the
   shopping cart page.  There isn't anything remarkable about either of
  these
   two pages, they're basically like any other in the app.  However,
 when
  the
   cart page loads, I get the exception at the bottom of this message.
  
   I've tried implementing Serializable on the Cart() page class but it
  makes
   no difference.  It points out
   com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate as
 the
   culprit.  I use a stateful session bean (ShoppingCart) which is
 passed
   around the app as part of the session (custom WebSession-derived
 class)
  
   This is the only page this occurs on.  There are several other steps
 in
  the
   cart's checkout process that look exactly like this one and the
  exception
   doesn't happen on any of the others
  
   Any ideas?
  
   Exception:
  
   25717 [httpSSLWorkerThread-8080-1] ERROR
   org.apache.wicket.util.lang.Objects
   - Error serializing object class com.myapp.ui.Cart [object=[Page
 class =
   com.myapp.ui.Cart, id = 3, version = 0]]
  
  
 
 org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
   Unable to serialize class:
   com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate
   Field hierarchy is:
3 [class=com.myapp.ui.Cart, path=3]
  private java.lang.Object
 org.apache.wicket.MarkupContainer.children
   [class=[Ljava.lang.Object;]
private
   org.apache.wicket.markup.html.ContainerWithAssociatedMarkupHelper
  
  
 
 org.apache.wicket.markup.html.WebMarkupContainerWithAssociatedMarkup.markupHelper[6]
   [class=org.apache.wicket.markup.html.form.Form, path=3:cartForm]
  private java.lang.Object
  org.apache.wicket.MarkupContainer.children
   [class=[Ljava.lang.Object;]
private java.lang.Object
   org.apache.wicket.MarkupContainer.children[0]
  [class=com.myapp.ui.Cart$1,
   path=3:cartForm:orderLinesView]
  final com.myapp.session.ShoppingCartLocal
   com.myapp.ui.Cart$1.val$cart [class=$Proxy92]
protected java.lang.reflect.InvocationHandler
   java.lang.reflect.Proxy.h
  
 [class=com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate]
   - field that is not serializable

Re: Wicket 1.4 + GF v2.1 causing WicketNotSerializableException

2009-11-19 Thread VGJ
I reference the bean's interface in order to use it, yes.  What's the
alternative?  Would I instead access everything through a proxy class and
store the proxy itself into the WebSession, to retain a reference?  As it
is, each page in the checkout process changes the Stateful bean's properties
and stores it back into the WebSession.  Here is what the Cart page looks
like, in summary:

public class Cart extends BasePage
{
  public Cart()
  {
//get session - derives from Wicket's WebSession
UserSession session = (UserSession)getSession();

//get cart from session
final ShoppingCartLocal cart = ((UserSession)getSession()).getCart();

//create form
Form form = new Form(cartForm);

//add list of non-bundle Configuration objects to form
form.add(new ListView(orderLinesView, cart.getOrderLines())
{
  protected void populateItem(ListItem item)
  {
//stuff happens here...
  }
}

//...and so on...and so forth...
  }
}

On Thu, Nov 19, 2009 at 10:07 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 according to the stacktrace, this component:

 path=3:cartForm:orderLinesView]

 has this reference: final com.myapp.session.ShoppingCartLocal

 so looks like you are holding on to your bean directly instead of using a
 proxy.

 -igor

 On Thu, Nov 19, 2009 at 8:48 AM, VGJ zambi...@gmail.com wrote:
  One would think...however I tried it and it makes no difference.  None of
 my
  proxy classes implement Serializable and this exception occurs nowhere
 else,
  also.
 
  Just to be certain, I just went through and implemented it on *all* of my
  proxy classes in this app.  No change.
 
 
  On Thu, Nov 19, 2009 at 9:30 AM, Igor Vaynberg igor.vaynb...@gmail.com
 wrote:
 
  your CartProxy does not implement serialiazable so it cannot be
  serialized...
 
  -igor
 
  On Thu, Nov 19, 2009 at 7:30 AM, VGJ zambi...@gmail.com wrote:
   I'm not injecting it directly.  I'm using a proxy class to get a
  reference
   to the stateless bean's interface like so:
  
   public class CartProxy
   {
private static ShoppingCartLocal lookupCartInterface()
{
  ShoppingCartLocal cart = null;
  
  try
  {
InitialContext ctx = new InitialContext();
cart =
   (ShoppingCartLocal)ctx.lookup(java:comp/env/ShoppingCartBean);
  }
  catch (NamingException exp)
  {
LogProxy.saveEntry(exp);
  }
  
  return cart;
}
   }
  
   The reference in web.xml makes this possible:
  
ejb-local-ref
  ejb-ref-nameShoppingCartBean/ejb-ref-name
  ejb-ref-typeSession/ejb-ref-type
  localcom.myapp.session.ShoppingCartLocal/local
  ejb-linkMyProjectEJB.jar#ShoppingCartBean/ejb-link
/ejb-local-ref
  
   Is this not supposed to work?  It's been in production for over 3
  yrs...so I
   hope it does!  :)
  
   The entire app is built this way and this one page is the only one
  throwing
   this exception.  It works, it doesn't stop the show or affect anything
   negatively, so far as I can tell.  I would just like to get rid of it
 and
   figure out what it is.
  
   Thanks again,
  
   -v
  
   On Wed, Nov 18, 2009 at 11:49 PM, Igor Vaynberg 
 igor.vaynb...@gmail.com
  wrote:
  
   wicket stuff contains a wicket-jee module which supports injecting
 ejb
   beans into wicket components the same way that wicket-spring injects
   wicket beans.
  
   -igor
  
   On Wed, Nov 18, 2009 at 10:37 PM, Pieter Degraeuwe
   pieter.degrae...@systemworks.be wrote:
Your cart has a reference to the sessionBean ShopingCart. This is
 not
allowed, however. The IOC incjectionsupport makes this possible by
   wrapping
this EJB reference with a serializable proxy.
   
I only have expecience with wicket-spring end it works great. (In
 your
   case,
define your ejb reference in spring and inject it via wicket-spring
   support
in your page.
problem solved!
   
Pieter
   
On Wed, Nov 18, 2009 at 10:50 PM, VGJ zambi...@gmail.com wrote:
   
I'm completely at wits end here and I hope someone can point out
  what's
wrong.
   
I've got an e-commerce application that is simply moving between
 two
   pages
using setRedirectPage() when going from a product detail page to
 the
shopping cart page.  There isn't anything remarkable about either
 of
   these
two pages, they're basically like any other in the app.  However,
  when
   the
cart page loads, I get the exception at the bottom of this
 message.
   
I've tried implementing Serializable on the Cart() page class but
 it
   makes
no difference.  It points out
com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate
 as
  the
culprit.  I use a stateful session bean (ShoppingCart) which is
  passed
around the app as part of the session (custom WebSession-derived
  class)
   
This is the only page this occurs on.  There are several other
 steps
  in
   the
cart's checkout process that look exactly like this one

Re: Wicket 1.4 + GF v2.1 causing WicketNotSerializableException

2009-11-19 Thread VGJ
Yep, you're right - I have a link inside of the populateItem method that
calls it one time, like so:

Link removeLink = new Link(removeLink)
{
  public void onClick()
  {
try
{
  //proxy method to remove line item
  CartProxy.removeOrderLine(cart, line); //here she is!

  //set cart back to session
  ((UserSession)getSession()).setCart(newCart);

  //redirect to self
  setResponsePage(new Cart());
}
catch (Exception exp)
{
  LogProxy.saveEntry(exp);
}
  }
};

I'll test out your suggestion, I hope it's that simple!  Thanks Igor.


On Thu, Nov 19, 2009 at 11:04 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 i am going to guess that inside //stuff happens here... you access
 the final cart field. when you do this inside an anonymous class it
 keeps a reference, so that is what is causing your serialization
 problem. instead of having the final field, do the lookup
 ((UserSession)getSession()).getCart(); directly inside the //stuff
 happens here...

 -igor

 On Thu, Nov 19, 2009 at 9:57 AM, VGJ zambi...@gmail.com wrote:
  I reference the bean's interface in order to use it, yes.  What's the
  alternative?  Would I instead access everything through a proxy class and
  store the proxy itself into the WebSession, to retain a reference?  As it
  is, each page in the checkout process changes the Stateful bean's
 properties
  and stores it back into the WebSession.  Here is what the Cart page looks
  like, in summary:
 
  public class Cart extends BasePage
  {
   public Cart()
   {
 //get session - derives from Wicket's WebSession
 UserSession session = (UserSession)getSession();
 
 //get cart from session
 final ShoppingCartLocal cart = ((UserSession)getSession()).getCart();
 
 //create form
 Form form = new Form(cartForm);
 
 //add list of non-bundle Configuration objects to form
 form.add(new ListView(orderLinesView, cart.getOrderLines())
 {
   protected void populateItem(ListItem item)
   {
 //stuff happens here...
   }
 }
 
 //...and so on...and so forth...
   }
  }
 
  On Thu, Nov 19, 2009 at 10:07 AM, Igor Vaynberg igor.vaynb...@gmail.com
 wrote:
 
  according to the stacktrace, this component:
 
  path=3:cartForm:orderLinesView]
 
  has this reference: final com.myapp.session.ShoppingCartLocal
 
  so looks like you are holding on to your bean directly instead of using
 a
  proxy.
 
  -igor
 
  On Thu, Nov 19, 2009 at 8:48 AM, VGJ zambi...@gmail.com wrote:
   One would think...however I tried it and it makes no difference.  None
 of
  my
   proxy classes implement Serializable and this exception occurs nowhere
  else,
   also.
  
   Just to be certain, I just went through and implemented it on *all* of
 my
   proxy classes in this app.  No change.
  
  
   On Thu, Nov 19, 2009 at 9:30 AM, Igor Vaynberg 
 igor.vaynb...@gmail.com
  wrote:
  
   your CartProxy does not implement serialiazable so it cannot be
   serialized...
  
   -igor
  
   On Thu, Nov 19, 2009 at 7:30 AM, VGJ zambi...@gmail.com wrote:
I'm not injecting it directly.  I'm using a proxy class to get a
   reference
to the stateless bean's interface like so:
   
public class CartProxy
{
 private static ShoppingCartLocal lookupCartInterface()
 {
   ShoppingCartLocal cart = null;
   
   try
   {
 InitialContext ctx = new InitialContext();
 cart =
(ShoppingCartLocal)ctx.lookup(java:comp/env/ShoppingCartBean);
   }
   catch (NamingException exp)
   {
 LogProxy.saveEntry(exp);
   }
   
   return cart;
 }
}
   
The reference in web.xml makes this possible:
   
 ejb-local-ref
   ejb-ref-nameShoppingCartBean/ejb-ref-name
   ejb-ref-typeSession/ejb-ref-type
   localcom.myapp.session.ShoppingCartLocal/local
   ejb-linkMyProjectEJB.jar#ShoppingCartBean/ejb-link
 /ejb-local-ref
   
Is this not supposed to work?  It's been in production for over 3
   yrs...so I
hope it does!  :)
   
The entire app is built this way and this one page is the only one
   throwing
this exception.  It works, it doesn't stop the show or affect
 anything
negatively, so far as I can tell.  I would just like to get rid of
 it
  and
figure out what it is.
   
Thanks again,
   
-v
   
On Wed, Nov 18, 2009 at 11:49 PM, Igor Vaynberg 
  igor.vaynb...@gmail.com
   wrote:
   
wicket stuff contains a wicket-jee module which supports injecting
  ejb
beans into wicket components the same way that wicket-spring
 injects
wicket beans.
   
-igor
   
On Wed, Nov 18, 2009 at 10:37 PM, Pieter Degraeuwe
pieter.degrae...@systemworks.be wrote:
 Your cart has a reference to the sessionBean ShopingCart. This
 is
  not
 allowed, however. The IOC

Re: Wicket 1.4 + GF v2.1 causing WicketNotSerializableException

2009-11-19 Thread VGJ
Ha!  I deserve that.  I was hesitant to put the stuff happens here instead
of just dumping another 100 lines of code in there.  Dammit. ;)

Anyhow, worked great.  Thanks for clearing it up for me!

On Thu, Nov 19, 2009 at 11:26 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 phase 1: collect underpants
 phase 2: ?
 phase 3: profit

 :)

 -igor

 On Thu, Nov 19, 2009 at 10:06 AM, Jeremy Thomerson
 jer...@wickettraining.com wrote:
  The problems always seem to occur in that cloud in the middle of the
 diagram
  that says stuff happens here or this is where the magic happens.
 
  --
  Jeremy Thomerson
  http://www.wickettraining.com
 
 
 
  On Thu, Nov 19, 2009 at 12:04 PM, Igor Vaynberg igor.vaynb...@gmail.com
 wrote:
 
  i am going to guess that inside //stuff happens here... you access
  the final cart field. when you do this inside an anonymous class it
  keeps a reference, so that is what is causing your serialization
  problem. instead of having the final field, do the lookup
  ((UserSession)getSession()).getCart(); directly inside the //stuff
  happens here...
 
  -igor
 
  On Thu, Nov 19, 2009 at 9:57 AM, VGJ zambi...@gmail.com wrote:
   I reference the bean's interface in order to use it, yes.  What's the
   alternative?  Would I instead access everything through a proxy class
 and
   store the proxy itself into the WebSession, to retain a reference?  As
 it
   is, each page in the checkout process changes the Stateful bean's
  properties
   and stores it back into the WebSession.  Here is what the Cart page
 looks
   like, in summary:
  
   public class Cart extends BasePage
   {
public Cart()
{
  //get session - derives from Wicket's WebSession
  UserSession session = (UserSession)getSession();
  
  //get cart from session
  final ShoppingCartLocal cart =
 ((UserSession)getSession()).getCart();
  
  //create form
  Form form = new Form(cartForm);
  
  //add list of non-bundle Configuration objects to form
  form.add(new ListView(orderLinesView, cart.getOrderLines())
  {
protected void populateItem(ListItem item)
{
  //stuff happens here...
}
  }
  
  //...and so on...and so forth...
}
   }
  
   On Thu, Nov 19, 2009 at 10:07 AM, Igor Vaynberg 
 igor.vaynb...@gmail.com
  wrote:
  
   according to the stacktrace, this component:
  
   path=3:cartForm:orderLinesView]
  
   has this reference: final com.myapp.session.ShoppingCartLocal
  
   so looks like you are holding on to your bean directly instead of
 using
  a
   proxy.
  
   -igor
  
   On Thu, Nov 19, 2009 at 8:48 AM, VGJ zambi...@gmail.com wrote:
One would think...however I tried it and it makes no difference.
  None
  of
   my
proxy classes implement Serializable and this exception occurs
 nowhere
   else,
also.
   
Just to be certain, I just went through and implemented it on *all*
 of
  my
proxy classes in this app.  No change.
   
   
On Thu, Nov 19, 2009 at 9:30 AM, Igor Vaynberg 
  igor.vaynb...@gmail.com
   wrote:
   
your CartProxy does not implement serialiazable so it cannot be
serialized...
   
-igor
   
On Thu, Nov 19, 2009 at 7:30 AM, VGJ zambi...@gmail.com wrote:
 I'm not injecting it directly.  I'm using a proxy class to get
 a
reference
 to the stateless bean's interface like so:

 public class CartProxy
 {
  private static ShoppingCartLocal lookupCartInterface()
  {
ShoppingCartLocal cart = null;

try
{
  InitialContext ctx = new InitialContext();
  cart =
 (ShoppingCartLocal)ctx.lookup(java:comp/env/ShoppingCartBean);
}
catch (NamingException exp)
{
  LogProxy.saveEntry(exp);
}

return cart;
  }
 }

 The reference in web.xml makes this possible:

  ejb-local-ref
ejb-ref-nameShoppingCartBean/ejb-ref-name
ejb-ref-typeSession/ejb-ref-type
localcom.myapp.session.ShoppingCartLocal/local
ejb-linkMyProjectEJB.jar#ShoppingCartBean/ejb-link
  /ejb-local-ref

 Is this not supposed to work?  It's been in production for over
 3
yrs...so I
 hope it does!  :)

 The entire app is built this way and this one page is the only
 one
throwing
 this exception.  It works, it doesn't stop the show or affect
  anything
 negatively, so far as I can tell.  I would just like to get rid
 of
  it
   and
 figure out what it is.

 Thanks again,

 -v

 On Wed, Nov 18, 2009 at 11:49 PM, Igor Vaynberg 
   igor.vaynb...@gmail.com
wrote:

 wicket stuff contains a wicket-jee module which supports
 injecting
   ejb
 beans into wicket components the same way that wicket-spring
  injects
 wicket beans.

 -igor

 On Wed, Nov 18, 2009 at 10:37 PM, Pieter Degraeuwe
 pieter.degrae...@systemworks.be wrote:
  Your cart has a reference

Wicket 1.4 + GF v2.1 causing WicketNotSerializableException

2009-11-18 Thread VGJ
I'm completely at wits end here and I hope someone can point out what's
wrong.

I've got an e-commerce application that is simply moving between two pages
using setRedirectPage() when going from a product detail page to the
shopping cart page.  There isn't anything remarkable about either of these
two pages, they're basically like any other in the app.  However, when the
cart page loads, I get the exception at the bottom of this message.

I've tried implementing Serializable on the Cart() page class but it makes
no difference.  It points out
com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate as the
culprit.  I use a stateful session bean (ShoppingCart) which is passed
around the app as part of the session (custom WebSession-derived class)

This is the only page this occurs on.  There are several other steps in the
cart's checkout process that look exactly like this one and the exception
doesn't happen on any of the others

Any ideas?

Exception:

25717 [httpSSLWorkerThread-8080-1] ERROR org.apache.wicket.util.lang.Objects
- Error serializing object class com.myapp.ui.Cart [object=[Page class =
com.myapp.ui.Cart, id = 3, version = 0]]
org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
Unable to serialize class:
com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate
Field hierarchy is:
  3 [class=com.myapp.ui.Cart, path=3]
private java.lang.Object org.apache.wicket.MarkupContainer.children
[class=[Ljava.lang.Object;]
  private
org.apache.wicket.markup.html.ContainerWithAssociatedMarkupHelper
org.apache.wicket.markup.html.WebMarkupContainerWithAssociatedMarkup.markupHelper[6]
[class=org.apache.wicket.markup.html.form.Form, path=3:cartForm]
private java.lang.Object org.apache.wicket.MarkupContainer.children
[class=[Ljava.lang.Object;]
  private java.lang.Object
org.apache.wicket.MarkupContainer.children[0] [class=com.myapp.ui.Cart$1,
path=3:cartForm:orderLinesView]
final com.myapp.session.ShoppingCartLocal
com.myapp.ui.Cart$1.val$cart [class=$Proxy92]
  protected java.lang.reflect.InvocationHandler
java.lang.reflect.Proxy.h
[class=com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate]
- field that is not serializable
at
org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:346)
at
org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:615)
at
org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:538)
at
org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:615)
at
org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:538)
at
org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:392)
at
org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:615)
at
org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:538)
at
org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:392)
at
org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:615)
at
org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:538)
at
org.apache.wicket.util.io.SerializableChecker.writeObjectOverride(SerializableChecker.java:684)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:322)
at
org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:129)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:322)
at
org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1120)
at
org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:203)
at
org.apache.wicket.protocol.http.pagestore.DiskPageStore.storePage(DiskPageStore.java:840)
at
org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.put(SecondLevelCacheSessionStore.java:332)
at org.apache.wicket.Session.requestDetached(Session.java:1404)
at org.apache.wicket.RequestCycle.detach(RequestCycle.java:1176)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1454)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:456)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:289)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288)
at

WebMarkupContainer and SimpleAttributeModifier problems on 1.4.1 upgrade.

2009-10-01 Thread VGJ
I've got a little helper method for replacing HTML tag attributes:

public static WebMarkupContainer getContainer(
String name,
String attribute,
String value)
{
//modify check add-on img tag
WebMarkupContainer container = new WebMarkupContainer(name);
container.add(new SimpleAttributeModifier(attribute, value));

return container;
}

I just upgraded from 1.3.2 to 1.4.1, and I'm getting this exception every
time the above method calls the add method:

java.lang.NoSuchMethodError:
org.apache.wicket.markup.html.WebMarkupContainer.add(Lorg/apache/wicket/behavior/IBehavior;)Lorg/apache/wicket/Component;

I just looked at the 1.4 Javadocs...it looks like this is still valid.  What
am I doing wrong?

Thanks!

-v


Re: WebMarkupContainer and SimpleAttributeModifier problems on 1.4.1 upgrade.

2009-10-01 Thread VGJ
Hmm...nevermind, I guess?  It seems like the problem just went away.  I
can't explain it...a few redeploys later and it's all working as if the
error never happened.

I'll submit this one to the X-Files.

On Thu, Oct 1, 2009 at 12:01 PM, VGJ zambi...@gmail.com wrote:

 I've got a little helper method for replacing HTML tag attributes:

 public static WebMarkupContainer getContainer(
 String name,
 String attribute,
 String value)
 {
 //modify check add-on img tag
 WebMarkupContainer container = new WebMarkupContainer(name);
 container.add(new SimpleAttributeModifier(attribute, value));

 return container;
 }

 I just upgraded from 1.3.2 to 1.4.1, and I'm getting this exception every
 time the above method calls the add method:

 java.lang.NoSuchMethodError:
 org.apache.wicket.markup.html.WebMarkupContainer.add(Lorg/apache/wicket/behavior/IBehavior;)Lorg/apache/wicket/Component;

 I just looked at the 1.4 Javadocs...it looks like this is still valid.
 What am I doing wrong?

 Thanks!

 -v



WebSession issue - Netbeans Glassfish

2009-09-24 Thread VGJ
I've got a very strange problem with WebSession objects becoming null
(suddenly ending) while debugging in Netbeans, using Glassfish as an app
server.  I'm using Wicket 1.3.2 and do not have the option of upgrading to
the latest version on this project right now.

I've got an e-commerce app that switches to https during the checkout
process.  If I'm not in debug mode in Netbeans, this works properly and the
session persists from one page to the next after using a redirect, like so:

  getRequestCycle().setRedirect(false);
  getRequestCycle().setRequestTarget(EmptyRequestTarget.getInstance());
  getResponse().redirect(https://site/secure-page;);

I pass a stateful session bean around the application, in the session, like
so:

ShoppingCartLocal cart = ((UserSession)getSession()).getCart();

My UserSession class looks like this:

public class UserSession extends WebSession
{
private User user;
private ShoppingCartLocal  cart;

public UserSession(WebApplication application, Request request)
{
super(application, request);
}

public User getUser()
{
return this.user;
}

public void setUser(User user)
{
this.user = user;
dirty();
}

public boolean authenticated()
{
if (this.getUser() == null)
return false;
else
return true;
}

public ShoppingCartLocal getCart()
{
return this.cart;
}

public void setCart(ShoppingCartLocal cart)
{
this.cart = cart;
dirty();
}
}

If I'm debugging, the session becomes null after the redirect and throws a
NPE when I try accessing it (of course).  I get the following message:

141750 [httpSSLWorkerThread-8080-4] ERROR org.apache.wicket.RequestCycle -
Can't instantiate page using constructor public com.myapp.UserAccount()
org.apache.wicket.WicketRuntimeException: Can't instantiate page using
constructor public com.myapp.UserAccount()
at
org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:168)
at
org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:58)
at
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:262)
at
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:283)
at
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:210)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:91)
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1166)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1243)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1330)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:493)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:358)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)

Re: WebSession issue - Netbeans Glassfish

2009-09-24 Thread VGJ
I see.  So, if I follow you, I should be OK.  The http-to-https switch
happens after the user has chosen some items and added them to the SFSB,
which would have already been created and added to the session.  The user
doesn't return to http again until the order is completed and the session is
cleared.

Am I correct?

Thanks!

On Thu, Sep 24, 2009 at 11:44 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 not really sure what is happening, but one thing to keep inmind is:

 when accessing an application over https a cookie that holds the
 session id is marked as secure and is not available to following
 requests if they are over http.

 so if the user creates the session over an https request that session
 will essentially be invisible to users over http. this may or may not
 be what is happening to you. if your user enters your app over https
 there is not much you can do, unless you can override container
 environment and stop it from marking the session as secure - which is
 a potential security vulnerability. if your user enters your app over
 http then an easy fix is to create a session right away, that way
 https cookie will hold the same session id.

 -igor

 On Thu, Sep 24, 2009 at 10:39 AM, VGJ zambi...@gmail.com wrote:
  I've got a very strange problem with WebSession objects becoming null
  (suddenly ending) while debugging in Netbeans, using Glassfish as an app
  server.  I'm using Wicket 1.3.2 and do not have the option of upgrading
 to
  the latest version on this project right now.
 
  I've got an e-commerce app that switches to https during the checkout
  process.  If I'm not in debug mode in Netbeans, this works properly and
 the
  session persists from one page to the next after using a redirect, like
 so:
 
   getRequestCycle().setRedirect(false);
 
  getRequestCycle().setRequestTarget(EmptyRequestTarget.getInstance());
   getResponse().redirect(https://site/secure-page;);
 
  I pass a stateful session bean around the application, in the session,
 like
  so:
 
  ShoppingCartLocal cart = ((UserSession)getSession()).getCart();
 
  My UserSession class looks like this:
 
  public class UserSession extends WebSession
  {
 private User user;
 private ShoppingCartLocal  cart;
 
 public UserSession(WebApplication application, Request request)
 {
 super(application, request);
 }
 
 public User getUser()
 {
 return this.user;
 }
 
 public void setUser(User user)
 {
 this.user = user;
 dirty();
 }
 
 public boolean authenticated()
 {
 if (this.getUser() == null)
 return false;
 else
 return true;
 }
 
 public ShoppingCartLocal getCart()
 {
 return this.cart;
 }
 
 public void setCart(ShoppingCartLocal cart)
 {
 this.cart = cart;
 dirty();
 }
  }
 
  If I'm debugging, the session becomes null after the redirect and throws
 a
  NPE when I try accessing it (of course).  I get the following message:
 
  141750 [httpSSLWorkerThread-8080-4] ERROR org.apache.wicket.RequestCycle
 -
  Can't instantiate page using constructor public com.myapp.UserAccount()
  org.apache.wicket.WicketRuntimeException: Can't instantiate page using
  constructor public com.myapp.UserAccount()
 at
 
 org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:168)
 at
 
 org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:58)
 at
 
 org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:262)
 at
 
 org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:283)
 at
 
 org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:210)
 at
 
 org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:91)
 at
 
 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1166)
 at org.apache.wicket.RequestCycle.step(RequestCycle.java:1243)
 at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1330)
 at org.apache.wicket.RequestCycle.request(RequestCycle.java:493)
 at
  org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:358)
 at
 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194)
 at
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
 at
 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
 at
 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288)
 at
 
 org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271

Wicket and RSS

2009-08-19 Thread VGJ
I've got a simple RSS feed I'm trying to display on a page.  Is
wicketstuff-rome dead?  Is there a better way?  I'm not a maven user (not
even familar with it) - so are there any jars I can download somewhere for
wicketstuff-rome, if it's not dead?

Appreciate the help, thanks.


Access http headers?

2009-05-05 Thread VGJ
I have a page that is built on a 3rd. party Flash movie, which reads a very
ugly, remote XML file.  It doesn't work correctly unless the URL I point to
in the embed tag is absolute.  This makes testing it locally a complete
PITA.  I'd like to put something in the page that tests the URL and
redirects if it matches certain criteria - how can I access the HTTP headers
to do this?  Is there a better way?

Thanks!