Ajax ModalWindow - passing value *in*?
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.
Re: 301 Redirect
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 :
> > 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 :
> >> > 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 :
> >> >> > 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: 301 Redirect
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 :
> > 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 :
> >> > 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
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 :
> > 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
>
>
301 Redirect
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: @RequireHttps - forms misbehaving
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 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
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 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: @RequireHttps - forms misbehaving
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, 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")
> >{
> > publi
Re: @RequireHttps - forms misbehaving
application class:
public class ProductCatalogApp extends WebApplication
{
/**
* initialize application resources
*/
@Override
public void init()
{
//mount pretty URLs
mountURLs();
//create external images resource
getSharedResources().add("imageResource", new ImageResource());
//start timer services
TimerProxy.init();
}
/**
* set application home page
*/
public Class getHomePage()
{
return ProductCatalog.class;
}
/**
* set custom session class
*/
@Override
public Session newSession(Request request, Response response)
{
return new UserSession(ProductCatalogApp.this, request);
}
@Override
protected IRequestCycleProcessor newRequestCycleProcessor()
{
return new HttpsRequestCycleProcessor(new HttpsConfig(8080, 8181));
}
/**
* Simple method for listing bookmarked pages with "pretty" URLs
*
*/
private void mountURLs()
{
mount(new HybridUrlCodingStrategy("/login", Login.class));
mount(new HybridUrlCodingStrategy("/products", ProductCatalog.class));
mount(new HybridUrlCodingStrategy("/category", CatalogCategory.class));
mount(new HybridUrlCodingStrategy("/product-detail",
ProductDetail.class));
mount(new HybridUrlCodingStrategy("/cart", Cart.class));
mount(new HybridUrlCodingStrategy("/account", UserAccount.class));
mount(new HybridUrlCodingStrategy("/addresses", ContactInfo.class));
mount(new HybridUrlCodingStrategy("/payment", PaymentInfo.class));
}
}
Hopefully something stands out to someone here...I don't see what could be
causing it?
Thanks again,
-v
On Sun, Dec 20, 2009 at 9:29 PM, wrote:
> Hi VGJ,
>
> If, as you say you can reproduce this in your storefront app no matter
> where you use it then you may want to reduce this to a testcase and
> create a jira issue from it.
>
> You are already writing that you can reproduce it and consequently it
> would be only a matter of removing all distracting detail from your
> storefront until further simplification is no longer possible. I can't
> see how otherwise anyone could help you with your issue.
>
> In any case, glitches like you mention should not happen whether the
> problem is in the Wicket framework domain or in the application
> domain. If it is in the application domain, as it would usually be the
> case because Wicket is mature, then there would still be a benefit of
> publishing the issue e.g. in a Wiki article so that others would not
> make the same mistake.
>
> Good luck!
>
> Bernard
>
> On Fri, 18 Dec 2009 14:58:15 -0700, you wrote:
>
> >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 wrote:
> >
> >> I'll create one and post it, if I can.
> >>
> >> -v
> >>
> >>
> >> On Fri, Dec 18, 2009 at 9:21 AM, Igor Vaynberg >wrote:
> >>
> >>> can you recreate in a quickstart?
> >>>
> >>> -igor
> >>>
> >>> On Fri, Dec 18, 2009 at 7:56 AM, VGJ 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
Re: @RequireHttps - forms misbehaving
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 wrote:
> I'll create one and post it, if I can.
>
> -v
>
>
> On Fri, Dec 18, 2009 at 9:21 AM, Igor Vaynberg wrote:
>
>> can you recreate in a quickstart?
>>
>> -igor
>>
>> On Fri, Dec 18, 2009 at 7:56 AM, VGJ 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:
>> >
>> >
>> >
>> >
>> >
>> > 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
I'll create one and post it, if I can.
-v
On Fri, Dec 18, 2009 at 9:21 AM, Igor Vaynberg wrote:
> can you recreate in a quickstart?
>
> -igor
>
> On Fri, Dec 18, 2009 at 7:56 AM, VGJ 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:
> >
> >
> >
> >
> >
> > Thanks!
> >
> > -v
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
@RequireHttps - forms misbehaving
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:
Thanks!
-v
Re: "Pretty" URLs and sessions
Alex, this was a great help, thank you!
On Thu, Dec 17, 2009 at 3:23 PM, Alex Objelean wrote:
>
> 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
> > wrote:
> >
> >>
> >> 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.(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
> >> > wrote:
> >> >
> >> >>
> >> >> 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 i
Re: "Pretty" URLs and sessions
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 wrote:
>
> 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.(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
> > wrote:
> >
> >>
> >> 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
> >> > wrote:
> >> >
> >> >>
> >> >> 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
> >> >> (
> >> >>
> >>
> h
Re: "Pretty" URLs and sessions
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.(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 wrote:
>
> 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
> > wrote:
> >
> >>
> >> 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
Re: "Pretty" URLs and sessions
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 wrote:
>
> 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
> > wrote:
> >
> >>
> >> 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
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/%22Pretty%22-URLs-and-sessions-tp26581608p26833349.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
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 wrote: > > 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 > >
"Pretty" URLs and sessions
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
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 wrote:
> phase 1: collect underpants
> phase 2: ?
> phase 3: profit
>
> :)
>
> -igor
>
> On Thu, Nov 19, 2009 at 10:06 AM, Jeremy Thomerson
> 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 >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 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 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 wrote:
> >> >> >> > I'm not injecting it directly. I'm using a "proxy" class to get
> a
Re: Wicket 1.4 + GF v2.1 causing WicketNotSerializableException
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 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 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 >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 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 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)
> >> >> >{
> &
Re: Wicket 1.4 + GF v2.1 causing WicketNotSerializableException
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 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 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 >wrote:
> >
> >> your CartProxy does not implement serialiazable so it cannot be
> >> serialized...
> >>
> >> -igor
> >>
> >> On Thu, Nov 19, 2009 at 7:30 AM, VGJ 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:
> >> >
> >> >
> >> >ShoppingCartBean
> >> >Session
> >> >com.myapp.session.ShoppingCartLocal
> >> >MyProjectEJB.jar#ShoppingCartBean
> >> >
> >> >
> >> > 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
> >> >> 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
&g
Re: Wicket 1.4 + GF v2.1 causing WicketNotSerializableException
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 wrote:
> your CartProxy does not implement serialiazable so it cannot be
> serialized...
>
> -igor
>
> On Thu, Nov 19, 2009 at 7:30 AM, VGJ 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:
> >
> >
> >ShoppingCartBean
> >Session
> >com.myapp.session.ShoppingCartLocal
> >MyProjectEJB.jar#ShoppingCartBean
> >
> >
> > 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 >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
> >> 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 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
>
Re: Wicket 1.4 + GF v2.1 causing WicketNotSerializableException
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:
ShoppingCartBean
Session
com.myapp.session.ShoppingCartLocal
MyProjectEJB.jar#ShoppingCartBean
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 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
> 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 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
Wicket 1.4 + GF v2.1 causing WicketNotSerializableException
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 org.apache.catalina.core.StandardContextValve.invokeInternal(StandardCo
Re: WebMarkupContainer and SimpleAttributeModifier problems on 1.4.1 upgrade.
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 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
>
WebMarkupContainer and SimpleAttributeModifier problems on 1.4.1 upgrade.
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: WebSession issue - Netbeans & Glassfish
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 wrote:
> 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 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)
> >
WebSession issue - Netbeans & Glassfish
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)
Wicket and RSS
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?
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 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!
Changing the attribute of a ListView tag?
I'm working with a 3rd. party Flash-based application which I'm trying to
integrate with our data.
To make a long story short, When the user clicks on a US state or foreign
country, I would like to un-hide a hidden tag on the same page. The
div tag is tied to a ListView - so basically, there are several hidden divs
which contain a data item (w/ a little JavaScript and the map unhides the
relevant one w/ a parameter.
So far, I'm having trouble figuring out how I can possibly do this.
Here's the tag:
Here's my ListItem and my attempt at re-assigning the ID value using a
WebMarkupContainer, so it ties to the values coming out of the map:
add(new ListView("customerList", customerModel)
{
protected void populateItem(final ListItem item)
{
//current entity in loop
final Customer customer = (Customer)item.getModelObject();
//capture values needed for temp formatting variables
String country = customer.getCountry() != null ?
customer.getCountry().trim() : "";
String stateProv = customer.getStateProvince() != null ?
customer.getStateProvince().trim() : "";
String city = customer.getCity() != null ? customer.getCity().trim()
: "";
//category labels
item.add(new Label("country", country));
item.add(new Label("stateProv", stateProv));
item.add(new Label("city", city));
String tagId = null;
if (!stateProv.equals(""))
tagId = stateProv;
else
tagId = country;
//modify check add-on img tag
WebMarkupContainer container = new
WebMarkupContainer("customerList");
container.add(new SimpleAttributeModifier("id", tagId));
item.add(container);
}
});
It doesn't change the values and it doesn't throw me an error...the id value
remains "#"
What else can I do?
Thanks!
