You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Marvan Spagnolo <ma...@gmail.com> on 2008/08/25 13:04:04 UTC

application scope objects in Wicket

Hi all, I'm new to Wicket and developing my first Wicket website.
I have some temporary objects created inside a users' session but needed by
a parallel process which uses them
outside the user session and I would like to avoid temporarily persisting
them into a database.

I'm looking at using application scope objects but I'm not sure how to do it
best
in Wicket.

I guess I should override the get() method of WebApplication
mimicking the pattern used for custom Session objects.

public class WicketApplication extends MyWebApplication
{
 private Object applicationScopeObject;

public WicketApplication() {
setApplicationScopeObject( <init value> );
}
 @Override
public static WicketApplication get() {
return (WicketApplication) WebApplication.get();
}
 public Object getApplicationScopeObject(){
return this.applicationScopeObject;
}
 public void setApplicationScopeObject( Object applicationScopeObject ){
this.applicationScopeObject = applicationScopeObject;
}
 [...]
}

public class PageInsideUserSession
{
public PageInsideUserSession(){
 [...]
// object has already been initialized
WicketApplication.get().setApplicationScopeObject( object );
}
}

public class PageOutsideUserSession
{
public PageOutsideUserSession(){
Object object = WicketApplication.get().getApplicationScopeObject();
[...]
}
}

In my case synchronizing the access to the application scope object should
not be needed.

Is this approach correct (and efficient) or is there a better solution ?
Should I maybe use a separate parent class (parent of WicketApplication and
child of WebApplication) for
overriding the get() method (in case the override interferes with something
else in the framework) ?

Cheers,

Marvan

-- 
Reza Marvan Spagnolo
SW Engineer - Freelancer

Re: application scope objects in Wicket

Posted by Jeremy Thomerson <je...@wickettraining.com>.
If I understood your use correctly, this approach won't work if there are
two users using the application concurrently - you would overwrite one's
application-scoped object with another....  Right?  There is only one
application per application - not per session.


-- 
Jeremy Thomerson
http://www.wickettraining.com


On Mon, Aug 25, 2008 at 6:04 AM, Marvan Spagnolo <ma...@gmail.com> wrote:

> Hi all, I'm new to Wicket and developing my first Wicket website.
> I have some temporary objects created inside a users' session but needed by
> a parallel process which uses them
> outside the user session and I would like to avoid temporarily persisting
> them into a database.
>
> I'm looking at using application scope objects but I'm not sure how to do
> it
> best
> in Wicket.
>
> I guess I should override the get() method of WebApplication
> mimicking the pattern used for custom Session objects.
>
> public class WicketApplication extends MyWebApplication
> {
>  private Object applicationScopeObject;
>
> public WicketApplication() {
> setApplicationScopeObject( <init value> );
> }
>  @Override
> public static WicketApplication get() {
> return (WicketApplication) WebApplication.get();
> }
>  public Object getApplicationScopeObject(){
> return this.applicationScopeObject;
> }
>  public void setApplicationScopeObject( Object applicationScopeObject ){
> this.applicationScopeObject = applicationScopeObject;
> }
>  [...]
> }
>
> public class PageInsideUserSession
> {
> public PageInsideUserSession(){
>  [...]
> // object has already been initialized
> WicketApplication.get().setApplicationScopeObject( object );
> }
> }
>
> public class PageOutsideUserSession
> {
> public PageOutsideUserSession(){
> Object object = WicketApplication.get().getApplicationScopeObject();
> [...]
> }
> }
>
> In my case synchronizing the access to the application scope object should
> not be needed.
>
> Is this approach correct (and efficient) or is there a better solution ?
> Should I maybe use a separate parent class (parent of WicketApplication and
> child of WebApplication) for
> overriding the get() method (in case the override interferes with something
> else in the framework) ?
>
> Cheers,
>
> Marvan
>
> --
> Reza Marvan Spagnolo
> SW Engineer - Freelancer
>

Re: application scope objects in Wicket

Posted by Reza Marvan Spagnolo <ma...@gmail.com>.
Thank you both for your answers, Jeremy and James.

The data structure I'll use in the real case will be a collection of 
objects with
one object for each of the user sessions.

That same object will be accessed only once outside the user session
and then it will be erased. There won't be 2 threads accessing the same 
object in the collection
at the same time but they will access the collection object itself 
concurrently (even if on separate elements).

That's why I thought about using synchronized methods only for removing, 
setting and adding an element in the Collection,
I hope this will work correctly without affecting the performance of the 
WebApplication object.
Don't know if I should incapsulate the collection in another object 
member of WebApplication and implement the synchronized methods
inside it.

I didn't post these details because my doubt was really on the 
correctness of overriding the get() method of WebApplication
to enable the use of application scope objects.

Thanks for the advice and cheers,

Marvan





