Re: JPA annotations
check http://jeff-schwartz.blogspot.nl/2011/03/java-ee6-wicket.html its a good series of articles about using Java EE and wicket I Haven't Lost My Mind - It's Backed Up On Disk Somewhere On Fri, Dec 21, 2012 at 1:30 PM, Lucio Crusca lu...@sulweb.org wrote: Hello *, I've started this short thread on the tomEE users ml: http://markmail.org/message/3asqvvptnkieknq5 The final answer sounds to me like if you want to use resources injection through JPA annotations in a wicket application, your best bet is Java-EE- Inject https://github.com/wicketstuff/core/wiki/Java-EE-Inject which in turn states that: With JavaEE Inject you can use in your wicket components three annotations: @EJB, @PersistenceUnit, @Resource. What about @Entity, @Table, @Id, @GeneratedValue and friends? What's the simplest way to use JPA annotations and dependency injection threreof in a wicket application? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA annotations
Hi, I really don't understand your question. You want to know how to get jpa-annotations to work. Well, you just need to get hold of an entitymanager. If you ask me, go with spring, it's easier than jee or even Guice. Regards Martin -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/JPA-annotations-tp4655001p4655025.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Attempting to establish session for static resources in Wicket 6
I don't remember quite well how it used to work with 1.5, but looking at
your stacktrace I see you used some kind of redirection policy that
involves class RestartResponseAtInterceptPageException. This class needs
to build a permanent session as you can see in its method InterceptData.set:
public static void set()
{
Session session = Session.get();
session.bind();
So the creation of a new session is not a question of static resources,
but rather a consequence of RestartResponseAtInterceptPageException.
But as I said I don't remember if 1.5 works differently.
A while ago when working with Wicket 1.5 we raised issue 4334 that dealt
with the problem of jsessoin ID's being present in static resource URLs
for the initial request and this issue was fixed.
Not requiring jsession ID in the URL meant there was no reason to ever
establish a session during requests for static resources i.e.
WebApplication#newSession was never called for static resource requests.
This worked very well but we've just discovered that in Wicket 6, even
though the URLs for static resources do not contain jsessionIDs there is
some code that is calling getSession - unnecessarily we believe (we hope
=] ).
Is there any reason why WebApplicatoin#newSession is called when no
session is required to service the static request? If not it would be
great if that call could be avoided.
Calling WebApplication#newSession on static resources becomes a problem
when you employ OpenSessionInView/OpenPersistenceManagerInView by using
a filter to wrap all Wicket requests within the context of an open
persistence session/manager. To optimize performance we use an 'ignore
list' that avoids wrapping the request if it is for a resource that
starts with a particular pattern (eg., /wicket/resource,/robots.txt)
We override WebApplication#newSession and do some fancy things whenever
a new session is established - this is intended for non static resource
requests. Some of this code assumes that there is an OpenSessionInView -
which fails in the case of static resources because their URLs are part
of the ignore list and so the request was not wrapped within an open
persistence session/manager.
I was hoping that Wicket 6 could be fixed to avoid the call to
newSession like Wicket 1.5 did after the resolution of 4334.
Here's a stack trace of a call that is servicing a request for a wicket
static resource:
2012/12/23 23:16:24.607 ERROR - DefaultExceptionMapper - unexpected
exception when handling another exception: null
java.lang.NullPointerException
at
com.sas.av.model.context.EServerContext.establishSiteVisitorForCrawler(E
ServerContext.java:3055)
at
com.sas.av.model.context.EServerContext.initSession(EServerContext.java:
3585)
at
com.sas.av.ui.wicket.templates.WicketModelExposerApplication.newSession(
WicketModelExposerApplication.java:148)
at
org.apache.wicket.Application.fetchCreateAndSetSession(Application.java:
1557)
at org.apache.wicket.Session.get(Session.java:152)
at
org.apache.wicket.RestartResponseAtInterceptPageException$InterceptData.
get(RestartResponseAtInterceptPageException.java:146)
at
org.apache.wicket.RestartResponseAtInterceptPageException$1.matchedData(
RestartResponseAtInterceptPageException.java:211)
at
org.apache.wicket.RestartResponseAtInterceptPageException$1.getCompatibi
lityScore(RestartResponseAtInterceptPageException.java:179)
at
org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(Compou
ndRequestMapper.java:138)
at
org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(Reque
stCycle.java:183)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle
.java:208)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(Req
uestCycle.java:282)
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketF
ilter.java:244)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter
.java:188)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:
267)
at
com.sas.av.ui.wicket.templates.original.PagebloomFilter.doFilter(Pageblo
omFilter.java:96)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:206)
at
com.sas.av.model.context.UrlRedirectorFilter.doFilter(UrlRedirectorFilte
r.java:93)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:206)
at
A little Christmas present
We (Olaf Siefart and me) have prepared a little christmas present for you. It's a small Wicket application showcasing different approaches to doing asynchronous loading in Wicket (WebSockets, HeartBeat, ...). We built it for our company developer conference and afterward decided to open source it. Get it at: https://github.com/osiefart/wicket-christmas Have a look, enjoy the snow fall and have a Merry Christmas. Olaf and Jochen jochen.ma...@senacor.com olaf.sief...@senacor.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Parsing company id from url
I'm hoping this will be an easy question to answer for the wicket gurus out there. I'm developing an app that will have pages specific to companies. They will be able to configure styles and logos and all the pages will be branded for their company. The root url looks like http://server/app. I'm going to have an Apache web server proxy in front of it that looks like http://yourcompany that will proxy to the backing tomcat instance. My problem is that I'm not sure how to formulate a URL that wicket can use to parse the institution id. I was thinking that I could proxy http://company1 to http://server/app/1 and http://company2 to http://server/app/2. I'm not sure if this is a best practice for this situation but it seems reasonable. *Question* How do I parse this kind of parameter from within wicket? IRequestMapper? *Note* Some pages will be secured requiring the user to log in, and other pages will be publicly accessible. Thanks for your time. Josh -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Parsing-company-id-from-url-tp4655029.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Parsing company id from url
Hi Josh, LocaleFirstMapper from wicket-examples seems like something you're looking for, it reads the locale from the first url segment. Sven On 12/23/2012 10:33 PM, jchappelle wrote: I'm hoping this will be an easy question to answer for the wicket gurus out there. I'm developing an app that will have pages specific to companies. They will be able to configure styles and logos and all the pages will be branded for their company. The root url looks like http://server/app. I'm going to have an Apache web server proxy in front of it that looks like http://yourcompany that will proxy to the backing tomcat instance. My problem is that I'm not sure how to formulate a URL that wicket can use to parse the institution id. I was thinking that I could proxy http://company1 to http://server/app/1 and http://company2 to http://server/app/2. I'm not sure if this is a best practice for this situation but it seems reasonable. *Question* How do I parse this kind of parameter from within wicket? IRequestMapper? *Note* Some pages will be secured requiring the user to log in, and other pages will be publicly accessible. Thanks for your time. Josh -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Parsing-company-id-from-url-tp4655029.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Attempting to establish session for static resources in Wicket 6
Hi Chris,
as already written, these are temporary sessions that should do no harm.
Nevertheless I've added a check into
RestartResponseAtInterceptPageException#InterceptData (which probes
every request to be able to restore post parameters from before an
intercept page) whether a session exists:
public static InterceptData get()
{
- return Session.get().getMetaData(key);
+ if (Session.exists())
+ {
+ return Session.get().getMetaData(key);
+ }
+ return null;
}
Your particular stacktrace below should no longer trigger the creation
of a session now.
Sven
On 12/23/2012 02:05 PM, Chris Colman wrote:
A while ago when working with Wicket 1.5 we raised issue 4334 that dealt
with the problem of jsessoin ID's being present in static resource URLs
for the initial request and this issue was fixed.
Not requiring jsession ID in the URL meant there was no reason to ever
establish a session during requests for static resources i.e.
WebApplication#newSession was never called for static resource requests.
This worked very well but we've just discovered that in Wicket 6, even
though the URLs for static resources do not contain jsessionIDs there is
some code that is calling getSession - unnecessarily we believe (we hope
=] ).
Is there any reason why WebApplicatoin#newSession is called when no
session is required to service the static request? If not it would be
great if that call could be avoided.
Calling WebApplication#newSession on static resources becomes a problem
when you employ OpenSessionInView/OpenPersistenceManagerInView by using
a filter to wrap all Wicket requests within the context of an open
persistence session/manager. To optimize performance we use an 'ignore
list' that avoids wrapping the request if it is for a resource that
starts with a particular pattern (eg., /wicket/resource,/robots.txt)
We override WebApplication#newSession and do some fancy things whenever
a new session is established - this is intended for non static resource
requests. Some of this code assumes that there is an OpenSessionInView -
which fails in the case of static resources because their URLs are part
of the ignore list and so the request was not wrapped within an open
persistence session/manager.
I was hoping that Wicket 6 could be fixed to avoid the call to
newSession like Wicket 1.5 did after the resolution of 4334.
Here's a stack trace of a call that is servicing a request for a wicket
static resource:
2012/12/23 23:16:24.607 ERROR - DefaultExceptionMapper - unexpected
exception when handling another exception: null
java.lang.NullPointerException
at
com.sas.av.model.context.EServerContext.establishSiteVisitorForCrawler(E
ServerContext.java:3055)
at
com.sas.av.model.context.EServerContext.initSession(EServerContext.java:
3585)
at
com.sas.av.ui.wicket.templates.WicketModelExposerApplication.newSession(
WicketModelExposerApplication.java:148)
at
org.apache.wicket.Application.fetchCreateAndSetSession(Application.java:
1557)
at org.apache.wicket.Session.get(Session.java:152)
at
org.apache.wicket.RestartResponseAtInterceptPageException$InterceptData.
get(RestartResponseAtInterceptPageException.java:146)
at
org.apache.wicket.RestartResponseAtInterceptPageException$1.matchedData(
RestartResponseAtInterceptPageException.java:211)
at
org.apache.wicket.RestartResponseAtInterceptPageException$1.getCompatibi
lityScore(RestartResponseAtInterceptPageException.java:179)
at
org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(Compou
ndRequestMapper.java:138)
at
org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(Reque
stCycle.java:183)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle
.java:208)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(Req
uestCycle.java:282)
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketF
ilter.java:244)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter
.java:188)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:
267)
at
com.sas.av.ui.wicket.templates.original.PagebloomFilter.doFilter(Pageblo
omFilter.java:96)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:206)
at
com.sas.av.model.context.UrlRedirectorFilter.doFilter(UrlRedirectorFilte
r.java:93)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
RE: Attempting to establish session for static resources in Wicket 6
I don't remember quite well how it used to work with 1.5, but looking
at
your stacktrace I see you used some kind of redirection policy that
involves class RestartResponseAtInterceptPageException.
I had the same reaction when I first saw the redirect but I can assure
you that we're not doing any redirect. In fact I put a break point on
the constructor of RestartResponseAtInterceptPageException but none are
instantiated during this execution.
No instance of RestartResponseAtInterceptPageExtension is created but
rather an anonymous instance of an inner class defined within that
class, an instance of IRequestMapper, is being used.
When attempting to service a request for a static resource the following
loop is executed and at some stage 'mapper', the iteration variable,
becomes an instance of:
org.apache.wicket.RestartResponseAtInterceptPageException$1
for (IRequestMapper mapper : mappers)
{
int score =
mapper.getCompatibilityScore(request);
list.add(new MapperWithScore(mapper, score));
}
The anonymouse, inner class instance is defined as:
static IRequestMapper MAPPER = new IRequestMapper()
{
@Override
public int getCompatibilityScore(Request request)
{
return matchedData(request) != null ?
Integer.MAX_VALUE : 0;
}
@Override
public Url mapHandler(IRequestHandler requestHandler)
{
return null;
}
@Override
public IRequestHandler mapRequest(Request request)
{
InterceptData data = matchedData(request);
if (data != null)
{
if (data.postParameters.isEmpty() ==
false
request.getPostParameters()
instanceof IWritableRequestParameters)
{
IWritableRequestParameters
parameters = (IWritableRequestParameters)request.getPostParameters();
parameters.reset();
for (String s :
data.postParameters.keySet())
{
parameters.setParameterValues(s, data.postParameters.get(s));
}
}
InterceptData.clear();
}
return null;
}
private InterceptData matchedData(Request request)
{
InterceptData data = InterceptData.get();
if (data != null
data.originalUrl.equals(request.getOriginalUrl()))
{
return data;
}
return null;
}
};
This class needs to build a permanent session as you can see in its
method
InterceptData.set:
I'm not sure why it's going to all this effort to respond to a request
for a static resource. I guess at this point it's trying to exhaust all
possibilities that the request is for a page before it assumes that it
is a resource.
The one thing I'm pretty sure of is that it is in no way necessary for
Wicket to establish a session to serve a static resource. Wicket 1.5 was
able to achieve this and I think Wicket 6 should be able to also.
public static void set()
{
Session session = Session.get();
session.bind();
So the creation of a new session is not a question of static resources,
but rather a consequence of RestartResponseAtInterceptPageException.
But as I said I don't remember if 1.5 works differently.
A while ago when working with Wicket 1.5 we raised issue 4334 that
dealt
with the problem of jsessoin ID's being present in static resource
URLs
for the initial request and this issue was fixed.
Not requiring jsession ID in the URL meant there was no reason to
ever
establish a session during requests for static resources i.e.
WebApplication#newSession was never called for static resource
requests.
This worked very well but we've just discovered that in Wicket 6,
even
though the URLs for static resources do not contain jsessionIDs there
is
some code that is calling getSession - unnecessarily we believe (we
hope
=] ).
Is there any reason why WebApplicatoin#newSession is called when no
session is required to service the static request? If not it would be
great if that call could be avoided.
Calling WebApplication#newSession on static resources becomes a
problem
when you employ OpenSessionInView/OpenPersistenceManagerInView by
using
a filter to wrap all Wicket requests within the context of an open
persistence session/manager.
RE: Attempting to establish session for static resources in Wicket 6
Ah excellent! Thanks Sven.
I was thinking about the creation of a simple test to be added to the
test suite that would override WebApplication#newSession and then make a
request for a static resource and then throw an exception if newSession
gets called. This would help trap any future regression of this issue.
Hi Chris,
as already written, these are temporary sessions that should do no
harm.
Nevertheless I've added a check into
RestartResponseAtInterceptPageException#InterceptData (which probes
every request to be able to restore post parameters from before an
intercept page) whether a session exists:
public static InterceptData get()
{
- return Session.get().getMetaData(key);
+ if (Session.exists())
+ {
+ return Session.get().getMetaData(key);
+ }
+ return null;
}
Your particular stacktrace below should no longer trigger the creation
of a session now.
Sven
On 12/23/2012 02:05 PM, Chris Colman wrote:
A while ago when working with Wicket 1.5 we raised issue 4334 that
dealt
with the problem of jsessoin ID's being present in static resource
URLs
for the initial request and this issue was fixed.
Not requiring jsession ID in the URL meant there was no reason to
ever
establish a session during requests for static resources i.e.
WebApplication#newSession was never called for static resource
requests.
This worked very well but we've just discovered that in Wicket 6,
even
though the URLs for static resources do not contain jsessionIDs there
is
some code that is calling getSession - unnecessarily we believe (we
hope
=] ).
Is there any reason why WebApplicatoin#newSession is called when no
session is required to service the static request? If not it would be
great if that call could be avoided.
Calling WebApplication#newSession on static resources becomes a
problem
when you employ OpenSessionInView/OpenPersistenceManagerInView by
using
a filter to wrap all Wicket requests within the context of an open
persistence session/manager. To optimize performance we use an
'ignore
list' that avoids wrapping the request if it is for a resource that
starts with a particular pattern (eg., /wicket/resource,/robots.txt)
We override WebApplication#newSession and do some fancy things
whenever
a new session is established - this is intended for non static
resource
requests. Some of this code assumes that there is an
OpenSessionInView -
which fails in the case of static resources because their URLs are
part
of the ignore list and so the request was not wrapped within an open
persistence session/manager.
I was hoping that Wicket 6 could be fixed to avoid the call to
newSession like Wicket 1.5 did after the resolution of 4334.
Here's a stack trace of a call that is servicing a request for a
wicket
static resource:
2012/12/23 23:16:24.607 ERROR - DefaultExceptionMapper -
unexpected
exception when handling another exception: null
java.lang.NullPointerException
at
com.sas.av.model.context.EServerContext.establishSiteVisitorForCrawler(E
ServerContext.java:3055)
at
com.sas.av.model.context.EServerContext.initSession(EServerContext.java:
3585)
at
com.sas.av.ui.wicket.templates.WicketModelExposerApplication.newSession(
WicketModelExposerApplication.java:148)
at
org.apache.wicket.Application.fetchCreateAndSetSession(Application.java:
1557)
at org.apache.wicket.Session.get(Session.java:152)
at
org.apache.wicket.RestartResponseAtInterceptPageException$InterceptData.
get(RestartResponseAtInterceptPageException.java:146)
at
org.apache.wicket.RestartResponseAtInterceptPageException$1.matchedData(
RestartResponseAtInterceptPageException.java:211)
at
org.apache.wicket.RestartResponseAtInterceptPageException$1.getCompatibi
lityScore(RestartResponseAtInterceptPageException.java:179)
at
org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(Compou
ndRequestMapper.java:138)
at
org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(Reque
stCycle.java:183)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle
.java:208)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(Req
uestCycle.java:282)
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketF
ilter.java:244)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter
.java:188)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:
267)
at
com.sas.av.ui.wicket.templates.original.PagebloomFilter.doFilter(Pageblo
omFilter.java:96)
at
