We've now received final funding for this position and are interviewing
candidates. Interested parties would need to be available soon. Please
contact me at the email below if you are interested.
Matt
Watter wrote:
Our team is developing a new application Using the following
technologies
Our team is developing a new application Using the following
technologies/frameworks:
Wicket
Spring
Hibernate
Compass/Lucene
Unfortunately we have a small gap in knowledge when it comes to Wicket.
We're learning quickly but we need to hire someone who can step in and be
immediately productive
Jean-Baptiste Quenot-3 wrote:
* Watter:
I created a small demo application that demonstrates the
problem? Is there somewhere I can upload the zip file (it uses
maven so it's only 7kb) with some instructions on the steps
necessary to recreate the problem? I hate to open
Jean-Baptiste Quenot-3 wrote:
* Watter:
1) I realized that ContextLoader which is the reported as the
classloader when I do a Session.class.getClassloader() right
before the error occurs is actually a Spring class. For some
reason I was thinking that it was a standard
Jean-Baptiste Quenot-3 wrote:
* Watter:
1) I realized that ContextLoader which is the reported as the
classloader when I do a Session.class.getClassloader() right
before the error occurs is actually a Spring class. For some
reason I was thinking that it was a standard
Watter wrote:
Jean-Baptiste Quenot-3 wrote:
* Watter:
1) I realized that ContextLoader which is the reported as the
classloader when I do a Session.class.getClassloader() right
before the error occurs is actually a Spring class. For some
reason I was thinking
Watter wrote:
Jean-Baptiste Quenot-3 wrote:
That's very interesting. It may be caused by some page
deserialization not using the right classloader, when Wicket pulls
pages out of the second-level cache. May be worth trying
Jean-Baptiste Quenot-3 wrote:
* Watter:
Most of the time the following holds true when I reach that statement:
Session.get().getClass().getClassLoader() =
org.apache.wicket.application.ReloadingClassLoader
FusionAuthenticatedWebSession.class.getClassLoader
Are there any rules about a company posting to this list about potential open
positions around Wicket?
Matt
--
View this message in context:
http://www.nabble.com/Wicket-mailing-list-rules-with-regards-to-jobs-tf4019684.html#a11416655
Sent from the Wicket - User mailing list archive at
Jean-Baptiste Quenot-3 wrote:
It means com.ptc.fusion.web.FusionAuthenticatedWebSession is
already loaded in other classes that did not match the inclusion
patterns.
To debug your usecase, set a conditional breakpoint in
ReloadingClassLoader.loadClass() when class name is
Jean-Baptiste Quenot-3 wrote:
* Watter:
With that, I can get past the error I reported
earlier. Unfortunately, I'm seeing something else now. If I go
to a page, then use my browser back button to go back a page,
and then click on any other link, I get
ptrthomas wrote:
On 6/28/07, Watter [EMAIL PROTECTED] wrote:
A couple of observations. Looks like you are using Acegi as well. I have
the same problem when I don't exclude my Session and Application classes.
Actually, we aren't using Acegi. That class you're looking it is named
similar
I realize this is a shot in the dark, but I'm at a loss and my team is
growing more and more frustrated with me (I'm the Wicket advocate), so I
hope someone might be able to help.
We are constantly getting the following error when accessing a page:
---
WicketMessage: Markup of type
Watter wrote:
I realize this is a shot in the dark, but I'm at a loss and my team is
growing more and more frustrated with me (I'm the Wicket advocate), so I
hope someone might be able to help.
We are constantly getting the following error when accessing a page
Jean-Baptiste Quenot-3 wrote:
I commented on the issue, and finally marked it as invalid. Here
is the comment, in case you wish to discuss it on the mailing-list
or just for the record if other users came across this:
It's a bit tricky to make the reloading work with Spring. You have
Jean-Baptiste Quenot-3 wrote:
* Watter:
Is it necessary to explicitly specify the inclusion of
sub-packages when the parent package is already included? I only
aske because our package hierarchy is pretty deep when it comes
to pages, and I'd loke to avoid having
Watter wrote:
I now have a new issue. Jean-Baptiste mentions in the JIRA issue that one
*must* include the XxxApplication and XxxSession classes. Well, when I
tried to do so I was unable to access my application. When I included the
my versions of those classes, I received the following
17 matches
Mail list logo