> James Perry wrote:
>> Firstly I hope you are enjoying building your first Wicket web app.
>>
>> Is this application scope object immutable? What is the data structure?
>>
>> IMHO, if it's immutable then it's OK to use composition within your
>> WebApplication by adding this object as a field within WebApplication.
>> I would just make it final so it never gets incorrectly pointed to a
>> different object once initialized.
>>
>> However if this has mutable shared data, then do not use the
>> WebApplication's intrinsic lock as you will jeopardize its throughput
>> to process requests. For example:
>>
>> public class FooBarApplication extends WebApplication {
>>
>> private MyAppScopeObject appScopeObject;
>>
>> public synchronized MyAppScopeObject getAppScopeObject(){
>>      return appScopeObject;
>> }
>>
>> public synchronized void setAppScopeObject(MyAppScopeObject appScopeObject) {
>>     this.appScopeObject = appScopeObject;
>> }
>>
>> }
>>
>> Instead, use your application-scope object's intrinsic lock or use a
>> suitable mutex in the Java 5/6 API.
>>
>> Best,
>> James.
>>
>> On Mon, Aug 25, 2008 at 12:04 PM, Marvan Spagnolo <ma...@gmail.com> wrote:
>>   
>>> Hi all, I'm new to Wicket and developing my first Wicket website.
>>> I have some temporary objects created inside a users' session but needed by
>>> a parallel process which uses them
>>> outside the user session and I would like to avoid temporarily persisting
>>> them into a database.
>>>
>>> I'm looking at using application scope objects but I'm not sure how to do it
>>> best
>>> in Wicket.
>>>
>>> I guess I should override the get() method of WebApplication
>>> mimicking the pattern used for custom Session objects.
>>>
>>> public class WicketApplication extends MyWebApplication
>>> {
>>>  private Object applicationScopeObject;
>>>
>>> public WicketApplication() {
>>> setApplicationScopeObject( <init value> );
>>> }
>>>  @Override
>>> public static WicketApplication get() {
>>> return (WicketApplication) WebApplication.get();
>>> }
>>>  public Object getApplicationScopeObject(){
>>> return this.applicationScopeObject;
>>> }
>>>  public void setApplicationScopeObject( Object applicationScopeObject ){
>>> this.applicationScopeObject = applicationScopeObject;
>>> }
>>>  [...]
>>> }
>>>
>>> public class PageInsideUserSession
>>> {
>>> public PageInsideUserSession(){
>>>  [...]
>>> // object has already been initialized
>>> WicketApplication.get().setApplicationScopeObject( object );
>>> }
>>> }
>>>
>>> public class PageOutsideUserSession
>>> {
>>> public PageOutsideUserSession(){
>>> Object object = WicketApplication.get().getApplicationScopeObject();
>>> [...]
>>> }
>>> }
>>>
>>> In my case synchronizing the access to the application scope object should
>>> not be needed.
>>>
>>> Is this approach correct (and efficient) or is there a better solution ?
>>> Should I maybe use a separate parent class (parent of WicketApplication and
>>> child of WebApplication) for
>>> overriding the get() method (in case the override interferes with something
>>> else in the framework) ?
>>>
>>> Cheers,
>>>
>>> Marvan
>>>
>>> --
>>> Reza Marvan Spagnolo
>>> SW Engineer - Freelancer
>>>
>>>     
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>   

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


Re: application scope objects in Wicket

Posted by James Perry <ja...@gmail.com>.
Firstly I hope you are enjoying building your first Wicket web app.

Is this application scope object immutable? What is the data structure?

IMHO, if it's immutable then it's OK to use composition within your
WebApplication by adding this object as a field within WebApplication.
I would just make it final so it never gets incorrectly pointed to a
different object once initialized.

However if this has mutable shared data, then do not use the
WebApplication's intrinsic lock as you will jeopardize its throughput
to process requests. For example:

public class FooBarApplication extends WebApplication {

private MyAppScopeObject appScopeObject;

public synchronized MyAppScopeObject getAppScopeObject(){
     return appScopeObject;
}

public synchronized void setAppScopeObject(MyAppScopeObject appScopeObject) {
    this.appScopeObject = appScopeObject;
}

}

Instead, use your application-scope object's intrinsic lock or use a
suitable mutex in the Java 5/6 API.

Best,
James.

On Mon, Aug 25, 2008 at 12:04 PM, Marvan Spagnolo <ma...@gmail.com> wrote:
> Hi all, I'm new to Wicket and developing my first Wicket website.
> I have some temporary objects created inside a users' session but needed by
> a parallel process which uses them
> outside the user session and I would like to avoid temporarily persisting
> them into a database.
>
> I'm looking at using application scope objects but I'm not sure how to do it
> best
> in Wicket.
>
> I guess I should override the get() method of WebApplication
> mimicking the pattern used for custom Session objects.
>
> public class WicketApplication extends MyWebApplication
> {
>  private Object applicationScopeObject;
>
> public WicketApplication() {
> setApplicationScopeObject( <init value> );
> }
>  @Override
> public static WicketApplication get() {
> return (WicketApplication) WebApplication.get();
> }
>  public Object getApplicationScopeObject(){
> return this.applicationScopeObject;
> }
>  public void setApplicationScopeObject( Object applicationScopeObject ){
> this.applicationScopeObject = applicationScopeObject;
> }
>  [...]
> }
>
> public class PageInsideUserSession
> {
> public PageInsideUserSession(){
>  [...]
> // object has already been initialized
> WicketApplication.get().setApplicationScopeObject( object );
> }
> }
>
> public class PageOutsideUserSession
> {
> public PageOutsideUserSession(){
> Object object = WicketApplication.get().getApplicationScopeObject();
> [...]
> }
> }
>
> In my case synchronizing the access to the application scope object should
> not be needed.
>
> Is this approach correct (and efficient) or is there a better solution ?
> Should I maybe use a separate parent class (parent of WicketApplication and
> child of WebApplication) for
> overriding the get() method (in case the override interferes with something
> else in the framework) ?
>
> Cheers,
>
> Marvan
>
> --
> Reza Marvan Spagnolo
> SW Engineer - Freelancer
>

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