Re: wicket 6.3.0 WeldDecorator
Thanks martin with jetty version 8.1.3.v20120416 its O.K. with jetty version 9.0.2.v20130417 same error Am 24.06.2013 13:48, schrieb Martin Grigorov: You need to use Jetty 8.x On Mon, Jun 24, 2013 at 2:44 PM, Piratenvisier hansheinrichbr...@yahoo.dewrote: Hi, Martin error is also in 6.8.0: I found the following remark: Wicket 6.8.0 and WeldDecoratorhttps://issues.apache.org/** jira/browse/WICKET-5144https://issues.apache.org/jira/browse/WICKET-5144 Am 24.06.2013 09:42, schrieb Martin Grigorov: Hi, Don't use 6.3.0. Even if there is a problem with it we cannot fix it. If there is a problem in Wicket v.Latest we can fix it in Wicket v.Next. So always check that your problems are valid in v.Latest. On Sun, Jun 23, 2013 at 5:26 PM, Piratenvisier hansheinrichbr...@yahoo.de**wrote: When I start jetty for wicket-examples 6.3.0 now 6.8.0 I get the following Error: Cannot load class for org.jboss.weld.environment.jetty.WeldDecorator --** --**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apa**che.orghttp://apache.org users-unsubscribe@**wicket.apache.orgusers-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: wicket and flow
Hello Martin,
a central class in Webflow is PageFlowRequestCycleProcessor:
public class PageFlowRequestCycleProcessor extends WebRequestCycleProcessor
{
/** {@inheritDoc} */
@Override
public IRequestTarget_*resolve*_(RequestCycle requestCycle,
RequestParameters requestParameters)
{
//If Key in URL use it
if(requestParameters.getParameters().containsKey(PageFlowConstants.FLOW_EXECUTION_KEY))
{
String[] flowExecutionKeyParms =
(String[])requestParameters.getParameters().get(PageFlowConstants.FLOW_EXECUTION_KEY);
if(flowExecutionKeyParms.length 0){
return
RequestTargetFactory.buildFromState(flowExecutionKeyParms[0],
requestCycle, requestParameters);
}
}
IRequestTarget target = super.resolve(requestCycle,
requestParameters);
// If the target is bookmarkable but mounted it needs to go
back and check pageflow
if (target instanceof BookmarkablePageRequestTarget)
{
//BookmarkablePageRequestTarget bookmarkableTarget =
(BookmarkablePageRequestTarget)target;
//if
(PAGE_FLOW_PAGE_CLASS.isAssignableFrom(bookmarkableTarget.getPageClass()) ||
//
PANEL_FLOW_PAGE_CLASS.isAssignableFrom(bookmarkableTarget.getPageClass()))
//{
String currentStateFromSession =
PageFlowSession.get().getFlowState().getCurrentViewState();
return
RequestTargetFactory.buildFromState(currentStateFromSession,
requestCycle, requestParameters);
//}
}
return target;
}
/** {@inheritDoc} */
@Override
protected IRequestTarget _*resolveHomePageTarget*_(RequestCycle
requestCycle, RequestParameters requestParameters)
{
//Grab the target as Wicket would normally calculate it
BookmarkablePageRequestTarget classicTarget
=(BookmarkablePageRequestTarget)
super.resolveHomePageTarget(requestCycle, requestParameters);
BookmarkablePageRequestTarget newTarget =
resolvePageFlowTargets(classicTarget,requestCycle,requestParameters);
//If the target that PageFlow is returning isn't the real home
page we need to redirect to it.
if(!classicTarget.getPageClass().equals(newTarget.getPageClass())){
//Redirect to the homepage if session is trying to go to
the end of the flow since we are restarting it
String currentStateFromSession =
PageFlowSession.get().getFlowState().getCurrentViewState();
if(PageFlowConstants.PAGE_FLOW_FINAL_STATE_DONE.equals(currentStateFromSession)){
//Reset the whole flow state in preparation for a new flow
PageFlowSession.get().resetFlowState();
// This line is to reset the target because the
flowstate was just reset so the url needs to be regenerated
classicTarget =(BookmarkablePageRequestTarget)
super.resolveHomePageTarget(requestCycle, requestParameters);
return classicTarget;
}
throw new
RestartResponseException(newTarget.getPageClass(),
newTarget.getPageParameters());
}
return
resolvePageFlowTargets(classicTarget,requestCycle,requestParameters);
}
/** {@inheritDoc} */
@Override
protected IRequestTarget _*resolveBookmarkablePage*_(RequestCycle
requestCycle, RequestParameters requestParameters)
{
//Grab the target as Wicket would normally calculate it
BookmarkablePageRequestTarget classicTarget
=(BookmarkablePageRequestTarget) super.resolveBookmarkablePage(
requestCycle, requestParameters);
return
resolvePageFlowTargets(classicTarget,requestCycle,requestParameters);
}
/**
* presolvePageFlowTargets./p
*
* @param classicTarget a {@link
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget} object.
* @param requestCycle a {@link org.apache.wicket.RequestCycle} object.
* @param requestParameters a {@link
org.apache.wicket.request.RequestParameters} object.
* @return a {@link
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget} object.
*/
protected BookmarkablePageRequestTarget
_resolvePageFlowTargets_(BookmarkablePageRequestTarget classicTarget,
RequestCycle requestCycle, RequestParameters requestParameters)
{
BookmarkablePageRequestTarget target = null;
String currentStateFromSession =
PageFlowSession.get().getFlowState().getCurrentViewState();
//If the target still hasn't been set, target from the user's
session data
if(currentStateFromSession != null)
{
target =
RequestTargetFactory.buildFromState(currentStateFromSession,
requestCycle, requestParameters);
}
//TODO if the target is null, redirect back to the last
rendered page, or the homepage
if(target == null)
{
target =
Re: DI Through Constructors w/Wicket
I'm just getting to this now... weekend coder. @MartinGrigorov - this looks exactly like what I want, or parts of it at least... I'll certainly check it out. And you're right, I shouldn't be so skeptical, you Wicket folks seem to always come through with some library when I ask a question :-) @DanielWatrous - your blog is helpful, except that you instantiate a Guice instance in your unit test. I'm still wrestling with what I consider best practices with respect to Guice/DI and Unit Tests, but I'm strongly leaning towards the best practice of: If you're having to create an injector in your unit test, then you're doing it wrong. Dependencies should come in through the constructor and constructor only. In the unit test, mocked instances of those dependencies should be passed in through the constructor after you've called new to create the object itself. This ensures you're ONLY testing the object, and none of its dependencies in that unit test. If you cannot pass your dependencies through the constructor, it's most likely because you're not letting the framework create the instance for you, and this exposes a deficiency in your implementation. This is the problem with Wicket, it creates the pages for you (unless you implement your own IPageFactory like in the library Martin linked), which forces you to use field injection like you did in your blog example. Draconian best practice? Maybe, but when working with a number of developers on a project, I find it best to keep strict but simple rules; even better when they can be enforced with things like Checkstyle. Am I totally wrong here? Am I missing something? I'd love people's feedback on this! Bill- On Tue, Jun 25, 2013 at 10:38 PM, Daniel Watrous dwmaill...@gmail.com wrote: I worked out this process: http://software.danielwatrous.com/wicket-guice-including-unittests/ It enables unittests and may help you toward your goal. Daniel On Tue, Jun 25, 2013 at 7:14 PM, William Speirs wspe...@apache.org wrote: I think I know the answer before I ask, but is there any way to do constructor injection with Wicket? Say I have a web page and an email service. I need the email service in the web page. Now everyone is going to say, Simply use field injection. That will work, but makes unit testing a real pain because now I have to setup injection for my unit test (or add additional methods to all of my pages so I can manually set these field, or additional constructors that set these fields). I should be able to unit test a class without needing injection, but instead passing mocks through the constructor. I feel like this is impossible in Wicket currently because the DefaultPageFactory is using reflection to create the page instances instead of the injector (Guice in my case). It would be easy enough to get the injector and call getInstance() to obtain a page instance. The problem is when you need to pass in parameters. There is no concept of parameters for a page other than what is passed via the constructor, so you cannot call something like setPageParameters because it doesn't exist. If using Guice, you could create an @Assisted injection, and have a factory. Has anyone tried creating this type of IPageFactory -- a GuicePageFactory? What kind of pitfalls would exist if I attempted such a thing? Am I being stupid and missing something? Thoughts? Thanks... Bill- - 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: clustering and failover
Another consideration is if you're using any authentication that relies upon the tomcat session, then bouncing to another box (if you're doing round-robin load balanced) would mean your users will have to reauthenticate. Been there, still have the bite marks from that :-) Bill- On Fri, Jun 28, 2013 at 4:50 PM, uwe schaefer u...@uwe-schaefer.org wrote: On 06/28/2013 09:19 AM, Martin Grigorov wrote: Hi Martin, i already saw and consider your memcached-based session management, thanks. the reason i ask the wicket mailing list is, that i assume that wicket only needs part of the pagemap (namely the current page) to serve a request, so that - hopefully - the data needed to serve a single request can be smaller if the pagemap is kept seperate from the session. is this assumption correct? cu uwe I think you should ask this question in Tomcat mailing list. Also check https://code.google.com/p/memcached-session-manager/ On Fri, Jun 28, 2013 at 8:46 AM, Uwe Schäfer u...@codesmell.de wrote: hi quick question about clustering: am i right to believe that putting session/pagemap data in a memcached-like storage has advantages over the tomcat session clustering in terms of latency and robust failover behaviour? i mean, the latter obviously has the data nearby (when assuming sticky sessions) whereas the first needs to grab it from (and push it to) external storage every time even though it is far more selective about what it needs. i was wondering if tomcat session clustering can effectivly update only the dirty parts of the session data? i'd love any kind of feedback on that topic INCLUDING 'depends'-answers :) cu uwe --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-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
