Re: Is it safe to use ComponentRenderer with different apps in the same thread one after another?
Hi Thorsten,
> As well I really only need to render within one and the same thread
> one after another,
that should work.
> is it safe to render recursively using ComponentRenderer within
> one and the same thread?
I assume you mean 'consecutively'? Yes, see above.
Have fun
Sven
On 29.03.20 15:45, Thorsten Schöning wrote:
Hi all,
I'm using Wicket as some render engine to render mails for reports
consisting of different individual render approaches: plain text only,
HTML only, a combination of both. In the latter case I of course would
like to simply reuse the former approaches, but am not sure if the
used ComponentRenderer does support that.
My individual rendering looks like the following:
private static String
forSome(VwrCtxctx,
Supplier page)
{
try (VwrCtxThreadScoped scopedCtx = new VwrCtxThreadScoped(ctx))
{
VwrHtmlApp app = new VwrHtmlApp();
ComponentRenderer renderer= new ComponentRenderer(app);
CharSequenceretVal = renderer.renderPage(page);
return retVal.toString();
}
}
"renderer.renderPage" is where I would call the above additionally to
provide text- and HTML-only. From my understanding that should be
safe, because ComponentRenderer supports multiple different contexts
for app etc.:
private T inThreadContext(Supplier supplier)
{
ThreadContext oldContext = ThreadContext.detach();
try
{
ThreadContext.setApplication(application);
return supplier.get();
}
finally
{
ThreadContext.restore(oldContext);
}
}
As well I really only need to render within one and the same thread
one after another, I'm not resuing apps or contexts between different
threads in parallel. If that would be needed at some point, it would
be dealt with at a higher level rendering using some threadpool.
So, is it safe to render recursively using ComponentRenderer within
one and the same thread? Thanks!
Mit freundlichen Grüßen,
Thorsten Schöning
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Is it safe to use ComponentRenderer with different apps in the same thread one after another?
Hi all,
I'm using Wicket as some render engine to render mails for reports
consisting of different individual render approaches: plain text only,
HTML only, a combination of both. In the latter case I of course would
like to simply reuse the former approaches, but am not sure if the
used ComponentRenderer does support that.
My individual rendering looks like the following:
> private static String
> forSome(VwrCtxctx,
> Supplier page)
> {
> try (VwrCtxThreadScoped scopedCtx = new VwrCtxThreadScoped(ctx))
> {
> VwrHtmlApp app = new VwrHtmlApp();
> ComponentRenderer renderer= new ComponentRenderer(app);
> CharSequenceretVal = renderer.renderPage(page);
>
> return retVal.toString();
> }
> }
"renderer.renderPage" is where I would call the above additionally to
provide text- and HTML-only. From my understanding that should be
safe, because ComponentRenderer supports multiple different contexts
for app etc.:
> private T inThreadContext(Supplier supplier)
> {
> ThreadContext oldContext = ThreadContext.detach();
>
> try
> {
> ThreadContext.setApplication(application);
>
> return supplier.get();
> }
> finally
> {
>
> ThreadContext.restore(oldContext);
> }
> }
As well I really only need to render within one and the same thread
one after another, I'm not resuing apps or contexts between different
threads in parallel. If that would be needed at some point, it would
be dealt with at a higher level rendering using some threadpool.
So, is it safe to render recursively using ComponentRenderer within
one and the same thread? Thanks!
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...05151- 9468- 55
Fax...05151- 9468- 88
Mobil..0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Safe way to display HTML user input
For the history here is library: https://github.com/owasp/java-html-sanitizer Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Feb 9, 2017 at 11:28 PM, daniel simko <dan.si...@gmail.com> wrote: > Thank you Martin! This is exactly what I was looking for. > > 2017-02-09 13:03 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>: > > > Hi, > > > > Check https://jsoup.org/cookbook/cleaning-html/whitelist-sanitizer > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Thu, Feb 9, 2017 at 12:50 PM, daniel simko <dan.si...@gmail.com> > wrote: > > > > > Hello, > > > > > > I would like to ask you whether there is some safe way how to display > > html > > > output from some rich editor (e.g. TinyMCE)? In order to display html > it > > is > > > necessary to switch off model escaping [1] which is opening a door for > > XSS. > > > I was thinking about some converter [2] which would escape only JS > > related > > > stuff (e.g.
Re: Safe way to display HTML user input
Thank you Martin! This is exactly what I was looking for. 2017-02-09 13:03 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>: > Hi, > > Check https://jsoup.org/cookbook/cleaning-html/whitelist-sanitizer > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Thu, Feb 9, 2017 at 12:50 PM, daniel simko <dan.si...@gmail.com> wrote: > > > Hello, > > > > I would like to ask you whether there is some safe way how to display > html > > output from some rich editor (e.g. TinyMCE)? In order to display html it > is > > necessary to switch off model escaping [1] which is opening a door for > XSS. > > I was thinking about some converter [2] which would escape only JS > related > > stuff (e.g.
Re: Safe way to display HTML user input
Hi, Check https://jsoup.org/cookbook/cleaning-html/whitelist-sanitizer Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Feb 9, 2017 at 12:50 PM, daniel simko <dan.si...@gmail.com> wrote: > Hello, > > I would like to ask you whether there is some safe way how to display html > output from some rich editor (e.g. TinyMCE)? In order to display html it is > necessary to switch off model escaping [1] which is opening a door for XSS. > I was thinking about some converter [2] which would escape only JS related > stuff (e.g.
Safe way to display HTML user input
Hello, I would like to ask you whether there is some safe way how to display html output from some rich editor (e.g. TinyMCE)? In order to display html it is necessary to switch off model escaping [1] which is opening a door for XSS. I was thinking about some converter [2] which would escape only JS related stuff (e.g.
Re: wicket-el - is this a safe way to hook into wicket?
https://issues.apache.org/jira/browse/WICKET-5456 6.13 should be released soon. Martin Grigorov Wicket Training and Consulting On Mon, Dec 23, 2013 at 4:21 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Sun, Dec 22, 2013 at 5:30 AM, Steve shadders@gmail.com wrote: So what it is the best way to go about requesting a change to wicket-core? I'm happy to fork and create a pull request etc but it seems overkill for removing a single word from one class. Should I create a JIRA ticket perhaps? Create a JIRA that describes why you need it and put a link back to this thread in the JIRA. That way it will be around for posterity if the change is made. -- Jeremy Thomerson http://wickettraining.com
Re: wicket-el - is this a safe way to hook into wicket?
On Sun, Dec 22, 2013 at 5:30 AM, Steve shadders@gmail.com wrote: So what it is the best way to go about requesting a change to wicket-core? I'm happy to fork and create a pull request etc but it seems overkill for removing a single word from one class. Should I create a JIRA ticket perhaps? Create a JIRA that describes why you need it and put a link back to this thread in the JIRA. That way it will be around for posterity if the change is made. -- Jeremy Thomerson http://wickettraining.com
Re: wicket-el - is this a safe way to hook into wicket?
On 19/12/13 18:45, Martin Grigorov wrote: So far no one needed to add custom MarkupElements and that's why it is not very easy. You can fork Wicket and create a branch where you can make modifications to make it easier and later we can review the needed changes and probably apply them back in Wicket. Hi Martin, I've found a way to achieve the goal of immutable markup. It's basically what we were talking about with a subclass of ComponentTag and RawMarkup. And I've found a better way to hook into wicket to generate this Markup by adding a MarkupFilter to the MarkupParser. This has the advantage of not even needing to subclass Markup as I can replace MarkupElements in MarkupFilter#postProcess. There's also huge benefits in the wicket-el code... Removing the need for quite a bit of complex code to manage situations where an EL component has associated markup that contains expressions that belong to one of it's child components. The only change needed to wicket to achieve this is removing the 'final' modifier from the RawMarkup class. I haven't been able to fully test it yet as I'm having trouble getting wicket-core to compile in eclipse. But it's very clear that the approach will work. So what it is the best way to go about requesting a change to wicket-core? I'm happy to fork and create a pull request etc but it seems overkill for removing a single word from one class. Should I create a JIRA ticket perhaps? I imagine I'll need to maintain the current implementation for a while as if the request change to RawMarkup is accepted it will take some time for it to appear in a release version. Any idea how long that would take? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket-el - is this a safe way to hook into wicket?
Hi, I'm glad you are making progress with your adventure! On Thu, Dec 19, 2013 at 7:40 AM, Steve Coughlan shadders@gmail.comwrote: A few weeks back I made a post about the first version of universal expression language for wicket. Since then it's come quite a way. The initial version hooked into by implementing IMarkupResourceStreamProvider for markup owning MarkupContainers (Panel, Page etc...) and by regenerating markup fragments for markup receiving MarkupContainers (ListView). Unfortunately due to the fact that the EL expressions need to be evaluated on every request this meant a huge performance hit (about 75% less than standard wicket) due to forcing wicket to constantly parse markup on every request cycle. The current evolution of wicket-el hooks in very differently. My first preference was to create a dynamic version of Markup and MarkupFragment that replaces MarkupElements that contain EL expressions with a dynamic version. Unfortuantely this was impossible because I need to subclass Markup (wicket uses a few case of 'instanceof Markup') and Markup has many final methods. And simply wrapping all the MarkupElements isn't possible because RawMarkup is a final class and is also reference inside wicket with 'instanceof'. So far no one needed to add custom MarkupElements and that's why it is not very easy. You can fork Wicket and create a branch where you can make modifications to make it easier and later we can review the needed changes and probably apply them back in Wicket. So the only way I could think of to do it (which I've done and it works) is to create a subclass of Markup (ModifiableMarkup) that takes the original wicket-parsed markup, and adds all it's elements. Then during the onRender phase EL enabled components call ModifiableMarkup.resolve(ExpressionResolver, ELParseMatchList) which internally replaces RawMarkup elements belonging to that compenent with an EL resolved version. This is done just before calling super.onRender(). Sounds ugly but it works and performance is now equal to standard wicket (in some cases can even be a little faster due to not needing PropertyModels). Because the Markup instances are now mutable I can't use wicket's markup cache as it's one per class and ModifiableMarkup.resolve method could easily be called by many threads at once. So I've had to implement caching per thread/class combination. i.e. ELPanel will have a cached instance of Markup for every thread. My question is twofold: 1/ As I have no choice but to leave ModifiableMarkup mutable, what is the purpose of making Markup immutable? From what I can see from browsing wicket source all it achieves is a bit of safety and releasing some resources from the backing XmlTags in the MarkupElements. Is there any other purpose to it? i.e. can you forsee any problems with using a mutable instance of Markup for rendering? Why ModifiableMarkup has to be mutable ? Do you expect that the markup will change at runtime in some conditions ? I think what you need is a new impl of MarkupElement for the expressions. So org.apache.wicket.markup.Markup#markupElements will have more elements. Then when rendering starts each element will render itself as appropriate. But the list itself won't change once created. If the developer changes the markup then the whole Markup instance is replaced with a new one. As now. 2/ Is the per thread/class caching strategy really safe? The only way I could think it could be broken is if it was possible for the server to suspend a thread mid-render cycle and give another request use of that thread. If that happened the new request would overwrite the markup expressions and the when the old resumed and expressions already resolved would have values from the the request that interrupted it. As far as I'm aware with the work I've done with Jetty and NIO connectors before this will only happen if you ask Jetty to do it while processing the request. Is this a possibility with wicket or can I rely on a complete render cycle to happen uninterrupted before the thread is reused for another request? It is safe to assume that exactly one thread will process the request. This is how Wicket's thread locals work today. Using Servlet 3.0 AsyncContext in a page will break many other things.
Re: wicket-el - is this a safe way to hook into wicket?
Why ModifiableMarkup has to be mutable ?
Do you expect that the markup will change at runtime in some conditions ?
I think what you need is a new impl of MarkupElement for the expressions.
So org.apache.wicket.markup.Markup#markupElements will have more elements.
Then when rendering starts each element will render itself as appropriate.
But the list itself won't change once created.
Yes markup will change at runtime. It is primarily because of
RawMarkup. It is a final class and there are several examples of: if
(element instanceof RawMarkup) do something; in wicket so when
resolving the EL expressions in the markup the only 'safe' way to do it
and stay completely transparent to wicket is to replace the original
RawMarkup with a new one... e.g.
in the EL component:
public void onRender() {
modifiableMarkup.resolve(some params);
super.onRender();
}
What it looks like inside MarkupModifier.resolve() is something like this:
original RawMarkup.toString: span${myProperty}/span
resolved = new RawMarkup(spanmy property value/span);
modifiableMarkup.replace(rawMarkupIndex, resolved);
(actually it's not really relevant to this discussion but the original
RawMarkup contains a marker token instead of the original expression to
ensure it's XML legal before it's passed to the markup parser... in this
case it would be '${#[expressionIndex]}' )
here's a link to ModifiableMarkup
https://bitbucket.org/shadders/wicket-el/src/917bb51f19ddd6e631d8ce537c90915eb21fb01f/src/main/java/org/apache/wicket/markup/ModifiableMarkup.java?at=default
So I can't call makeImmutable() on ModifiableMarkup or it will throw an
exception whenever replace(index, markupElement) is called. However the
length of the element list will never change and each element in the
list will always be the same type.
If the developer changes the markup then the whole Markup instance is
replaced with a new one. As now.
That's the entire purpose of this approach... To avoid that. The
overhead from continually recreating Markups was enormous.
So far no one needed to add custom MarkupElements and that's why it is not
very easy.
You can fork Wicket and create a branch where you can make modifications to
make it easier and
later we can review the needed changes and probably apply them back in
Wicket.
I may give that a go. This has been an interesting exercise that's
forced to spend a lot of time under the hood in wicket getting to know
the markup sourcing and rendering aspects of it. I must confess I was a
little concerned the wicket team might not like this project much given
that it's fairly hefty divergence from the wicket way of doing
things... Wonderful to hear you are open to considering some minor
changes to accomodate it.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket-el - is this a safe way to hook into wicket?
On Thu, Dec 19, 2013 at 11:49 AM, Steve shadders@gmail.com wrote:
Why ModifiableMarkup has to be mutable ?
Do you expect that the markup will change at runtime in some conditions ?
I think what you need is a new impl of MarkupElement for the expressions.
So org.apache.wicket.markup.Markup#markupElements will have more
elements.
Then when rendering starts each element will render itself as
appropriate.
But the list itself won't change once created.
Yes markup will change at runtime. It is primarily because of
RawMarkup. It is a final class and there are several examples of: if
(element instanceof RawMarkup) do something; in wicket so when
resolving the EL expressions in the markup the only 'safe' way to do it
and stay completely transparent to wicket is to replace the original
RawMarkup with a new one... e.g.
in the EL component:
public void onRender() {
modifiableMarkup.resolve(some params);
super.onRender();
}
What it looks like inside MarkupModifier.resolve() is something like this:
original RawMarkup.toString: span${myProperty}/span
resolved = new RawMarkup(spanmy property value/span);
modifiableMarkup.replace(rawMarkupIndex, resolved);
My idea is to use something like ElMarkupElement instead of RawMarkup when
there are EL expressions inside.
Then each ElMarkupElement will resolve its value when requested
(org.apache.wicket.markup.MarkupElement#toCharSequence, I think).
You can put the params in the request cycle metadata, or custom thread
local, ...
This way the Markup instance is always the same, its markup elements are
always the same, but the output they produce is different depending on the
context information.
To accomplish this you will need to tweak the MarkupParser though.
The good thing is that Wicket parses the markup just once and then puts it
in the cache.
(actually it's not really relevant to this discussion but the original
RawMarkup contains a marker token instead of the original expression to
ensure it's XML legal before it's passed to the markup parser... in this
case it would be '${#[expressionIndex]}' )
here's a link to ModifiableMarkup
https://bitbucket.org/shadders/wicket-el/src/917bb51f19ddd6e631d8ce537c90915eb21fb01f/src/main/java/org/apache/wicket/markup/ModifiableMarkup.java?at=default
So I can't call makeImmutable() on ModifiableMarkup or it will throw an
exception whenever replace(index, markupElement) is called. However the
length of the element list will never change and each element in the
list will always be the same type.
If the developer changes the markup then the whole Markup instance is
replaced with a new one. As now.
That's the entire purpose of this approach... To avoid that. The
overhead from continually recreating Markups was enormous.
So far no one needed to add custom MarkupElements and that's why it is not
very easy.
You can fork Wicket and create a branch where you can make modifications
to
make it easier and
later we can review the needed changes and probably apply them back in
Wicket.
I may give that a go. This has been an interesting exercise that's
forced to spend a lot of time under the hood in wicket getting to know
the markup sourcing and rendering aspects of it. I must confess I was a
I am not the best person to guide you in this part of Wicket.
Because markup handling was relatively bug-free in the last years I haven't
spent much time in this area.
Also there were no many brave souls to do something like you :)
little concerned the wicket team might not like this project much given
that it's fairly hefty divergence from the wicket way of doing
things... Wonderful to hear you are open to considering some minor
changes to accomodate it.
I personally do not like EL per se.
But I see no problem to make it easier for external projects to hook in
every part of Wicket to accomplish whatever is needed, as far as the core
functionality of Wicket is not harmed by this.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket-el - is this a safe way to hook into wicket?
On Wed, Dec 18, 2013 at 9:40 PM, Steve Coughlan shadders@gmail.com wrote: A few weeks back I made a post about the first version of universal expression language for wicket. Since then it's come quite a way. The initial version hooked into by implementing IMarkupResourceStreamProvider for markup owning MarkupContainers (Panel, Page etc...) and by regenerating markup fragments for markup receiving MarkupContainers (ListView). Unfortunately due to the fact that the EL expressions need to be evaluated on every request this meant a huge performance hit (about 75% less than standard wicket) due to forcing wicket to constantly parse markup on every request cycle. The current evolution of wicket-el hooks in very differently. My first preference was to create a dynamic version of Markup and MarkupFragment that replaces MarkupElements that contain EL expressions with a dynamic version. Unfortuantely this was impossible because I need to subclass Markup (wicket uses a few case of 'instanceof Markup') and Markup has many final methods. And simply wrapping all the MarkupElements isn't possible because RawMarkup is a final class and is also reference inside wicket with 'instanceof'. So the only way I could think of to do it (which I've done and it works) is to create a subclass of Markup (ModifiableMarkup) that takes the original wicket-parsed markup, and adds all it's elements. Then during the onRender phase EL enabled components call ModifiableMarkup.resolve(ExpressionResolver, ELParseMatchList) which internally replaces RawMarkup elements belonging to that compenent with an EL resolved version. This is done just before calling super.onRender(). Sounds ugly but it works and performance is now equal to standard wicket (in some cases can even be a little faster due to not needing PropertyModels). Because the Markup instances are now mutable I can't use wicket's markup cache as it's one per class and ModifiableMarkup.resolve method could easily be called by many threads at once. So I've had to implement caching per thread/class combination. i.e. ELPanel will have a cached instance of Markup for every thread. My question is twofold: 1/ As I have no choice but to leave ModifiableMarkup mutable, what is the purpose of making Markup immutable? From what I can see from browsing wicket source all it achieves is a bit of safety and releasing some resources from the backing XmlTags in the MarkupElements. Is there any other purpose to it? i.e. can you forsee any problems with using a mutable instance of Markup for rendering? because its immutable it is thread-safe. making it mutable would add a lot of complexity to make sure it is thread-safe. -igor 2/ Is the per thread/class caching strategy really safe? The only way I could think it could be broken is if it was possible for the server to suspend a thread mid-render cycle and give another request use of that thread. If that happened the new request would overwrite the markup expressions and the when the old resumed and expressions already resolved would have values from the the request that interrupted it. As far as I'm aware with the work I've done with Jetty and NIO connectors before this will only happen if you ask Jetty to do it while processing the request. Is this a possibility with wicket or can I rely on a complete render cycle to happen uninterrupted before the thread is reused for another request? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
wicket-el - is this a safe way to hook into wicket?
A few weeks back I made a post about the first version of universal expression language for wicket. Since then it's come quite a way. The initial version hooked into by implementing IMarkupResourceStreamProvider for markup owning MarkupContainers (Panel, Page etc...) and by regenerating markup fragments for markup receiving MarkupContainers (ListView). Unfortunately due to the fact that the EL expressions need to be evaluated on every request this meant a huge performance hit (about 75% less than standard wicket) due to forcing wicket to constantly parse markup on every request cycle. The current evolution of wicket-el hooks in very differently. My first preference was to create a dynamic version of Markup and MarkupFragment that replaces MarkupElements that contain EL expressions with a dynamic version. Unfortuantely this was impossible because I need to subclass Markup (wicket uses a few case of 'instanceof Markup') and Markup has many final methods. And simply wrapping all the MarkupElements isn't possible because RawMarkup is a final class and is also reference inside wicket with 'instanceof'. So the only way I could think of to do it (which I've done and it works) is to create a subclass of Markup (ModifiableMarkup) that takes the original wicket-parsed markup, and adds all it's elements. Then during the onRender phase EL enabled components call ModifiableMarkup.resolve(ExpressionResolver, ELParseMatchList) which internally replaces RawMarkup elements belonging to that compenent with an EL resolved version. This is done just before calling super.onRender(). Sounds ugly but it works and performance is now equal to standard wicket (in some cases can even be a little faster due to not needing PropertyModels). Because the Markup instances are now mutable I can't use wicket's markup cache as it's one per class and ModifiableMarkup.resolve method could easily be called by many threads at once. So I've had to implement caching per thread/class combination. i.e. ELPanel will have a cached instance of Markup for every thread. My question is twofold: 1/ As I have no choice but to leave ModifiableMarkup mutable, what is the purpose of making Markup immutable? From what I can see from browsing wicket source all it achieves is a bit of safety and releasing some resources from the backing XmlTags in the MarkupElements. Is there any other purpose to it? i.e. can you forsee any problems with using a mutable instance of Markup for rendering? 2/ Is the per thread/class caching strategy really safe? The only way I could think it could be broken is if it was possible for the server to suspend a thread mid-render cycle and give another request use of that thread. If that happened the new request would overwrite the markup expressions and the when the old resumed and expressions already resolved would have values from the the request that interrupted it. As far as I'm aware with the work I've done with Jetty and NIO connectors before this will only happen if you ask Jetty to do it while processing the request. Is this a possibility with wicket or can I rely on a complete render cycle to happen uninterrupted before the thread is reused for another request?
Another safe way to build PropertyModels
Hi After playing around with both lambdaJ and SafeModel, here is our take on safe property model creation (that shamelessly steals from the above ones): IModelPerson p=... IModelStreet pm = model(from(p).getAddress().getStreet()) or assert(address.street, path(from(p).getAddress().getStreet()) ); in short: API=SafeModel-ish, Speed=lambdaJ-ish http://wicketeer.org/wicket-modelfactory/ this is heavily used in several production projects. we'd love to get feedback of any kind. uwe PS: Kudos to C.E.Menzel and M.Fusco for their respective work - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Safe URL for a dynamic resource
Hi, I'm trying to display a PDF file inside an IFRAME. To do that, I need a url to place on the IFRAME's src attribute. My idea is to create a shared resource and mount a url to it so I can reference it easily. Since the PDF file is generated on-the-fly, I can also pass a parameter through this url to determine the file's contents. However, I'm concerned about how safe it would be to do this. To add the shared resource I have to produce a single WebResource object. This would be fine if the call to getResourceStream would also pass along the parameters that have been set, but the parameters are retrieved though a call to getParameters. That means that the setParameters method must be called by Wicket sometime before the call to getResourceStream is made. My question is: How can I be sure that multiple simultaneous requests won't have concurrency problems in this scenario? Could there be a better way to do this? Thanks in advance, Denis Souza
Re: Safe URL for a dynamic resource
you can read the parameters off the url yourself, requestcycle.getrequest()... -igor On Tue, Sep 14, 2010 at 10:08 AM, Denis Souza denis.so...@gmail.com wrote: Hi, I'm trying to display a PDF file inside an IFRAME. To do that, I need a url to place on the IFRAME's src attribute. My idea is to create a shared resource and mount a url to it so I can reference it easily. Since the PDF file is generated on-the-fly, I can also pass a parameter through this url to determine the file's contents. However, I'm concerned about how safe it would be to do this. To add the shared resource I have to produce a single WebResource object. This would be fine if the call to getResourceStream would also pass along the parameters that have been set, but the parameters are retrieved though a call to getParameters. That means that the setParameters method must be called by Wicket sometime before the call to getResourceStream is made. My question is: How can I be sure that multiple simultaneous requests won't have concurrency problems in this scenario? Could there be a better way to do this? Thanks in advance, Denis Souza - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Safe URL for a dynamic resource
Thanks, that worked! I had though of something like that but the WebResource does not give you access to a request cycle. I had forgotten that I can just call RequestCycle.get(). Also I noticed the strangest thing while implementing it. Let's say I have the following query string: ?order=1234autoPrint=false Whenever I get the PageParameters from the request cycle and try to retrieve a parameter (say, order) it gives me the memory reference for the string instead of the string itself. For example it gives me [Ljava.lang.String;@1b4d41e instead of 1234. The same thing happens if I call requestCycle.getRequest().getParameterMap().get(order) But if I call requestCycle.getRequest().getParameter(order) it works fine. It's not really a big problem because I can just call the method that works, but, out of curiosity, any idea why this happens? Denis Souza -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: terça-feira, 14 de setembro de 2010 14:22 To: users@wicket.apache.org Subject: Re: Safe URL for a dynamic resource you can read the parameters off the url yourself, requestcycle.getrequest()... -igor On Tue, Sep 14, 2010 at 10:08 AM, Denis Souza denis.so...@gmail.com wrote: Hi, I'm trying to display a PDF file inside an IFRAME. To do that, I need a url to place on the IFRAME's src attribute. My idea is to create a shared resource and mount a url to it so I can reference it easily. Since the PDF file is generated on-the-fly, I can also pass a parameter through this url to determine the file's contents. However, I'm concerned about how safe it would be to do this. To add the shared resource I have to produce a single WebResource object. This would be fine if the call to getResourceStream would also pass along the parameters that have been set, but the parameters are retrieved though a call to getParameters. That means that the setParameters method must be called by Wicket sometime before the call to getResourceStream is made. My question is: How can I be sure that multiple simultaneous requests won't have concurrency problems in this scenario? Could there be a better way to do this? Thanks in advance, Denis Souza - 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: Safe URL for a dynamic resource
Thanks, that worked! I had though of something like that but the WebResource does not give you access to a request cycle. I had forgotten that I can just call RequestCycle.get(). Also I noticed the strangest thing while implementing it. Let's say I have the following query string: ?order=1234autoPrint=false Whenever I get the PageParameters from the request cycle and try to retrieve a parameter (say, order) it gives me the memory reference for the string instead of the string itself. For example it gives me [Ljava.lang.String;@1b4d41e instead of 1234. The same thing happens if I call requestCycle.getRequest().getParameterMap().get(order) But if I call requestCycle.getRequest().getParameter(order) it works fine. It's not really a big problem because I can just call the method that works, but, out of curiosity, any idea why this happens? Denis Souza -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: terça-feira, 14 de setembro de 2010 14:22 To: users@wicket.apache.org Subject: Re: Safe URL for a dynamic resource you can read the parameters off the url yourself, requestcycle.getrequest()... -igor On Tue, Sep 14, 2010 at 10:08 AM, Denis Souza denis.so...@gmail.com wrote: Hi, I'm trying to display a PDF file inside an IFRAME. To do that, I need a url to place on the IFRAME's src attribute. My idea is to create a shared resource and mount a url to it so I can reference it easily. Since the PDF file is generated on-the-fly, I can also pass a parameter through this url to determine the file's contents. However, I'm concerned about how safe it would be to do this. To add the shared resource I have to produce a single WebResource object. This would be fine if the call to getResourceStream would also pass along the parameters that have been set, but the parameters are retrieved though a call to getParameters. That means that the setParameters method must be called by Wicket sometime before the call to getResourceStream is made. My question is: How can I be sure that multiple simultaneous requests won't have concurrency problems in this scenario? Could there be a better way to do this? Thanks in advance, Denis Souza - 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: Safe URL for a dynamic resource
use getstring() -igor On Tue, Sep 14, 2010 at 11:17 AM, Denis Souza denis.so...@gmail.com wrote: Thanks, that worked! I had though of something like that but the WebResource does not give you access to a request cycle. I had forgotten that I can just call RequestCycle.get(). Also I noticed the strangest thing while implementing it. Let's say I have the following query string: ?order=1234autoPrint=false Whenever I get the PageParameters from the request cycle and try to retrieve a parameter (say, order) it gives me the memory reference for the string instead of the string itself. For example it gives me [Ljava.lang.String;@1b4d41e instead of 1234. The same thing happens if I call requestCycle.getRequest().getParameterMap().get(order) But if I call requestCycle.getRequest().getParameter(order) it works fine. It's not really a big problem because I can just call the method that works, but, out of curiosity, any idea why this happens? Denis Souza -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: terça-feira, 14 de setembro de 2010 14:22 To: users@wicket.apache.org Subject: Re: Safe URL for a dynamic resource you can read the parameters off the url yourself, requestcycle.getrequest()... -igor On Tue, Sep 14, 2010 at 10:08 AM, Denis Souza denis.so...@gmail.com wrote: Hi, I'm trying to display a PDF file inside an IFRAME. To do that, I need a url to place on the IFRAME's src attribute. My idea is to create a shared resource and mount a url to it so I can reference it easily. Since the PDF file is generated on-the-fly, I can also pass a parameter through this url to determine the file's contents. However, I'm concerned about how safe it would be to do this. To add the shared resource I have to produce a single WebResource object. This would be fine if the call to getResourceStream would also pass along the parameters that have been set, but the parameters are retrieved though a call to getParameters. That means that the setParameters method must be called by Wicket sometime before the call to getResourceStream is made. My question is: How can I be sure that multiple simultaneous requests won't have concurrency problems in this scenario? Could there be a better way to do this? Thanks in advance, Denis Souza - 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: Is WicketFilter.checkCharacterEncoding() safe?
As solution I can see using HttpServletRequestWrapper instead of dealing directly with the HttpServletRequest passed by the container. This way we can provide custom implementation of HttpServletRequestWrapper that overrides javax.servlet.ServletRequestWrapper.getCharacterEncoding() and if super.getCharacterEncoding() returns 'null' then use the preconfigured one in the settings and cache it. If other devs think this solution is ok then please create a ticket and we will improve it. On Sun, Aug 15, 2010 at 6:32 PM, Harald Wellmann harald.wellm...@multi-m.de wrote: I'm not sure if this is severe or not, but I think there's a gap in the implicit assumptions underlying WicketFilter.checkCharacterEncoding(): It seems the author's intention was to guarantee a postcondition of servletRequest.getCharacterEncoding() != null, but this postcondition does not hold in all cases. I ran into this issue after upgrading my Glassfish app server from 3.0.1 to 3.1-b12, containing a newer release of Weld which causes the problem to appear. After this upgrade, my log was full of warnings of the following type: WARN o.apache.catalina.connector.Request - PWC4011: Unable to set request character encoding to UTF-8 from context /xxx, because request parameters have already been read, or ServletRequest.getReader() has already been called Setting a couple of breakpoints revealed that Weld registers a ServletRequestListener and calls request.getParameter() in that listener. By specification, this listener gets called before all servlet filters, including WicketFilter, and again by specification, the invocation of servlet.request.setCharacterEncoding() from WicketFilter has no effect, since a request parameter has already been read by the WeldListener. So it there are other parts of Wicket relying on the request character encoding to be non-null, then this looks like a bug to me. Otherwise, if Wicket handles a null character encoding gracefully, then checkCharacterEncoding() is redundant, because it cannot be guaranteed to have any effect. Regards, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Is WicketFilter.checkCharacterEncoding() safe?
I'm not sure if this is severe or not, but I think there's a gap in the implicit assumptions underlying WicketFilter.checkCharacterEncoding(): It seems the author's intention was to guarantee a postcondition of servletRequest.getCharacterEncoding() != null, but this postcondition does not hold in all cases. I ran into this issue after upgrading my Glassfish app server from 3.0.1 to 3.1-b12, containing a newer release of Weld which causes the problem to appear. After this upgrade, my log was full of warnings of the following type: WARN o.apache.catalina.connector.Request - PWC4011: Unable to set request character encoding to UTF-8 from context /xxx, because request parameters have already been read, or ServletRequest.getReader() has already been called Setting a couple of breakpoints revealed that Weld registers a ServletRequestListener and calls request.getParameter() in that listener. By specification, this listener gets called before all servlet filters, including WicketFilter, and again by specification, the invocation of servlet.request.setCharacterEncoding() from WicketFilter has no effect, since a request parameter has already been read by the WeldListener. So it there are other parts of Wicket relying on the request character encoding to be non-null, then this looks like a bug to me. Otherwise, if Wicket handles a null character encoding gracefully, then checkCharacterEncoding() is redundant, because it cannot be guaranteed to have any effect. Regards, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
type safe field references
Hi all
I am new to Wicket and investigating if usable for our project or not. I
have a minor question related to type safety and the creation of models. It
seems to me, that existing bean models are used by referencing the bean
fields using Strings, e.g.
public PojoStockQuotePage()
{
StockQuote quote = new StockQuote(IBM);
add(new Label(stockIBM, new PropertyModel(quote, quote));
}
I seem to remember, that I've seen an example of a Wicket extension, which
allows me to write type safe field references. Does any one have a clue,
which extension I stumbled into or how to perform type safe references?
Best regards,
Jesper
Re: type safe field references
Hi,
Perhaps this is what you're looking for?
http://code.google.com/p/bindgen-wicket/
add(new Label(state, new PropertyModel(person, address.state.code)));
becomes
add(new Label(state, new PropertyModel(person, new
PersonBinding().address().state().code().getPath(;
Type safe and refactor safe.
// Leo
Hi all
I am new to Wicket and investigating if usable for our project or not. I
have a minor question related to type safety and the creation of models.
It
seems to me, that existing bean models are used by referencing the bean
fields using Strings, e.g.
public PojoStockQuotePage()
{
StockQuote quote = new StockQuote(IBM);
add(new Label(stockIBM, new PropertyModel(quote, quote));
}
I seem to remember, that I've seen an example of a Wicket extension,
which
allows me to write type safe field references. Does any one have a clue,
which extension I stumbled into or how to perform type safe references?
How do I provide digit-only IDs to make childs safe?
Hi, I'm a new Wicket user who is also getting familiar with the GMap2 module from wicket-stuff. I'm using the geocode example as a basis for creating a form which allows you to search for a location and set the map viewport to display it: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/gmap2-parent/gmap2-examples/src/main/java/wicket/contrib/examples/gmap/geocode/ The code works, but every time I search for a place I get a warning: WARN - AbstractRepeater - Child component of repeater org.apache.wicket.markup.repeater.RepeatingView:content has a non-safe child id of [STRING_SEARCHED]. Safe child ids must be composed of digits only. The [STRING_SEARCHED] is whatever I typed in the text field (e.g. Barcelona, Spain or Athens, Greece). So apparently, GMap2 sets an ID somewhere using the text field's value, violating some Wicket expectation that such IDs should be composed using digits only. How can I fix this? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How do I provide digit-only IDs to make childs safe?
Hi Alexandros, it's just that the example uses the location's name as an id for a label shown as content in a GInfoWindowTab. See the following line in the example: new GInfoWindowTab(address, new Label(*address*, address)) The label will end up inside a repeater which is complaining about the id. Sven Alexandros Karypidis wrote: Hi, I'm a new Wicket user who is also getting familiar with the GMap2 module from wicket-stuff. I'm using the geocode example as a basis for creating a form which allows you to search for a location and set the map viewport to display it: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/gmap2-parent/gmap2-examples/src/main/java/wicket/contrib/examples/gmap/geocode/ The code works, but every time I search for a place I get a warning: WARN - AbstractRepeater - Child component of repeater org.apache.wicket.markup.repeater.RepeatingView:content has a non-safe child id of [STRING_SEARCHED]. Safe child ids must be composed of digits only. The [STRING_SEARCHED] is whatever I typed in the text field (e.g. Barcelona, Spain or Athens, Greece). So apparently, GMap2 sets an ID somewhere using the text field's value, violating some Wicket expectation that such IDs should be composed using digits only. How can I fix this? - 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: About a thread safe problem of the WebApplication class
It might be one idea to use concurrenthashmap. However, concurrenthashmap is API supported from JDK1.5. Moreover, I think that the Wicket1.3 series was JDK1.4 support. Therefore, I think that the method of exclusively controlling the method is suitable in this case(synchronized). -- View this message in context: http://www.nabble.com/About-a-thread-safe-problem-of-the-WebApplication-class-tp21154813p21156901.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
About a thread safe problem of the WebApplication class
The following errors occurred when the performance of the wicket application was tested. [Trace of error] [08/12/18 9:53:34:575 JST] 003e SystemOut O 2008-12-18 09:53:34,499 ERROR RequestCycle - concurrent access to HashMap attempted by Thread[WebContainer : 6,5,main] java.util.ConcurrentModificationException: concurrent access to HashMap attempted by Thread[WebContainer : 6,5,main] at java.util.HashMap.onExit(HashMap.java:217) at java.util.HashMap.transfer(HashMap.java:514) at java.util.HashMap.resize(HashMap.java:500) at java.util.HashMap.addEntry(HashMap.java:800) at java.util.HashMap.put(HashMap.java:441) at org.apache.wicket.protocol.http.WebApplication.addBufferedResponse(WebApplication.java:639) at org.apache.wicket.protocol.http.WebRequestCycle.redirectTo(WebRequestCycle.java:201) at org.apache.wicket.request.target.component.PageRequestTarget.respond(PageRequestTarget.java:58) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104) ・・・ [Test environment] OS:AIX5.3 TL005 +WAS6.1.0.21 Java:JDK1.5.0 Wicket:wicket1.3.5 [Consideration And Question] I think that it is a cause that the bufferedResponses instance of the WebApplication class is not the thread safe. The sessionDestroyed method and the addBufferedResponse method of the WebApplication class might have to be controlled exclusively(When these methods were declared in synchronized, the problem was canceled). - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: About a thread safe problem of the WebApplication class
Hmm weird nobody else seem to notice this before, we just should make it a concurrenthashmap On 24/12/2008, 加納充照 michiaki.ka...@gmail.com wrote: The following errors occurred when the performance of the wicket application was tested. [Trace of error] [08/12/18 9:53:34:575 JST] 003e SystemOut O 2008-12-18 09:53:34,499 ERROR RequestCycle - concurrent access to HashMap attempted by Thread[WebContainer : 6,5,main] java.util.ConcurrentModificationException: concurrent access to HashMap attempted by Thread[WebContainer : 6,5,main] at java.util.HashMap.onExit(HashMap.java:217) at java.util.HashMap.transfer(HashMap.java:514) at java.util.HashMap.resize(HashMap.java:500) at java.util.HashMap.addEntry(HashMap.java:800) at java.util.HashMap.put(HashMap.java:441) at org.apache.wicket.protocol.http.WebApplication.addBufferedResponse(WebApplication.java:639) at org.apache.wicket.protocol.http.WebRequestCycle.redirectTo(WebRequestCycle.java:201) at org.apache.wicket.request.target.component.PageRequestTarget.respond(PageRequestTarget.java:58) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104) ・・・ [Test environment] OS:AIX5.3 TL005 +WAS6.1.0.21 Java:JDK1.5.0 Wicket:wicket1.3.5 [Consideration And Question] I think that it is a cause that the bufferedResponses instance of the WebApplication class is not the thread safe. The sessionDestroyed method and the addBufferedResponse method of the WebApplication class might have to be controlled exclusively(When these methods were declared in synchronized, the problem was canceled). - 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: Is DynamicImageResource safe for multiple windows?
I found my problem in the end. There was an object that wasn't able to be correctly serialized (a JFreeChart object), which threw an error that, due to some mistake on my logging configuration I was hiding. Anyway, once I fixed the serialization problem, now everything is being correctly versioned and I don't see any problems with shared image resources. Thanks for the help! Michel On Fri, Aug 15, 2008 at 12:08 PM, Michel Goldstein [EMAIL PROTECTED] wrote: Building a sample to show the problem has been harder than I thought. Because on all bare-bones applications that I tried to build, the URLs end up being different (the counter on the interface seems to be working). What could make my larger application not increment the ?wicket:interface=:counter: count? That seems to be the source of my problem. On my application, it's always at 0. I'm using wicket 1.3.3 (which is the same version as the one I'm testing it with) and, besides a much deeper component tree, the only meaningful thing that is different on my application is that I initialize the SpringComponentInjector (which I don't think should be the issue, but it's good to mention). Thanks, Michel On Thu, Aug 14, 2008 at 10:26 PM, Michel Goldstein [EMAIL PROTECTED] wrote: As I mentioned, I basically used what was in the twiki about JFreeChart integration. I'll build a simple example of the problem and send it out sometime tomorrow (USA Pacific time). Thanks, Michel On Thu, Aug 14, 2008 at 7:59 PM, Timo Rantalaiho [EMAIL PROTECTED]wrote: On Thu, 14 Aug 2008, Michel Goldstein wrote: Spoke too soon... Unfortunately the problem still seems to be there even after I've added the NonCachingImage. This furthers the confirmation that it's not browser caching issue, but a resource sharing problem. From where does the image data come from, and when? You could show some code, preferably in an easily executable quickstart, and maybe someone could help you. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is DynamicImageResource safe for multiple windows?
Building a sample to show the problem has been harder than I thought. Because on all bare-bones applications that I tried to build, the URLs end up being different (the counter on the interface seems to be working). What could make my larger application not increment the ?wicket:interface=:counter: count? That seems to be the source of my problem. On my application, it's always at 0. I'm using wicket 1.3.3 (which is the same version as the one I'm testing it with) and, besides a much deeper component tree, the only meaningful thing that is different on my application is that I initialize the SpringComponentInjector (which I don't think should be the issue, but it's good to mention). Thanks, Michel On Thu, Aug 14, 2008 at 10:26 PM, Michel Goldstein [EMAIL PROTECTED] wrote: As I mentioned, I basically used what was in the twiki about JFreeChart integration. I'll build a simple example of the problem and send it out sometime tomorrow (USA Pacific time). Thanks, Michel On Thu, Aug 14, 2008 at 7:59 PM, Timo Rantalaiho [EMAIL PROTECTED]wrote: On Thu, 14 Aug 2008, Michel Goldstein wrote: Spoke too soon... Unfortunately the problem still seems to be there even after I've added the NonCachingImage. This furthers the confirmation that it's not browser caching issue, but a resource sharing problem. From where does the image data come from, and when? You could show some code, preferably in an easily executable quickstart, and maybe someone could help you. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is DynamicImageResource safe for multiple windows?
Hi, I have an application that generates different reports based on what the user selects. The report generation page is the same, but the reports vary. Part of the reports contain a DynamicImageResource (JFreeChart chart). Everything works great when a user is looking at a report at a time. But when multiple browser windows are open at the same time for the same user, each containing a different report, diagrams seem to get shared between reports, or sometimes are missing from some of them (broken resource). Looking at the generated URL, it looks like the problem must be with something more fundamental in the way I'm structuring my page, because the image URL seems to be fixed to the component tree: img src=../../../../?wicket:interface=:0:label_content:summaryPanelContainer:0:summaryPanel:processedHistory::IResourceListener:: wicket:id=processedHistory/ Which will always be the same between reports, so it's expected that they will show the same image (if I understand the rest of the architecture correctly). Is there something I'm missing here? To create the image, I followed what is in the wiki: http://cwiki.apache.org/WICKET/jfreechart-and-wicket-example.html Is there something missing there? Do I have to wrap my images on some container that will ensure that its path will be unique for each report? Or actually, is there a way to do that? As a more general Wicket architecture question, are resources session-specific, or are concurrent users also potentially sharing the resource too? I wasn't able to verify this correctly on my side because synchronizing different is harder than just ctrl-clicking on multiple report links on a same browser. Thanks and I apologize if this was already discussed before. I wasn't able to find any references to it. Michel
Re: Is DynamicImageResource safe for multiple windows?
are all the urls really exactly the same? is your pagesettings.automaticmultiwindowsupport enabled? -igor On Thu, Aug 14, 2008 at 10:30 AM, Michel Goldstein [EMAIL PROTECTED] wrote: Hi, I have an application that generates different reports based on what the user selects. The report generation page is the same, but the reports vary. Part of the reports contain a DynamicImageResource (JFreeChart chart). Everything works great when a user is looking at a report at a time. But when multiple browser windows are open at the same time for the same user, each containing a different report, diagrams seem to get shared between reports, or sometimes are missing from some of them (broken resource). Looking at the generated URL, it looks like the problem must be with something more fundamental in the way I'm structuring my page, because the image URL seems to be fixed to the component tree: img src=../../../../?wicket:interface=:0:label_content:summaryPanelContainer:0:summaryPanel:processedHistory::IResourceListener:: wicket:id=processedHistory/ Which will always be the same between reports, so it's expected that they will show the same image (if I understand the rest of the architecture correctly). Is there something I'm missing here? To create the image, I followed what is in the wiki: http://cwiki.apache.org/WICKET/jfreechart-and-wicket-example.html Is there something missing there? Do I have to wrap my images on some container that will ensure that its path will be unique for each report? Or actually, is there a way to do that? As a more general Wicket architecture question, are resources session-specific, or are concurrent users also potentially sharing the resource too? I wasn't able to verify this correctly on my side because synchronizing different is harder than just ctrl-clicking on multiple report links on a same browser. Thanks and I apologize if this was already discussed before. I wasn't able to find any references to it. Michel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is DynamicImageResource safe for multiple windows?
Q: are all the urls really exactly the same? Yes, they are exactly the same Q: is your pagesettings.automaticmultiwindowsupport enabled? Interesting. I didn't know of such setting. But I did change it in the application, adding: getPageSettings().setAutomaticMultiWindowSupport(true); but I'm still seeing the same behavior and the same URLs. Michel On Thu, Aug 14, 2008 at 11:15 AM, Igor Vaynberg [EMAIL PROTECTED]wrote: are all the urls really exactly the same? is your pagesettings.automaticmultiwindowsupport enabled? -igor On Thu, Aug 14, 2008 at 10:30 AM, Michel Goldstein [EMAIL PROTECTED] wrote: Hi, I have an application that generates different reports based on what the user selects. The report generation page is the same, but the reports vary. Part of the reports contain a DynamicImageResource (JFreeChart chart). Everything works great when a user is looking at a report at a time. But when multiple browser windows are open at the same time for the same user, each containing a different report, diagrams seem to get shared between reports, or sometimes are missing from some of them (broken resource). Looking at the generated URL, it looks like the problem must be with something more fundamental in the way I'm structuring my page, because the image URL seems to be fixed to the component tree: img src=../../../../?wicket:interface=:0:label_content:summaryPanelContainer:0:summaryPanel:processedHistory::IResourceListener:: wicket:id=processedHistory/ Which will always be the same between reports, so it's expected that they will show the same image (if I understand the rest of the architecture correctly). Is there something I'm missing here? To create the image, I followed what is in the wiki: http://cwiki.apache.org/WICKET/jfreechart-and-wicket-example.html Is there something missing there? Do I have to wrap my images on some container that will ensure that its path will be unique for each report? Or actually, is there a way to do that? As a more general Wicket architecture question, are resources session-specific, or are concurrent users also potentially sharing the resource too? I wasn't able to verify this correctly on my side because synchronizing different is harder than just ctrl-clicking on multiple report links on a same browser. Thanks and I apologize if this was already discussed before. I wasn't able to find any references to it. Michel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is DynamicImageResource safe for multiple windows?
I read a different thread that is going on right now about preventing image caching by using a NonCachingImage instead Image and seeing that it adds a random reference to the image, I thought it might help on my problem too. And, as far as I can tell, it actually did solve my problem too. Should the wiki be changed to use NonCachingImage or is it supposed to work with Image? I feel like it should, but I probably don't know the internals Wicket enough to make this call. Maybe my code was still missing something else. Thanks, Michel On Thu, Aug 14, 2008 at 12:01 PM, Michel Goldstein [EMAIL PROTECTED] wrote: Q: are all the urls really exactly the same? Yes, they are exactly the same Q: is your pagesettings.automaticmultiwindowsupport enabled? Interesting. I didn't know of such setting. But I did change it in the application, adding: getPageSettings().setAutomaticMultiWindowSupport(true); but I'm still seeing the same behavior and the same URLs. Michel On Thu, Aug 14, 2008 at 11:15 AM, Igor Vaynberg [EMAIL PROTECTED]wrote: are all the urls really exactly the same? is your pagesettings.automaticmultiwindowsupport enabled? -igor On Thu, Aug 14, 2008 at 10:30 AM, Michel Goldstein [EMAIL PROTECTED] wrote: Hi, I have an application that generates different reports based on what the user selects. The report generation page is the same, but the reports vary. Part of the reports contain a DynamicImageResource (JFreeChart chart). Everything works great when a user is looking at a report at a time. But when multiple browser windows are open at the same time for the same user, each containing a different report, diagrams seem to get shared between reports, or sometimes are missing from some of them (broken resource). Looking at the generated URL, it looks like the problem must be with something more fundamental in the way I'm structuring my page, because the image URL seems to be fixed to the component tree: img src=../../../../?wicket:interface=:0:label_content:summaryPanelContainer:0:summaryPanel:processedHistory::IResourceListener:: wicket:id=processedHistory/ Which will always be the same between reports, so it's expected that they will show the same image (if I understand the rest of the architecture correctly). Is there something I'm missing here? To create the image, I followed what is in the wiki: http://cwiki.apache.org/WICKET/jfreechart-and-wicket-example.html Is there something missing there? Do I have to wrap my images on some container that will ensure that its path will be unique for each report? Or actually, is there a way to do that? As a more general Wicket architecture question, are resources session-specific, or are concurrent users also potentially sharing the resource too? I wasn't able to verify this correctly on my side because synchronizing different is harder than just ctrl-clicking on multiple report links on a same browser. Thanks and I apologize if this was already discussed before. I wasn't able to find any references to it. Michel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is DynamicImageResource safe for multiple windows?
Spoke too soon... Unfortunately the problem still seems to be there even after I've added the NonCachingImage. This furthers the confirmation that it's not browser caching issue, but a resource sharing problem. Any ideas would be greatly appreciated. Thanks, Michel On Thu, Aug 14, 2008 at 1:18 PM, Michel Goldstein [EMAIL PROTECTED] wrote: I read a different thread that is going on right now about preventing image caching by using a NonCachingImage instead Image and seeing that it adds a random reference to the image, I thought it might help on my problem too. And, as far as I can tell, it actually did solve my problem too. Should the wiki be changed to use NonCachingImage or is it supposed to work with Image? I feel like it should, but I probably don't know the internals Wicket enough to make this call. Maybe my code was still missing something else. Thanks, Michel On Thu, Aug 14, 2008 at 12:01 PM, Michel Goldstein [EMAIL PROTECTED] wrote: Q: are all the urls really exactly the same? Yes, they are exactly the same Q: is your pagesettings.automaticmultiwindowsupport enabled? Interesting. I didn't know of such setting. But I did change it in the application, adding: getPageSettings().setAutomaticMultiWindowSupport(true); but I'm still seeing the same behavior and the same URLs. Michel On Thu, Aug 14, 2008 at 11:15 AM, Igor Vaynberg [EMAIL PROTECTED]wrote: are all the urls really exactly the same? is your pagesettings.automaticmultiwindowsupport enabled? -igor On Thu, Aug 14, 2008 at 10:30 AM, Michel Goldstein [EMAIL PROTECTED] wrote: Hi, I have an application that generates different reports based on what the user selects. The report generation page is the same, but the reports vary. Part of the reports contain a DynamicImageResource (JFreeChart chart). Everything works great when a user is looking at a report at a time. But when multiple browser windows are open at the same time for the same user, each containing a different report, diagrams seem to get shared between reports, or sometimes are missing from some of them (broken resource). Looking at the generated URL, it looks like the problem must be with something more fundamental in the way I'm structuring my page, because the image URL seems to be fixed to the component tree: img src=../../../../?wicket:interface=:0:label_content:summaryPanelContainer:0:summaryPanel:processedHistory::IResourceListener:: wicket:id=processedHistory/ Which will always be the same between reports, so it's expected that they will show the same image (if I understand the rest of the architecture correctly). Is there something I'm missing here? To create the image, I followed what is in the wiki: http://cwiki.apache.org/WICKET/jfreechart-and-wicket-example.html Is there something missing there? Do I have to wrap my images on some container that will ensure that its path will be unique for each report? Or actually, is there a way to do that? As a more general Wicket architecture question, are resources session-specific, or are concurrent users also potentially sharing the resource too? I wasn't able to verify this correctly on my side because synchronizing different is harder than just ctrl-clicking on multiple report links on a same browser. Thanks and I apologize if this was already discussed before. I wasn't able to find any references to it. Michel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is DynamicImageResource safe for multiple windows?
On Thu, 14 Aug 2008, Michel Goldstein wrote: Spoke too soon... Unfortunately the problem still seems to be there even after I've added the NonCachingImage. This furthers the confirmation that it's not browser caching issue, but a resource sharing problem. From where does the image data come from, and when? You could show some code, preferably in an easily executable quickstart, and maybe someone could help you. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is DynamicImageResource safe for multiple windows?
As I mentioned, I basically used what was in the twiki about JFreeChart integration. I'll build a simple example of the problem and send it out sometime tomorrow (USA Pacific time). Thanks, Michel On Thu, Aug 14, 2008 at 7:59 PM, Timo Rantalaiho [EMAIL PROTECTED]wrote: On Thu, 14 Aug 2008, Michel Goldstein wrote: Spoke too soon... Unfortunately the problem still seems to be there even after I've added the NonCachingImage. This furthers the confirmation that it's not browser caching issue, but a resource sharing problem. From where does the image data come from, and when? You could show some code, preferably in an easily executable quickstart, and maybe someone could help you. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is it safe to share static components across multiple page instances and request threads?
Hi, Is it threadsafe and wicket safe to share static Components across multiple instances of a Page (as well as across request threads) in wicket? Say for example I have a BookmarkablePageLink that takes no dynamic PageParameter arguments, can I create this as a static class member and share it across all instances of the Page on which it is used? (instead if creating a new instance for each new page). Rgs, Joel
Re: Is it safe to share static components across multiple page instances and request threads?
(BTW I am assuming that since each component has a parent that sharing is NOT allowed) -- From: Joel Halbert [EMAIL PROTECTED] Sent: Friday, June 20, 2008 9:29 AM To: users@wicket.apache.org Subject: Is it safe to share static components across multiple page instances and request threads? Hi, Is it threadsafe and wicket safe to share static Components across multiple instances of a Page (as well as across request threads) in wicket? Say for example I have a BookmarkablePageLink that takes no dynamic PageParameter arguments, can I create this as a static class member and share it across all instances of the Page on which it is used? (instead if creating a new instance for each new page). Rgs, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it safe to share static components across multiple page instances and request threads?
no On Fri, Jun 20, 2008 at 10:29 AM, Joel Halbert [EMAIL PROTECTED] wrote: Hi, Is it threadsafe and wicket safe to share static Components across multiple instances of a Page (as well as across request threads) in wicket? Say for example I have a BookmarkablePageLink that takes no dynamic PageParameter arguments, can I create this as a static class member and share it across all instances of the Page on which it is used? (instead if creating a new instance for each new page). Rgs, Joel -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is it safe to share static components across multiple page instances and request threads?
My guess would be no, since the object hierarchy of a page is a fundamental aspect of Wicket. I don't think that instances of Wicket Component objects are meant to be thread-safe and shared between different Component trees. There is all kinds of mutable data in Component that is not meant to be shared across threads. Creating a new instance of the link for every page would be the correct approach. -Original Message- From: Joel Halbert [mailto:[EMAIL PROTECTED] Sent: Friday, June 20, 2008 4:31 AM To: users@wicket.apache.org Subject: Re: Is it safe to share static components across multiple page instances and request threads? (BTW I am assuming that since each component has a parent that sharing is NOT allowed) -- From: Joel Halbert [EMAIL PROTECTED] Sent: Friday, June 20, 2008 9:29 AM To: users@wicket.apache.org Subject: Is it safe to share static components across multiple page instances and request threads? Hi, Is it threadsafe and wicket safe to share static Components across multiple instances of a Page (as well as across request threads) in wicket? Say for example I have a BookmarkablePageLink that takes no dynamic PageParameter arguments, can I create this as a static class member and share it across all instances of the Page on which it is used? (instead if creating a new instance for each new page). Rgs, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making your webapp thread safe
but you only have a assignment in our session, and that assignment you do when somebody logs in the first time. After that it isn't used. So the only problem i can see is that maybe when you person logs in AND does already another request in another pagemap/browser tab then that tab will not see that it is logged in and also redirect once more. But what does that matter because if the second tab did came a little bit earlier any way then that would still happen. Its not that the session object will be in an inconsitent state at some point. johan On Jan 31, 2008 11:57 PM, Dan Kaplan [EMAIL PROTECTED] wrote: I've been told by many people that the Session object is not thread safe. If that's true, I don't think the example can be thread safe. RestartResponseException does not allow you to redirect to an external URL (that's what that method does). That's why I can't use it. -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Thursday, January 31, 2008 12:18 PM To: users@wicket.apache.org Subject: Re: Making your webapp thread safe that looks fine i would throw a RestartResponseException in youre forcelogin method On Jan 31, 2008 8:48 PM, Dan Kaplan [EMAIL PROTECTED] wrote: Ok, I've asked this at least twice already but I'm still incredibly unsure of how to make my webapp thread safe. So this time I thought I'd take a different approach. I wrote on the wiki a short, unrelated example: http://cwiki.apache.org/confluence/display/WICKET/Facebook+Integration Is this example thread safe? If it isn't, please EDIT THE EXAMPLE TO MAKE IT SO. That way I can finally see a *complete* example of a thread safe webapp. Thanks a lot for any help ☺ Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Making your webapp thread safe
Ok, I’ve asked this at least twice already but I’m still incredibly unsure of how to make my webapp thread safe. So this time I thought I’d take a different approach. I wrote on the wiki a short, unrelated example: http://cwiki.apache.org/confluence/display/WICKET/Facebook+Integration Is this example thread safe? If it isn’t, please EDIT THE EXAMPLE TO MAKE IT SO. That way I can finally see a *complete* example of a thread safe webapp. Thanks a lot for any help ☺ Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making your webapp thread safe
that looks fine i would throw a RestartResponseException in youre forcelogin method On Jan 31, 2008 8:48 PM, Dan Kaplan [EMAIL PROTECTED] wrote: Ok, I've asked this at least twice already but I'm still incredibly unsure of how to make my webapp thread safe. So this time I thought I'd take a different approach. I wrote on the wiki a short, unrelated example: http://cwiki.apache.org/confluence/display/WICKET/Facebook+Integration Is this example thread safe? If it isn't, please EDIT THE EXAMPLE TO MAKE IT SO. That way I can finally see a *complete* example of a thread safe webapp. Thanks a lot for any help ☺ Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Making your webapp thread safe
I've been told by many people that the Session object is not thread safe. If that's true, I don't think the example can be thread safe. RestartResponseException does not allow you to redirect to an external URL (that's what that method does). That's why I can't use it. -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Thursday, January 31, 2008 12:18 PM To: users@wicket.apache.org Subject: Re: Making your webapp thread safe that looks fine i would throw a RestartResponseException in youre forcelogin method On Jan 31, 2008 8:48 PM, Dan Kaplan [EMAIL PROTECTED] wrote: Ok, I've asked this at least twice already but I'm still incredibly unsure of how to make my webapp thread safe. So this time I thought I'd take a different approach. I wrote on the wiki a short, unrelated example: http://cwiki.apache.org/confluence/display/WICKET/Facebook+Integration Is this example thread safe? If it isn't, please EDIT THE EXAMPLE TO MAKE IT SO. That way I can finally see a *complete* example of a thread safe webapp. Thanks a lot for any help ☺ Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is this safe?
Hi all, I wonder if this will work: add(new CartPanel(cart, new PropertyModel(s, cart))); where 's' is my app specific session, containing the method getCart() which checks the session for an existing cart, and if not found creates one. Is this enough to handle load/detach? Or do I have to write my own LoadableModel -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29
Re: Is this safe?
What would you like to detach? What is inside that card object? I guess thats a temp storage object of shopping items? Do remenber that getting the card object from the session isnt thread safe! (mutating it can be done from more then one thread if different pagemaps and so on are used) On 1/21/08, Martijn Lindhout [EMAIL PROTECTED] wrote: Hi all, I wonder if this will work: add(new CartPanel(cart, new PropertyModel(s, cart))); where 's' is my app specific session, containing the method getCart() which checks the session for an existing cart, and if not found creates one. Is this enough to handle load/detach? Or do I have to write my own LoadableModel -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is this safe?
ok, and if the session isn't thread safe, where do I store my temporal data? 2008/1/21, Johan Compagner [EMAIL PROTECTED]: The session. Because the property exp is used when you ask for the value On 1/21/08, Martijn Lindhout [EMAIL PROTECTED] wrote: you're right. It contains a shoppingcart. What is stored in the propertymodel, the session? Or the result of evaluating the expression s.cart - session.getCart(). And if the session isn't thread safe, where do I store my temporal data? 2008/1/21, Johan Compagner [EMAIL PROTECTED]: What would you like to detach? What is inside that card object? I guess thats a temp storage object of shopping items? Do remenber that getting the card object from the session isnt thread safe! (mutating it can be done from more then one thread if different pagemaps and so on are used) On 1/21/08, Martijn Lindhout [EMAIL PROTECTED] wrote: Hi all, I wonder if this will work: add(new CartPanel(cart, new PropertyModel(s, cart))); where 's' is my app specific session, containing the method getCart() which checks the session for an existing cart, and if not found creates one. Is this enough to handle load/detach? Or do I have to write my own LoadableModel -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29
Re: Is this safe?
you're right. It contains a shoppingcart. What is stored in the propertymodel, the session? Or the result of evaluating the expression s.cart - session.getCart(). And if the session isn't thread safe, where do I store my temporal data? 2008/1/21, Johan Compagner [EMAIL PROTECTED]: What would you like to detach? What is inside that card object? I guess thats a temp storage object of shopping items? Do remenber that getting the card object from the session isnt thread safe! (mutating it can be done from more then one thread if different pagemaps and so on are used) On 1/21/08, Martijn Lindhout [EMAIL PROTECTED] wrote: Hi all, I wonder if this will work: add(new CartPanel(cart, new PropertyModel(s, cart))); where 's' is my app specific session, containing the method getCart() which checks the session for an existing cart, and if not found creates one. Is this enough to handle load/detach? Or do I have to write my own LoadableModel -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29
Re: Is this safe?
The session. Because the property exp is used when you ask for the value On 1/21/08, Martijn Lindhout [EMAIL PROTECTED] wrote: you're right. It contains a shoppingcart. What is stored in the propertymodel, the session? Or the result of evaluating the expression s.cart - session.getCart(). And if the session isn't thread safe, where do I store my temporal data? 2008/1/21, Johan Compagner [EMAIL PROTECTED]: What would you like to detach? What is inside that card object? I guess thats a temp storage object of shopping items? Do remenber that getting the card object from the session isnt thread safe! (mutating it can be done from more then one thread if different pagemaps and so on are used) On 1/21/08, Martijn Lindhout [EMAIL PROTECTED] wrote: Hi all, I wonder if this will work: add(new CartPanel(cart, new PropertyModel(s, cart))); where 's' is my app specific session, containing the method getCart() which checks the session for an existing cart, and if not found creates one. Is this enough to handle load/detach? Or do I have to write my own LoadableModel -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is this safe?
custom request cycle? 2008/1/21, Martijn Dashorst [EMAIL PROTECTED]: Typically a custom request cycle for the actual object and store the key for getting access to the object in the session. If the cart is not a hibernate entity, but something really transient, I don't think there is any harm in putting it in the session, as long as you are certain you won't be doing resouce updates based on the session. Typically add/remove from carts are single requests that are synchronized on the session. As for the property model, you can do this as well: add(new ShoppingCartPanel(panel, new PropertyModel(this, session.cart ))); Martijn On 1/21/08, Martijn Lindhout [EMAIL PROTECTED] wrote: ok, and if the session isn't thread safe, where do I store my temporal data? 2008/1/21, Johan Compagner [EMAIL PROTECTED]: The session. Because the property exp is used when you ask for the value On 1/21/08, Martijn Lindhout [EMAIL PROTECTED] wrote: you're right. It contains a shoppingcart. What is stored in the propertymodel, the session? Or the result of evaluating the expression s.cart - session.getCart(). And if the session isn't thread safe, where do I store my temporal data? 2008/1/21, Johan Compagner [EMAIL PROTECTED]: What would you like to detach? What is inside that card object? I guess thats a temp storage object of shopping items? Do remenber that getting the card object from the session isnt thread safe! (mutating it can be done from more then one thread if different pagemaps and so on are used) On 1/21/08, Martijn Lindhout [EMAIL PROTECTED] wrote: Hi all, I wonder if this will work: add(new CartPanel(cart, new PropertyModel(s, cart))); where 's' is my app specific session, containing the method getCart() which checks the session for an existing cart, and if not found creates one. Is this enough to handle load/detach? Or do I have to write my own LoadableModel -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29 -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29
Re: Is this safe?
On Jan 21, 2008 1:51 AM, Martijn Lindhout [EMAIL PROTECTED] wrote: ok, and if the session isn't thread safe, where do I store my temporal data? I think the session is a fine storage option for a shopping cart. Just synchronize the cart itself and you're fine. Or don't; it's rather unlikely you actually run into trouble if you ask me. Btw, add(new CartPanel(cart, new PropertyModel(this, session.cart))); also works, since components have a getSession method. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Type safe roles for AUTH-ROLES?
heh. it is a functional example of a fully implemented authorization
strategy. but it doesnt have any fancy features, nor will they be
added to it in the future. it is meant to serve as an example, so
users can see how to implement their own authorization strategies.
what more do you want me to say exactly?
-igor
On Jan 14, 2008 1:51 PM, Dan Kaplan [EMAIL PROTECTED] wrote:
What? Really? Fuck. Can you please elaborate? Did I waste every second
of the time I spent looking at the examples on wicketstuff? I applied these
examples to my webapp. Did I implement some type of pretend authorization
strategy?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 12, 2008 10:31 AM
To: users@wicket.apache.org; [EMAIL PROTECTED]
Subject: Re: Type safe roles for AUTH-ROLES?
wicket-auth-roles is just an example. its not really meant to be
something you drop into your application, for that there is
wicketstuff-wasp and wicketstuff-swarm
-igor
On Jan 12, 2008 9:14 AM, Jeremy Thomerson [EMAIL PROTECTED]
wrote:
I have several successful Wicket projects going, and in all have used my
own
authorization strategy based on annotations. I'm just trying
wicket-auth-roles for my next project, but seem confused by the apparent
String-only roles. I already have a domain model where a User has a Role
or
Role(s), where Role is a class. This promotes type-safety, etc, etc.
But, I can't go:
@AuthorizeInstantiation({ Role.ADMIN, Role.SUPER_USER,
Role.MEMBER_SERVICE_REP, Role.MEMBER })
I also can't do:
@AuthorizeInstantiation({ Role.ADMIN.name(), Role.SUPER_USER.name (),
Role.MEMBER_SERVICE_REP.name(), Role.MEMBER.name() })
So, do I *have* to use Strings? Or is there another way? If I have to
use
Strings, then I either have to redefine all my roles and change how the DB
stores them, or just use the names of my own roles (i.e . SUPER_USER
which
later my UserAuthorizer does a Role.valueOf(String) on), and risk typoes
messing me up, or have Role.SUPER_USER and Role.SUPER_USER_NAME as a
public
static final String.
It's been a long week - I could be missing something.
Thanks in advance.
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Type safe roles for AUTH-ROLES?
What? Really? Fuck. Can you please elaborate? Did I waste every second
of the time I spent looking at the examples on wicketstuff? I applied these
examples to my webapp. Did I implement some type of pretend authorization
strategy?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 12, 2008 10:31 AM
To: users@wicket.apache.org; [EMAIL PROTECTED]
Subject: Re: Type safe roles for AUTH-ROLES?
wicket-auth-roles is just an example. its not really meant to be
something you drop into your application, for that there is
wicketstuff-wasp and wicketstuff-swarm
-igor
On Jan 12, 2008 9:14 AM, Jeremy Thomerson [EMAIL PROTECTED]
wrote:
I have several successful Wicket projects going, and in all have used my
own
authorization strategy based on annotations. I'm just trying
wicket-auth-roles for my next project, but seem confused by the apparent
String-only roles. I already have a domain model where a User has a Role
or
Role(s), where Role is a class. This promotes type-safety, etc, etc.
But, I can't go:
@AuthorizeInstantiation({ Role.ADMIN, Role.SUPER_USER,
Role.MEMBER_SERVICE_REP, Role.MEMBER })
I also can't do:
@AuthorizeInstantiation({ Role.ADMIN.name(), Role.SUPER_USER.name (),
Role.MEMBER_SERVICE_REP.name(), Role.MEMBER.name() })
So, do I *have* to use Strings? Or is there another way? If I have to
use
Strings, then I either have to redefine all my roles and change how the DB
stores them, or just use the names of my own roles (i.e . SUPER_USER
which
later my UserAuthorizer does a Role.valueOf(String) on), and risk typoes
messing me up, or have Role.SUPER_USER and Role.SUPER_USER_NAME as a
public
static final String.
It's been a long week - I could be missing something.
Thanks in advance.
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Type safe roles for AUTH-ROLES?
In my opinion there is nothing 'wrong' with auth-roles. but they are
limited in scope. Fortunately the code base is really small so it
wouldn't take that much effort to roll your own based on that code.
That said, I think that a lot of applications can live with the 3
levels of authorization: none, user and admin provided by auth-roles.
Martijn
(who likes using auth-roles)
On 1/14/08, Dan Kaplan [EMAIL PROTECTED] wrote:
I guess I'll have to read about swarm/wasp to read about what fancy features
I'm missing out on. But, ATM, I'm content to stay with it because
auth-roles are simple and allow me to move on to the actual content of my
webapp. Am I going to be kicking myself later for that choice?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Monday, January 14, 2008 1:55 PM
To: users@wicket.apache.org
Subject: Re: Type safe roles for AUTH-ROLES?
heh. it is a functional example of a fully implemented authorization
strategy. but it doesnt have any fancy features, nor will they be
added to it in the future. it is meant to serve as an example, so
users can see how to implement their own authorization strategies.
what more do you want me to say exactly?
-igor
On Jan 14, 2008 1:51 PM, Dan Kaplan [EMAIL PROTECTED] wrote:
What? Really? Fuck. Can you please elaborate? Did I waste every second
of the time I spent looking at the examples on wicketstuff? I applied
these
examples to my webapp. Did I implement some type of pretend
authorization
strategy?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 12, 2008 10:31 AM
To: users@wicket.apache.org; [EMAIL PROTECTED]
Subject: Re: Type safe roles for AUTH-ROLES?
wicket-auth-roles is just an example. its not really meant to be
something you drop into your application, for that there is
wicketstuff-wasp and wicketstuff-swarm
-igor
On Jan 12, 2008 9:14 AM, Jeremy Thomerson [EMAIL PROTECTED]
wrote:
I have several successful Wicket projects going, and in all have used my
own
authorization strategy based on annotations. I'm just trying
wicket-auth-roles for my next project, but seem confused by the apparent
String-only roles. I already have a domain model where a User has a
Role
or
Role(s), where Role is a class. This promotes type-safety, etc, etc.
But, I can't go:
@AuthorizeInstantiation({ Role.ADMIN, Role.SUPER_USER,
Role.MEMBER_SERVICE_REP, Role.MEMBER })
I also can't do:
@AuthorizeInstantiation({ Role.ADMIN.name(), Role.SUPER_USER.name (),
Role.MEMBER_SERVICE_REP.name(), Role.MEMBER.name() })
So, do I *have* to use Strings? Or is there another way? If I have to
use
Strings, then I either have to redefine all my roles and change how the
DB
stores them, or just use the names of my own roles (i.e . SUPER_USER
which
later my UserAuthorizer does a Role.valueOf(String) on), and risk typoes
messing me up, or have Role.SUPER_USER and Role.SUPER_USER_NAME as a
public
static final String.
It's been a long week - I could be missing something.
Thanks in advance.
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Type safe roles for AUTH-ROLES?
Sure, and although not an included option, can't I just make a new one named
moderator and use that where I want? I haven't tried this but I assume
the library won't care.
-Original Message-
From: Martijn Dashorst [mailto:[EMAIL PROTECTED]
Sent: Monday, January 14, 2008 2:22 PM
To: users@wicket.apache.org
Subject: Re: Type safe roles for AUTH-ROLES?
In my opinion there is nothing 'wrong' with auth-roles. but they are
limited in scope. Fortunately the code base is really small so it
wouldn't take that much effort to roll your own based on that code.
That said, I think that a lot of applications can live with the 3
levels of authorization: none, user and admin provided by auth-roles.
Martijn
(who likes using auth-roles)
On 1/14/08, Dan Kaplan [EMAIL PROTECTED] wrote:
I guess I'll have to read about swarm/wasp to read about what fancy
features
I'm missing out on. But, ATM, I'm content to stay with it because
auth-roles are simple and allow me to move on to the actual content of my
webapp. Am I going to be kicking myself later for that choice?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Monday, January 14, 2008 1:55 PM
To: users@wicket.apache.org
Subject: Re: Type safe roles for AUTH-ROLES?
heh. it is a functional example of a fully implemented authorization
strategy. but it doesnt have any fancy features, nor will they be
added to it in the future. it is meant to serve as an example, so
users can see how to implement their own authorization strategies.
what more do you want me to say exactly?
-igor
On Jan 14, 2008 1:51 PM, Dan Kaplan [EMAIL PROTECTED] wrote:
What? Really? Fuck. Can you please elaborate? Did I waste every
second
of the time I spent looking at the examples on wicketstuff? I applied
these
examples to my webapp. Did I implement some type of pretend
authorization
strategy?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 12, 2008 10:31 AM
To: users@wicket.apache.org; [EMAIL PROTECTED]
Subject: Re: Type safe roles for AUTH-ROLES?
wicket-auth-roles is just an example. its not really meant to be
something you drop into your application, for that there is
wicketstuff-wasp and wicketstuff-swarm
-igor
On Jan 12, 2008 9:14 AM, Jeremy Thomerson [EMAIL PROTECTED]
wrote:
I have several successful Wicket projects going, and in all have used
my
own
authorization strategy based on annotations. I'm just trying
wicket-auth-roles for my next project, but seem confused by the
apparent
String-only roles. I already have a domain model where a User has a
Role
or
Role(s), where Role is a class. This promotes type-safety, etc, etc.
But, I can't go:
@AuthorizeInstantiation({ Role.ADMIN, Role.SUPER_USER,
Role.MEMBER_SERVICE_REP, Role.MEMBER })
I also can't do:
@AuthorizeInstantiation({ Role.ADMIN.name(), Role.SUPER_USER.name (),
Role.MEMBER_SERVICE_REP.name(), Role.MEMBER.name() })
So, do I *have* to use Strings? Or is there another way? If I have
to
use
Strings, then I either have to redefine all my roles and change how
the
DB
stores them, or just use the names of my own roles (i.e . SUPER_USER
which
later my UserAuthorizer does a Role.valueOf(String) on), and risk
typoes
messing me up, or have Role.SUPER_USER and Role.SUPER_USER_NAME as a
public
static final String.
It's been a long week - I could be missing something.
Thanks in advance.
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Type safe roles for AUTH-ROLES?
I guess I'll have to read about swarm/wasp to read about what fancy features
I'm missing out on. But, ATM, I'm content to stay with it because
auth-roles are simple and allow me to move on to the actual content of my
webapp. Am I going to be kicking myself later for that choice?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Monday, January 14, 2008 1:55 PM
To: users@wicket.apache.org
Subject: Re: Type safe roles for AUTH-ROLES?
heh. it is a functional example of a fully implemented authorization
strategy. but it doesnt have any fancy features, nor will they be
added to it in the future. it is meant to serve as an example, so
users can see how to implement their own authorization strategies.
what more do you want me to say exactly?
-igor
On Jan 14, 2008 1:51 PM, Dan Kaplan [EMAIL PROTECTED] wrote:
What? Really? Fuck. Can you please elaborate? Did I waste every second
of the time I spent looking at the examples on wicketstuff? I applied
these
examples to my webapp. Did I implement some type of pretend
authorization
strategy?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 12, 2008 10:31 AM
To: users@wicket.apache.org; [EMAIL PROTECTED]
Subject: Re: Type safe roles for AUTH-ROLES?
wicket-auth-roles is just an example. its not really meant to be
something you drop into your application, for that there is
wicketstuff-wasp and wicketstuff-swarm
-igor
On Jan 12, 2008 9:14 AM, Jeremy Thomerson [EMAIL PROTECTED]
wrote:
I have several successful Wicket projects going, and in all have used my
own
authorization strategy based on annotations. I'm just trying
wicket-auth-roles for my next project, but seem confused by the apparent
String-only roles. I already have a domain model where a User has a
Role
or
Role(s), where Role is a class. This promotes type-safety, etc, etc.
But, I can't go:
@AuthorizeInstantiation({ Role.ADMIN, Role.SUPER_USER,
Role.MEMBER_SERVICE_REP, Role.MEMBER })
I also can't do:
@AuthorizeInstantiation({ Role.ADMIN.name(), Role.SUPER_USER.name (),
Role.MEMBER_SERVICE_REP.name(), Role.MEMBER.name() })
So, do I *have* to use Strings? Or is there another way? If I have to
use
Strings, then I either have to redefine all my roles and change how the
DB
stores them, or just use the names of my own roles (i.e . SUPER_USER
which
later my UserAuthorizer does a Role.valueOf(String) on), and risk typoes
messing me up, or have Role.SUPER_USER and Role.SUPER_USER_NAME as a
public
static final String.
It's been a long week - I could be missing something.
Thanks in advance.
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Type safe roles for AUTH-ROLES?
for a comparison between auth-roles and swarm/wasp, take a look at http://wicketstuff.org/confluence/display/STUFFWIKI/Security+Framework+Comparison gerolf On Jan 14, 2008 11:14 PM, C. Bergström [EMAIL PROTECTED] wrote: On Mon, 2008-01-14 at 13:51 -0800, Dan Kaplan wrote: What? Really? F***. Can you please elaborate? Did I waste every second of the time I spent looking at the examples on wicketstuff? I applied these examples to my webapp. Did I implement some type of pretend authorization strategy? http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security +Examples Sources are available here.. https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-security-examples maybe this is more in the ballpark of what you were expecting? ./C - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Type safe roles for AUTH-ROLES?
No, I'm perfectly happy with the functionality provided by the examples on wicketstuff. I just want to make sure they are secure. I don't want to use them if they're giving me a false sense of security. -Original Message- From: C. Bergström [mailto:[EMAIL PROTECTED] Sent: Monday, January 14, 2008 2:15 PM To: users@wicket.apache.org Subject: RE: Type safe roles for AUTH-ROLES? On Mon, 2008-01-14 at 13:51 -0800, Dan Kaplan wrote: What? Really? F***. Can you please elaborate? Did I waste every second of the time I spent looking at the examples on wicketstuff? I applied these examples to my webapp. Did I implement some type of pretend authorization strategy? http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security +Examples Sources are available here.. https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-s ecurity-examples maybe this is more in the ballpark of what you were expecting? ./C - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Type safe roles for AUTH-ROLES?
I have several successful Wicket projects going, and in all have used my own
authorization strategy based on annotations. I'm just trying
wicket-auth-roles for my next project, but seem confused by the apparent
String-only roles. I already have a domain model where a User has a Role or
Role(s), where Role is a class. This promotes type-safety, etc, etc.
But, I can't go:
@AuthorizeInstantiation({ Role.ADMIN, Role.SUPER_USER,
Role.MEMBER_SERVICE_REP, Role.MEMBER })
I also can't do:
@AuthorizeInstantiation({ Role.ADMIN.name(), Role.SUPER_USER.name (),
Role.MEMBER_SERVICE_REP.name(), Role.MEMBER.name() })
So, do I *have* to use Strings? Or is there another way? If I have to use
Strings, then I either have to redefine all my roles and change how the DB
stores them, or just use the names of my own roles (i.e . SUPER_USER which
later my UserAuthorizer does a Role.valueOf(String) on), and risk typoes
messing me up, or have Role.SUPER_USER and Role.SUPER_USER_NAME as a public
static final String.
It's been a long week - I could be missing something.
Thanks in advance.
Jeremy
Re: Type safe roles for AUTH-ROLES?
wicket-auth-roles is just an example. its not really meant to be
something you drop into your application, for that there is
wicketstuff-wasp and wicketstuff-swarm
-igor
On Jan 12, 2008 9:14 AM, Jeremy Thomerson [EMAIL PROTECTED] wrote:
I have several successful Wicket projects going, and in all have used my own
authorization strategy based on annotations. I'm just trying
wicket-auth-roles for my next project, but seem confused by the apparent
String-only roles. I already have a domain model where a User has a Role or
Role(s), where Role is a class. This promotes type-safety, etc, etc.
But, I can't go:
@AuthorizeInstantiation({ Role.ADMIN, Role.SUPER_USER,
Role.MEMBER_SERVICE_REP, Role.MEMBER })
I also can't do:
@AuthorizeInstantiation({ Role.ADMIN.name(), Role.SUPER_USER.name (),
Role.MEMBER_SERVICE_REP.name(), Role.MEMBER.name() })
So, do I *have* to use Strings? Or is there another way? If I have to use
Strings, then I either have to redefine all my roles and change how the DB
stores them, or just use the names of my own roles (i.e . SUPER_USER which
later my UserAuthorizer does a Role.valueOf(String) on), and risk typoes
messing me up, or have Role.SUPER_USER and Role.SUPER_USER_NAME as a public
static final String.
It's been a long week - I could be missing something.
Thanks in advance.
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
