RE: Wicket-bootstrap Bootstrap 3 support

2014-02-05 Thread Richter, Marvin
There might be breaking changes with Modals. Not sure if you provide support 
for the remote function of the Bootstrap Modals.

Marvin Richter


-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org] 
Sent: Wednesday, February 05, 2014 8:54 AM
To: users@wicket.apache.org
Subject: Re: Wicket-bootstrap Bootstrap 3 support

Right, the correct way is to use Maven for this.
Another way is via IBootstrapSettings#setCssResourceReference() -
https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/master/bootstrap-core/src/main/java/de/agilecoders/wicket/core/settings/IBootstrapSettings.java?source=c#L53

We will upgrade to 3.1.0 soon. We have to see whether there are breaking 
migration changes first.

Martin Grigorov
Wicket Training and Consulting


On Wed, Feb 5, 2014 at 8:41 AM, Richter, Marvin  
marvin.rich...@jestadigital.com wrote:

 In Maven you can just exclude transitive dependecies from a dependency 
 and add the version you prefer. But be aware of possible version conflicts.

 dependency
 groupIdde.agilecoders.wicket/groupId
 artifactIdwicket-bootstrap-core/artifactId
 version${wicket.bootstrap.version}/version
 exclusions
 exclusion
 artifactIdorg.webjars/artifactId
 groupIdbootstrap/groupId
 /exclusion
 /exclusions
 /dependency
 dependency
 groupIdorg.webjars/groupId
 artifactIdbootstrap/artifactId
 version3.1.0/version
 /dependency

 Best,
 Marvin

 -Original Message-
 From: danjee [mailto:daniel.j...@asf.ro]
 Sent: Wednesday, February 05, 2014 8:32 AM
 To: users@wicket.apache.org
 Subject: Re: Wicket-bootstrap Bootstrap 3 support

 On 02/05/2014 09:13 AM, danjee [via Apache Wicket] wrote:
  I found out that I could put the dependency in my pom.xml and no 
  need to alter the one from your release.
  Sorry for the confusion, I am pretty new to maven.
  Best regards,
  Daniel
 
  
  --
  -- If you reply to this email, your message will be added to the 
  discussion below:
  http://apache-wicket.1842946.n4.nabble.com/Wicket-bootstrap-Bootstra
  p-
  3-support-tp4661497p4664171.html
 
  To unsubscribe from Wicket-bootstrap Bootstrap 3 support, click here 
  
 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?ma
 cro=unsubscribe_by_codenode=4661497code=ZGFuaWVsLmppcGFAYXNmLnJvfDQ2
 NjE0OTd8LTIwNDU1Njg5NTY=
 .
  NAML
  
 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?
 m  
 acro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.n
 a
  
 ml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace
 -  
 nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers
 %  
 21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_insta
 n
  t_email%21nabble%3Aemail.naml
 



 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Wicket-bootstrap-Bootstrap-
 3-support-tp4661497p4664173.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: Dynamic Headers for Open Graph tags in E-Com site

2014-02-05 Thread Arjun Dhar
Hey thanks  ya sorry i re-edited my post.
But helps. .. never tried using panels in Headers. It failed for me sometime
so I assumed its not the right thing 

thanks again, will try it

-
Software documentation is like sex: when it is good, it is very, very good; and 
when it is bad, it is still better than nothing!
--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Dynamic-Headers-for-Open-Graph-tags-in-E-Com-site-tp4664158p4664181.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



WicketTester.isRenderedPage() in 6.13

2014-02-05 Thread Daniel Stoch
Hi,

I'm during migration from Wicket 1.4.x to 6.x and I have the following
problem with WicketTester.
I have some secured page, during its initialization some kind of
AuthorizationException is raised. It should end with displaying standard
AccessDeniedPage. Here is a code fragment from test case:

1.4.x:
RequestCycle.get().setResponsePage(SecuredDummyPage.class);
tester.processRequestCycle(requestCycle);
Result result = tester.isRenderedPage(AccessDeniedPage.class);
assertFalse(result.getMessage(), result.wasFailed());

This test is passed.

But in 6.13 the similar test:
RequestCycle.get().setResponsePage(SecuredDummyPage.class);
tester.processRequest();
// or tester.startPage(SecuredDummyPage.class)
Result result = tester.isRenderedPage(AccessDeniedPage.class);
assertFalse(result.getMessage(), result.wasFailed());

is not passed. It is end up on this AuthorizationException and
AccessDeniedPage is not rendered.
Should it be rendered or should I have to change my test, because in 6.x it
works in different way?

--
Daniel


Re: WicketTester.isRenderedPage() in 6.13

2014-02-05 Thread Martin Grigorov
Try with tester.setExposeExceptions(false) before making the request to the
secured page

Martin Grigorov
Wicket Training and Consulting


On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch daniel.st...@gmail.comwrote:

 Hi,

 I'm during migration from Wicket 1.4.x to 6.x and I have the following
 problem with WicketTester.
 I have some secured page, during its initialization some kind of
 AuthorizationException is raised. It should end with displaying standard
 AccessDeniedPage. Here is a code fragment from test case:

 1.4.x:
 RequestCycle.get().setResponsePage(SecuredDummyPage.class);
 tester.processRequestCycle(requestCycle);
 Result result = tester.isRenderedPage(AccessDeniedPage.class);
 assertFalse(result.getMessage(), result.wasFailed());

 This test is passed.

 But in 6.13 the similar test:
 RequestCycle.get().setResponsePage(SecuredDummyPage.class);
 tester.processRequest();
 // or tester.startPage(SecuredDummyPage.class)
 Result result = tester.isRenderedPage(AccessDeniedPage.class);
 assertFalse(result.getMessage(), result.wasFailed());

 is not passed. It is end up on this AuthorizationException and
 AccessDeniedPage is not rendered.
 Should it be rendered or should I have to change my test, because in 6.x it
 works in different way?

 --
 Daniel



Re: WicketTester.isRenderedPage() in 6.13

2014-02-05 Thread Daniel Stoch
It works!
Thanks for your fast replay :)

--
Daniel


On Wed, Feb 5, 2014 at 10:40 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 Try with tester.setExposeExceptions(false) before making the request to the
 secured page

 Martin Grigorov
 Wicket Training and Consulting


 On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch daniel.st...@gmail.com
 wrote:

  Hi,
 
  I'm during migration from Wicket 1.4.x to 6.x and I have the following
  problem with WicketTester.
  I have some secured page, during its initialization some kind of
  AuthorizationException is raised. It should end with displaying standard
  AccessDeniedPage. Here is a code fragment from test case:
 
  1.4.x:
  RequestCycle.get().setResponsePage(SecuredDummyPage.class);
  tester.processRequestCycle(requestCycle);
  Result result = tester.isRenderedPage(AccessDeniedPage.class);
  assertFalse(result.getMessage(), result.wasFailed());
 
  This test is passed.
 
  But in 6.13 the similar test:
  RequestCycle.get().setResponsePage(SecuredDummyPage.class);
  tester.processRequest();
  // or tester.startPage(SecuredDummyPage.class)
  Result result = tester.isRenderedPage(AccessDeniedPage.class);
  assertFalse(result.getMessage(), result.wasFailed());
 
  is not passed. It is end up on this AuthorizationException and
  AccessDeniedPage is not rendered.
  Should it be rendered or should I have to change my test, because in 6.x
 it
  works in different way?
 
  --
  Daniel
 



Re: WicketTester.isRenderedPage() in 6.13

2014-02-05 Thread Daniel Stoch
For fast REPLY, of course ;)


On Wed, Feb 5, 2014 at 10:45 AM, Daniel Stoch daniel.st...@gmail.comwrote:

 It works!
 Thanks for your fast replay :)

 --
 Daniel


 On Wed, Feb 5, 2014 at 10:40 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 Try with tester.setExposeExceptions(false) before making the request to
 the
 secured page

 Martin Grigorov
 Wicket Training and Consulting


 On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch daniel.st...@gmail.com
 wrote:

  Hi,
 
  I'm during migration from Wicket 1.4.x to 6.x and I have the following
  problem with WicketTester.
  I have some secured page, during its initialization some kind of
  AuthorizationException is raised. It should end with displaying standard
  AccessDeniedPage. Here is a code fragment from test case:
 
  1.4.x:
  RequestCycle.get().setResponsePage(SecuredDummyPage.class);
  tester.processRequestCycle(requestCycle);
  Result result = tester.isRenderedPage(AccessDeniedPage.class);
  assertFalse(result.getMessage(), result.wasFailed());
 
  This test is passed.
 
  But in 6.13 the similar test:
  RequestCycle.get().setResponsePage(SecuredDummyPage.class);
  tester.processRequest();
  // or tester.startPage(SecuredDummyPage.class)
  Result result = tester.isRenderedPage(AccessDeniedPage.class);
  assertFalse(result.getMessage(), result.wasFailed());
 
  is not passed. It is end up on this AuthorizationException and
  AccessDeniedPage is not rendered.
  Should it be rendered or should I have to change my test, because in
 6.x it
  works in different way?
 
  --
  Daniel
 





Re: WicketTester.isRenderedPage() in 6.13

2014-02-05 Thread Daniel Stoch
One more question: what is a difference between these two calls:

1.
tester.startPage(DummyBasePage.class);
Result result = tester.isRenderedPage(DummyBasePage.class);

2.
tester.getRequestCycle().setResponsePage(DummyBasePage.class);
tester.processRequest();
Result result = tester.isRenderedPage(DummyBasePage.class);

The first one works ok (DummyBasePage is rendered), but the second fails:
HomePage is rendered instead of DummyBasePage. Why?

--
Daniel



On Wed, Feb 5, 2014 at 10:40 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 Try with tester.setExposeExceptions(false) before making the request to the
 secured page

 Martin Grigorov
 Wicket Training and Consulting


 On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch daniel.st...@gmail.com
 wrote:

  Hi,
 
  I'm during migration from Wicket 1.4.x to 6.x and I have the following
  problem with WicketTester.
  I have some secured page, during its initialization some kind of
  AuthorizationException is raised. It should end with displaying standard
  AccessDeniedPage. Here is a code fragment from test case:
 
  1.4.x:
  RequestCycle.get().setResponsePage(SecuredDummyPage.class);
  tester.processRequestCycle(requestCycle);
  Result result = tester.isRenderedPage(AccessDeniedPage.class);
  assertFalse(result.getMessage(), result.wasFailed());
 
  This test is passed.
 
  But in 6.13 the similar test:
  RequestCycle.get().setResponsePage(SecuredDummyPage.class);
  tester.processRequest();
  // or tester.startPage(SecuredDummyPage.class)
  Result result = tester.isRenderedPage(AccessDeniedPage.class);
  assertFalse(result.getMessage(), result.wasFailed());
 
  is not passed. It is end up on this AuthorizationException and
  AccessDeniedPage is not rendered.
  Should it be rendered or should I have to change my test, because in 6.x
 it
  works in different way?
 
  --
  Daniel
 



Re: WicketTester.isRenderedPage() in 6.13

2014-02-05 Thread Martin Grigorov
#processRequest() triggers a new request to the server
so first the page is rendered, then a new request to the default
destination is made, so the home page is rendered and lastRenderedPage
changes

Martin Grigorov
Wicket Training and Consulting


On Wed, Feb 5, 2014 at 11:39 AM, Daniel Stoch daniel.st...@gmail.comwrote:

 One more question: what is a difference between these two calls:

 1.
 tester.startPage(DummyBasePage.class);
 Result result = tester.isRenderedPage(DummyBasePage.class);

 2.
 tester.getRequestCycle().setResponsePage(DummyBasePage.class);
 tester.processRequest();
 Result result = tester.isRenderedPage(DummyBasePage.class);

 The first one works ok (DummyBasePage is rendered), but the second fails:
 HomePage is rendered instead of DummyBasePage. Why?

 --
 Daniel



 On Wed, Feb 5, 2014 at 10:40 AM, Martin Grigorov mgrigo...@apache.org
 wrote:

  Try with tester.setExposeExceptions(false) before making the request to
 the
  secured page
 
  Martin Grigorov
  Wicket Training and Consulting
 
 
  On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch daniel.st...@gmail.com
  wrote:
 
   Hi,
  
   I'm during migration from Wicket 1.4.x to 6.x and I have the following
   problem with WicketTester.
   I have some secured page, during its initialization some kind of
   AuthorizationException is raised. It should end with displaying
 standard
   AccessDeniedPage. Here is a code fragment from test case:
  
   1.4.x:
   RequestCycle.get().setResponsePage(SecuredDummyPage.class);
   tester.processRequestCycle(requestCycle);
   Result result = tester.isRenderedPage(AccessDeniedPage.class);
   assertFalse(result.getMessage(), result.wasFailed());
  
   This test is passed.
  
   But in 6.13 the similar test:
   RequestCycle.get().setResponsePage(SecuredDummyPage.class);
   tester.processRequest();
   // or tester.startPage(SecuredDummyPage.class)
   Result result = tester.isRenderedPage(AccessDeniedPage.class);
   assertFalse(result.getMessage(), result.wasFailed());
  
   is not passed. It is end up on this AuthorizationException and
   AccessDeniedPage is not rendered.
   Should it be rendered or should I have to change my test, because in
 6.x
  it
   works in different way?
  
   --
   Daniel
  
 



Re: WicketTester.isRenderedPage() in 6.13

2014-02-05 Thread Daniel Stoch
Ok, but what I should call to render DummyBasePage after calling:
  tester.getRequestCycle().setResponsePage(DummyBasePage.class);
without making a new request?

--
Daniel


On Wed, Feb 5, 2014 at 12:01 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 #processRequest() triggers a new request to the server
 so first the page is rendered, then a new request to the default
 destination is made, so the home page is rendered and lastRenderedPage
 changes

 Martin Grigorov
 Wicket Training and Consulting


 On Wed, Feb 5, 2014 at 11:39 AM, Daniel Stoch daniel.st...@gmail.com
 wrote:

  One more question: what is a difference between these two calls:
 
  1.
  tester.startPage(DummyBasePage.class);
  Result result = tester.isRenderedPage(DummyBasePage.class);
 
  2.
  tester.getRequestCycle().setResponsePage(DummyBasePage.class);
  tester.processRequest();
  Result result = tester.isRenderedPage(DummyBasePage.class);
 
  The first one works ok (DummyBasePage is rendered), but the second fails:
  HomePage is rendered instead of DummyBasePage. Why?
 
  --
  Daniel
 
 
 
  On Wed, Feb 5, 2014 at 10:40 AM, Martin Grigorov mgrigo...@apache.org
  wrote:
 
   Try with tester.setExposeExceptions(false) before making the request to
  the
   secured page
  
   Martin Grigorov
   Wicket Training and Consulting
  
  
   On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch daniel.st...@gmail.com
   wrote:
  
Hi,
   
I'm during migration from Wicket 1.4.x to 6.x and I have the
 following
problem with WicketTester.
I have some secured page, during its initialization some kind of
AuthorizationException is raised. It should end with displaying
  standard
AccessDeniedPage. Here is a code fragment from test case:
   
1.4.x:
RequestCycle.get().setResponsePage(SecuredDummyPage.class);
tester.processRequestCycle(requestCycle);
Result result = tester.isRenderedPage(AccessDeniedPage.class);
assertFalse(result.getMessage(), result.wasFailed());
   
This test is passed.
   
But in 6.13 the similar test:
RequestCycle.get().setResponsePage(SecuredDummyPage.class);
tester.processRequest();
// or tester.startPage(SecuredDummyPage.class)
Result result = tester.isRenderedPage(AccessDeniedPage.class);
assertFalse(result.getMessage(), result.wasFailed());
   
is not passed. It is end up on this AuthorizationException and
AccessDeniedPage is not rendered.
Should it be rendered or should I have to change my test, because in
  6.x
   it
works in different way?
   
--
Daniel
   
  
 



Re: WicketTester.isRenderedPage() in 6.13

2014-02-05 Thread Martin Grigorov
You should not use  tester.getRequestCycle().setResponsePage(DummyBasePage.
class);

You should do something like:
- in the test code: tester.startPage(Page1.class)
- in your real application code: Page1 or in its components you can use
setResponsePage(Page2.class)
- finally in the test code: tester.assertRenderedPage(Page2.class)


Martin Grigorov
Wicket Training and Consulting


On Wed, Feb 5, 2014 at 12:18 PM, Daniel Stoch daniel.st...@gmail.comwrote:

 Ok, but what I should call to render DummyBasePage after calling:
   tester.getRequestCycle().setResponsePage(DummyBasePage.class);
 without making a new request?

 --
 Daniel


 On Wed, Feb 5, 2014 at 12:01 PM, Martin Grigorov mgrigo...@apache.org
 wrote:

  #processRequest() triggers a new request to the server
  so first the page is rendered, then a new request to the default
  destination is made, so the home page is rendered and lastRenderedPage
  changes
 
  Martin Grigorov
  Wicket Training and Consulting
 
 
  On Wed, Feb 5, 2014 at 11:39 AM, Daniel Stoch daniel.st...@gmail.com
  wrote:
 
   One more question: what is a difference between these two calls:
  
   1.
   tester.startPage(DummyBasePage.class);
   Result result = tester.isRenderedPage(DummyBasePage.class);
  
   2.
   tester.getRequestCycle().setResponsePage(DummyBasePage.class);
   tester.processRequest();
   Result result = tester.isRenderedPage(DummyBasePage.class);
  
   The first one works ok (DummyBasePage is rendered), but the second
 fails:
   HomePage is rendered instead of DummyBasePage. Why?
  
   --
   Daniel
  
  
  
   On Wed, Feb 5, 2014 at 10:40 AM, Martin Grigorov mgrigo...@apache.org
   wrote:
  
Try with tester.setExposeExceptions(false) before making the request
 to
   the
secured page
   
Martin Grigorov
Wicket Training and Consulting
   
   
On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch 
 daniel.st...@gmail.com
wrote:
   
 Hi,

 I'm during migration from Wicket 1.4.x to 6.x and I have the
  following
 problem with WicketTester.
 I have some secured page, during its initialization some kind of
 AuthorizationException is raised. It should end with displaying
   standard
 AccessDeniedPage. Here is a code fragment from test case:

 1.4.x:
 RequestCycle.get().setResponsePage(SecuredDummyPage.class);
 tester.processRequestCycle(requestCycle);
 Result result = tester.isRenderedPage(AccessDeniedPage.class);
 assertFalse(result.getMessage(), result.wasFailed());

 This test is passed.

 But in 6.13 the similar test:
 RequestCycle.get().setResponsePage(SecuredDummyPage.class);
 tester.processRequest();
 // or tester.startPage(SecuredDummyPage.class)
 Result result = tester.isRenderedPage(AccessDeniedPage.class);
 assertFalse(result.getMessage(), result.wasFailed());

 is not passed. It is end up on this AuthorizationException and
 AccessDeniedPage is not rendered.
 Should it be rendered or should I have to change my test, because
 in
   6.x
it
 works in different way?

 --
 Daniel

   
  
 



Re: Dynamic Headers for Open Graph tags in E-Com site

2014-02-05 Thread Arjun Dhar
Thanks ..so using Panels in the header did work out fine. .. using
container !

Though; I want to put custom variables in the META tags; I found it more
complex it to do via Wicket.
Rather used Velocity to accept a MAP of Attributes and generate the META
TAGS and pass that into a FRAGMENT seemed scalable and faster.

But curious if you dumped the entire META content is a String or you used
Some sort of Repeater or Wicket component to render the Dynamic individual
Meta tags?

Example in Velocity I found to be a breeze over wicket:


-
Software documentation is like sex: when it is good, it is very, very good; and 
when it is bad, it is still better than nothing!
--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Dynamic-Headers-for-Open-Graph-tags-in-E-Com-site-tp4664158p4664194.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: Dynamic Headers for Open Graph tags in E-Com site

2014-02-05 Thread Martin Grigorov
My panel had all meta tags for all possible data.
Each page constructs some data (a model) depending on the current
functionality.
Then the panel uses the model to populate some of the meta tags and to set
invisible all without data for them.

Martin Grigorov
Wicket Training and Consulting


On Wed, Feb 5, 2014 at 1:17 PM, Arjun Dhar dhar...@yahoo.com wrote:

 Thanks ..so using Panels in the header did work out fine. .. using
 container !

 Though; I want to put custom variables in the META tags; I found it more
 complex it to do via Wicket.
 Rather used Velocity to accept a MAP of Attributes and generate the META
 TAGS and pass that into a FRAGMENT seemed scalable and faster.

 But curious if you dumped the entire META content is a String or you used
 Some sort of Repeater or Wicket component to render the Dynamic individual
 Meta tags?

 Example in Velocity I found to be a breeze over wicket:


 -
 Software documentation is like sex: when it is good, it is very, very
 good; and when it is bad, it is still better than nothing!
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Dynamic-Headers-for-Open-Graph-tags-in-E-Com-site-tp4664158p4664194.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: WicketTester.isRenderedPage() in 6.13

2014-02-05 Thread Daniel Stoch
In my real application there are calls to RequestCycle.setResponsePage(...)
which are hidden by more advanced action/navigation framework. So I cannot
simply replace them by component.setResponsePage().
I think that if RequestCycle.setResponsePage(...) is valid for real
application, it should also be valid for tests. Am I wrong?

--
Daniel


On Wed, Feb 5, 2014 at 1:14 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 You should not use  tester.getRequestCycle().setResponsePage(DummyBasePage.
 class);

 You should do something like:
 - in the test code: tester.startPage(Page1.class)
 - in your real application code: Page1 or in its components you can use
 setResponsePage(Page2.class)
 - finally in the test code: tester.assertRenderedPage(Page2.class)


 Martin Grigorov
 Wicket Training and Consulting


 On Wed, Feb 5, 2014 at 12:18 PM, Daniel Stoch daniel.st...@gmail.com
 wrote:

  Ok, but what I should call to render DummyBasePage after calling:
tester.getRequestCycle().setResponsePage(DummyBasePage.class);
  without making a new request?
 
  --
  Daniel
 
 
  On Wed, Feb 5, 2014 at 12:01 PM, Martin Grigorov mgrigo...@apache.org
  wrote:
 
   #processRequest() triggers a new request to the server
   so first the page is rendered, then a new request to the default
   destination is made, so the home page is rendered and
 lastRenderedPage
   changes
  
   Martin Grigorov
   Wicket Training and Consulting
  
  
   On Wed, Feb 5, 2014 at 11:39 AM, Daniel Stoch daniel.st...@gmail.com
   wrote:
  
One more question: what is a difference between these two calls:
   
1.
tester.startPage(DummyBasePage.class);
Result result = tester.isRenderedPage(DummyBasePage.class);
   
2.
tester.getRequestCycle().setResponsePage(DummyBasePage.class);
tester.processRequest();
Result result = tester.isRenderedPage(DummyBasePage.class);
   
The first one works ok (DummyBasePage is rendered), but the second
  fails:
HomePage is rendered instead of DummyBasePage. Why?
   
--
Daniel
   
   
   
On Wed, Feb 5, 2014 at 10:40 AM, Martin Grigorov 
 mgrigo...@apache.org
wrote:
   
 Try with tester.setExposeExceptions(false) before making the
 request
  to
the
 secured page

 Martin Grigorov
 Wicket Training and Consulting


 On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch 
  daniel.st...@gmail.com
 wrote:

  Hi,
 
  I'm during migration from Wicket 1.4.x to 6.x and I have the
   following
  problem with WicketTester.
  I have some secured page, during its initialization some kind of
  AuthorizationException is raised. It should end with displaying
standard
  AccessDeniedPage. Here is a code fragment from test case:
 
  1.4.x:
  RequestCycle.get().setResponsePage(SecuredDummyPage.class);
  tester.processRequestCycle(requestCycle);
  Result result =
 tester.isRenderedPage(AccessDeniedPage.class);
  assertFalse(result.getMessage(), result.wasFailed());
 
  This test is passed.
 
  But in 6.13 the similar test:
  RequestCycle.get().setResponsePage(SecuredDummyPage.class);
  tester.processRequest();
  // or tester.startPage(SecuredDummyPage.class)
  Result result =
 tester.isRenderedPage(AccessDeniedPage.class);
  assertFalse(result.getMessage(), result.wasFailed());
 
  is not passed. It is end up on this AuthorizationException and
  AccessDeniedPage is not rendered.
  Should it be rendered or should I have to change my test, because
  in
6.x
 it
  works in different way?
 
  --
  Daniel
 

   
  
 



Re: WicketTester.isRenderedPage() in 6.13

2014-02-05 Thread Martin Grigorov
Component#setResponsePage() just delegates to
RequestCycle#setResponsePage(). So it is the same.

I'm saying that you should not use tester.getRequestCycle().xyz(). I.e. do
not set the new page in the test code. Set it in the real application code.

Martin Grigorov
Wicket Training and Consulting


On Wed, Feb 5, 2014 at 1:47 PM, Daniel Stoch daniel.st...@gmail.com wrote:

 In my real application there are calls to RequestCycle.setResponsePage(...)
 which are hidden by more advanced action/navigation framework. So I cannot
 simply replace them by component.setResponsePage().
 I think that if RequestCycle.setResponsePage(...) is valid for real
 application, it should also be valid for tests. Am I wrong?

 --
 Daniel


 On Wed, Feb 5, 2014 at 1:14 PM, Martin Grigorov mgrigo...@apache.org
 wrote:

  You should not use
  tester.getRequestCycle().setResponsePage(DummyBasePage.
  class);
 
  You should do something like:
  - in the test code: tester.startPage(Page1.class)
  - in your real application code: Page1 or in its components you can use
  setResponsePage(Page2.class)
  - finally in the test code: tester.assertRenderedPage(Page2.class)
 
 
  Martin Grigorov
  Wicket Training and Consulting
 
 
  On Wed, Feb 5, 2014 at 12:18 PM, Daniel Stoch daniel.st...@gmail.com
  wrote:
 
   Ok, but what I should call to render DummyBasePage after calling:
 tester.getRequestCycle().setResponsePage(DummyBasePage.class);
   without making a new request?
  
   --
   Daniel
  
  
   On Wed, Feb 5, 2014 at 12:01 PM, Martin Grigorov mgrigo...@apache.org
   wrote:
  
#processRequest() triggers a new request to the server
so first the page is rendered, then a new request to the default
destination is made, so the home page is rendered and
  lastRenderedPage
changes
   
Martin Grigorov
Wicket Training and Consulting
   
   
On Wed, Feb 5, 2014 at 11:39 AM, Daniel Stoch 
 daniel.st...@gmail.com
wrote:
   
 One more question: what is a difference between these two calls:

 1.
 tester.startPage(DummyBasePage.class);
 Result result = tester.isRenderedPage(DummyBasePage.class);

 2.
 tester.getRequestCycle().setResponsePage(DummyBasePage.class);
 tester.processRequest();
 Result result = tester.isRenderedPage(DummyBasePage.class);

 The first one works ok (DummyBasePage is rendered), but the second
   fails:
 HomePage is rendered instead of DummyBasePage. Why?

 --
 Daniel



 On Wed, Feb 5, 2014 at 10:40 AM, Martin Grigorov 
  mgrigo...@apache.org
 wrote:

  Try with tester.setExposeExceptions(false) before making the
  request
   to
 the
  secured page
 
  Martin Grigorov
  Wicket Training and Consulting
 
 
  On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch 
   daniel.st...@gmail.com
  wrote:
 
   Hi,
  
   I'm during migration from Wicket 1.4.x to 6.x and I have the
following
   problem with WicketTester.
   I have some secured page, during its initialization some kind
 of
   AuthorizationException is raised. It should end with displaying
 standard
   AccessDeniedPage. Here is a code fragment from test case:
  
   1.4.x:
   RequestCycle.get().setResponsePage(SecuredDummyPage.class);
   tester.processRequestCycle(requestCycle);
   Result result =
  tester.isRenderedPage(AccessDeniedPage.class);
   assertFalse(result.getMessage(), result.wasFailed());
  
   This test is passed.
  
   But in 6.13 the similar test:
   RequestCycle.get().setResponsePage(SecuredDummyPage.class);
   tester.processRequest();
   // or tester.startPage(SecuredDummyPage.class)
   Result result =
  tester.isRenderedPage(AccessDeniedPage.class);
   assertFalse(result.getMessage(), result.wasFailed());
  
   is not passed. It is end up on this AuthorizationException and
   AccessDeniedPage is not rendered.
   Should it be rendered or should I have to change my test,
 because
   in
 6.x
  it
   works in different way?
  
   --
   Daniel
  
 

   
  
 



AjaxRequestTarget.IListener question

2014-02-05 Thread Tom Götz
Hi there,

I’d like to add something to the AjaxRequestTarget at the very end“, i.e. I 
need to be the last one to add something to the target (because I need to check 
some preconditions that might change if the target is manipulated later on).

Reading the Javadoc of 
org.apache.wicket.ajax.AjaxRequestTarget.IListener#onAfterRespond I learned 
that adding components at that stage is already too late. Is there an 
alternative to AjaxRequestTarget.IListener that might do the job?

Cheers,
   -Tom



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



Re: AjaxRequestTarget.IListener question

2014-02-05 Thread Martin Grigorov
Hi,

org.apache.wicket.ajax.AjaxRequestTarget.IListener#onBeforeRespond() is
called after the action phase (e.g. onEvent, onSubmit) and before the
rendering.
Sounds like what you need.

Martin Grigorov
Wicket Training and Consulting


On Wed, Feb 5, 2014 at 4:09 PM, Tom Götz t...@decoded.de wrote:

 Hi there,

 I’d like to add something to the AjaxRequestTarget at the very end“, i.e.
 I need to be the last one to add something to the target (because I need to
 check some preconditions that might change if the target is manipulated
 later on).

 Reading the Javadoc of
 org.apache.wicket.ajax.AjaxRequestTarget.IListener#onAfterRespond I learned
 that adding components at that stage is already too late. Is there an
 alternative to AjaxRequestTarget.IListener that might do the job?

 Cheers,
-Tom



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




Re: AjaxRequestTarget.IListener question

2014-02-05 Thread Tom Götz
Ok, I was misinterpreting the Javadoc of 
org.apache.wicket.ajax.AjaxRequestTarget.IListener#onBeforeRespond: Triggered 
before ajax request target begins its response cycle“. That sounded to me as it 
was called *before* the action phase …

Thanks for the hint, I will try that.

Cheers,
   -Tom


On 05.02.2014, at 16:12, Martin Grigorov mgrigo...@apache.org wrote:

 Hi,
 
 org.apache.wicket.ajax.AjaxRequestTarget.IListener#onBeforeRespond() is
 called after the action phase (e.g. onEvent, onSubmit) and before the
 rendering.
 Sounds like what you need.
 
 Martin Grigorov
 Wicket Training and Consulting
 
 
 On Wed, Feb 5, 2014 at 4:09 PM, Tom Götz t...@decoded.de wrote:
 
 Hi there,
 
 I’d like to add something to the AjaxRequestTarget at the very end“, i.e.
 I need to be the last one to add something to the target (because I need to
 check some preconditions that might change if the target is manipulated
 later on).
 
 Reading the Javadoc of
 org.apache.wicket.ajax.AjaxRequestTarget.IListener#onAfterRespond I learned
 that adding components at that stage is already too late. Is there an
 alternative to AjaxRequestTarget.IListener that might do the job?
 
 Cheers,
   -Tom
 
 
 
 -
 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



Changed JSESSIONID Results in Wicket Exception

2014-02-05 Thread Aaron J. Garcia

Hi Everyone,

I maintain a Wicket application running on Tomcat 7.0.39, and I recently 
altered $TOMCAT_HOME/conf/context.xml to include a sessionCookieName 
parameter.  I made a change like this:


Context sessionCookieName=JSESSIONID_MYAPP

This properly changes the session cookie that is used by Wicket to 
JESSIONID_MYAPP instead of JSESSIONID.  However, when I start up my 
Wicket app, I get the following error spit out to the logs in 
Development mode, when running in Intellij.  Any idea why?


When I was using the normal JSESSIONID, it was properly ignoring it when 
it was appended to the classname for the SignInPage.


Thanks for your help!

-- Aaron

java.lang.ClassNotFoundException: 
my/orgs/package/SignInPage;JSESSIONID_MYAPP=075861AE6FB6CE4ED36F2B5EE01B387B

at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:340)
at 
org.apache.wicket.application.AbstractClassResolver.resolveClass(AbstractClassResolver.java:108)
at 
org.apache.wicket.core.util.lang.WicketObjects.resolveClass(WicketObjects.java:72)
at 
org.apache.wicket.core.request.mapper.AbstractComponentMapper.getPageClass(AbstractComponentMapper.java:139)
at 
org.apache.wicket.core.request.mapper.BookmarkableMapper.parseRequest(BookmarkableMapper.java:118)
at 
org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.mapRequest(AbstractBookmarkableMapper.java:292)
at 
org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(CompoundRequestMapper.java:152)
at 
org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(RequestCycle.java:190)
at 
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:215)
at 
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289)
at 
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259)
at 
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201)
at 
org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:137)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.apache.catalina.filters.ExpiresFilter.doFilter(ExpiresFilter.java:1179)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:947)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1009)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at java.lang.Thread.run(Thread.java:744)

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



Re: Changed JSESSIONID Results in Wicket Exception

2014-02-05 Thread Timo Schmidt
On Wed 05.02.2014 13:12, Aaron J. Garcia wrote:
 Hi Everyone,
 
 I maintain a Wicket application running on Tomcat 7.0.39, and I recently
 altered $TOMCAT_HOME/conf/context.xml to include a sessionCookieName
 parameter.  I made a change like this:
 
 Context sessionCookieName=JSESSIONID_MYAPP
 
 This properly changes the session cookie that is used by Wicket to
 JESSIONID_MYAPP instead of JSESSIONID.  However, when I start up my Wicket
 app, I get the following error spit out to the logs in Development mode,
 when running in Intellij.  Any idea why?
 
 When I was using the normal JSESSIONID, it was properly ignoring it when it
 was appended to the classname for the SignInPage.

See https://issues.apache.org/jira/browse/WICKET-4873

as of Wicket 6.4.0 you may use a different session id name. Set
a system property »wicket.jsessionid.name« to the desired
value.

  -Timo

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



Re: Changed JSESSIONID Results in Wicket Exception

2014-02-05 Thread Aaron J . Garcia
Timo Schmidt wicket at xomit.de writes:

 
 On Wed 05.02.2014 13:12, Aaron J. Garcia wrote:
  Hi Everyone,
  
  I maintain a Wicket application running on Tomcat 7.0.39, and I recently
  altered $TOMCAT_HOME/conf/context.xml to include a sessionCookieName
  parameter.  I made a change like this:
  
  Context sessionCookieName=JSESSIONID_MYAPP
  
  This properly changes the session cookie that is used by Wicket to
  JESSIONID_MYAPP instead of JSESSIONID.  However, when I start up my Wicket
  app, I get the following error spit out to the logs in Development mode,
  when running in Intellij.  Any idea why?
  
  When I was using the normal JSESSIONID, it was properly ignoring it when it
  was appended to the classname for the SignInPage.
 
 See https://issues.apache.org/jira/browse/WICKET-4873
 
 as of Wicket 6.4.0 you may use a different session id name. Set
 a system property »wicket.jsessionid.name« to the desired
 value.
 
   -Timo
 
 -
 To unsubscribe, e-mail: users-unsubscribe at wicket.apache.org
 For additional commands, e-mail: users-help at wicket.apache.org
 
 

This doesn't work for me.  Looking at the source for WicketObjects.java
(where the error is coming from), it seems like the className passed into it
should be passed through Strings.stripJSessionId() before it is attempted to
be resolved.

Should I open a JIRA issue for this change?  

-- Aaron

WARN  - WicketObjects  - Could not resolve class
[org.mine.SignInPage;JSESSIONID_MYAPP=AFAB91436EA86A0DF57057C56DEBEEB4]
java.lang.ClassNotFoundException:
org/mine/SignInPage;JSESSIONID_MYAPP=AFAB91436EA86A0DF57057C56DEBEEB4
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:340)
at org.apache.wicket.application.AbstractClassResolver
  .resolveClass(AbstractClassResolver.java:108)
at org.apache.wicket.core.util.lang.WicketObjects
  .resolveClass(WicketObjects.java:72)

... snip ...


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



Re: Changed JSESSIONID Results in Wicket Exception

2014-02-05 Thread Francois Meillet
Use a system property :
System.setProperty(wicket.jsessionid.name, JSESSIONID_MYAPP);


François Meillet
Formation Wicket - Développement Wicket





Le 5 févr. 2014 à 22:05, Aaron J. Garcia agar...@rentec.com a écrit :

 Timo Schmidt wicket at xomit.de writes:
 
 
 On Wed 05.02.2014 13:12, Aaron J. Garcia wrote:
 Hi Everyone,
 
 I maintain a Wicket application running on Tomcat 7.0.39, and I recently
 altered $TOMCAT_HOME/conf/context.xml to include a sessionCookieName
 parameter.  I made a change like this:
 
 Context sessionCookieName=JSESSIONID_MYAPP
 
 This properly changes the session cookie that is used by Wicket to
 JESSIONID_MYAPP instead of JSESSIONID.  However, when I start up my Wicket
 app, I get the following error spit out to the logs in Development mode,
 when running in Intellij.  Any idea why?
 
 When I was using the normal JSESSIONID, it was properly ignoring it when it
 was appended to the classname for the SignInPage.
 
 See https://issues.apache.org/jira/browse/WICKET-4873
 
 as of Wicket 6.4.0 you may use a different session id name. Set
 a system property »wicket.jsessionid.name« to the desired
 value.
 
  -Timo
 
 -
 To unsubscribe, e-mail: users-unsubscribe at wicket.apache.org
 For additional commands, e-mail: users-help at wicket.apache.org
 
 
 
 This doesn't work for me.  Looking at the source for WicketObjects.java
 (where the error is coming from), it seems like the className passed into it
 should be passed through Strings.stripJSessionId() before it is attempted to
 be resolved.
 
 Should I open a JIRA issue for this change?  
 
 -- Aaron
 
 WARN  - WicketObjects  - Could not resolve class
 [org.mine.SignInPage;JSESSIONID_MYAPP=AFAB91436EA86A0DF57057C56DEBEEB4]
 java.lang.ClassNotFoundException:
 org/mine/SignInPage;JSESSIONID_MYAPP=AFAB91436EA86A0DF57057C56DEBEEB4
   at java.lang.Class.forName0(Native Method)
   at java.lang.Class.forName(Class.java:340)
   at org.apache.wicket.application.AbstractClassResolver
  .resolveClass(AbstractClassResolver.java:108)
   at org.apache.wicket.core.util.lang.WicketObjects
  .resolveClass(WicketObjects.java:72)
 
 ... snip ...
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 



Modularity in Wicket Application

2014-02-05 Thread Richter, Marvin
Hey guys,

hope you can help me with this.

I’m currently in the preparation phase of a new Project and evaluating possible 
technologies.
What I already know: the Web part will be done with Wicket.

The application will be some kind of management tool for others applications 
configuration.
To support future applications configuration it would be nice to just need to 
develop „Plugins“ for the new application and just drop them into the 
management tool.

Did anyone something like this already? If so, how did you do this? Which 
technology did you use to support modularity in a wicket application?

I’m thankful for any advice.

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



Re: Modularity in Wicket Application

2014-02-05 Thread Martin Grigorov
Hi,

Look in the archives for plugin and IInitializer.
Wicket's IInitializer is very simple solution for this.
Also Decebal Suiu have implemented https://github.com/decebals/wicket-plugin

Martin Grigorov
Wicket Training and Consulting


On Wed, Feb 5, 2014 at 11:17 PM, Richter, Marvin 
marvin.rich...@jestadigital.com wrote:

 Hey guys,

 hope you can help me with this.

 I’m currently in the preparation phase of a new Project and evaluating
 possible technologies.
 What I already know: the Web part will be done with Wicket.

 The application will be some kind of management tool for others
 applications configuration.
 To support future applications configuration it would be nice to just need
 to develop „Plugins“ for the new application and just drop them into the
 management tool.

 Did anyone something like this already? If so, how did you do this? Which
 technology did you use to support modularity in a wicket application?

 I’m thankful for any advice.

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




Re: Changed JSESSIONID Results in Wicket Exception

2014-02-05 Thread Martin Grigorov
Hi,

I will test this tomorrow.

Martin Grigorov
Wicket Training and Consulting


On Wed, Feb 5, 2014 at 11:09 PM, Francois Meillet 
francois.meil...@gmail.com wrote:

 Use a system property :
 System.setProperty(wicket.jsessionid.name, JSESSIONID_MYAPP);


 François Meillet
 Formation Wicket - Développement Wicket





 Le 5 févr. 2014 à 22:05, Aaron J. Garcia agar...@rentec.com a écrit :

  Timo Schmidt wicket at xomit.de writes:
 
 
  On Wed 05.02.2014 13:12, Aaron J. Garcia wrote:
  Hi Everyone,
 
  I maintain a Wicket application running on Tomcat 7.0.39, and I
 recently
  altered $TOMCAT_HOME/conf/context.xml to include a sessionCookieName
  parameter.  I made a change like this:
 
  Context sessionCookieName=JSESSIONID_MYAPP
 
  This properly changes the session cookie that is used by Wicket to
  JESSIONID_MYAPP instead of JSESSIONID.  However, when I start up my
 Wicket
  app, I get the following error spit out to the logs in Development
 mode,
  when running in Intellij.  Any idea why?
 
  When I was using the normal JSESSIONID, it was properly ignoring it
 when it
  was appended to the classname for the SignInPage.
 
  See https://issues.apache.org/jira/browse/WICKET-4873
 
  as of Wicket 6.4.0 you may use a different session id name. Set
  a system property »wicket.jsessionid.name« to the desired
  value.
 
   -Timo
 
  -
  To unsubscribe, e-mail: users-unsubscribe at wicket.apache.org
  For additional commands, e-mail: users-help at wicket.apache.org
 
 
 
  This doesn't work for me.  Looking at the source for WicketObjects.java
  (where the error is coming from), it seems like the className passed
 into it
  should be passed through Strings.stripJSessionId() before it is
 attempted to
  be resolved.
 
  Should I open a JIRA issue for this change?
 
  -- Aaron
 
  WARN  - WicketObjects  - Could not resolve class
  [org.mine.SignInPage;JSESSIONID_MYAPP=AFAB91436EA86A0DF57057C56DEBEEB4]
  java.lang.ClassNotFoundException:
  org/mine/SignInPage;JSESSIONID_MYAPP=AFAB91436EA86A0DF57057C56DEBEEB4
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:340)
at org.apache.wicket.application.AbstractClassResolver
   .resolveClass(AbstractClassResolver.java:108)
at org.apache.wicket.core.util.lang.WicketObjects
   .resolveClass(WicketObjects.java:72)
 
  ... snip ...
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 




Re: Changed JSESSIONID Results in Wicket Exception

2014-02-05 Thread Aaron J . Garcia
Martin Grigorov mgrigorov at apache.org writes:


 Hi,
 
 I will test this tomorrow.
 
 Martin Grigorov
 Wicket Training and Consulting

Thanks Martin,

FWIW, I was setting this when running Tomcat:

-Dwicket.jsessionid.name=JSESSIONID_MYAPP

It didn't work with the -D option, so I added it to my class that extends
WebApplication, like so:

System.setProperty(wicket.jsessionid.name, JSESSIONID_MYAPP);

and that didn't work either.

I'm happy to help pinpoint the issue however I can.  Please let me know.

-- Aaron


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



Re: Modularity in Wicket Application

2014-02-05 Thread Shengche Hsiao
Hello
What's the difference of PF4J and osgi ?
On Feb 6, 2014 6:37 AM, Martin Grigorov mgrigo...@apache.org wrote:

 Hi,

 Look in the archives for plugin and IInitializer.
 Wicket's IInitializer is very simple solution for this.
 Also Decebal Suiu have implemented
 https://github.com/decebals/wicket-plugin

 Martin Grigorov
 Wicket Training and Consulting


 On Wed, Feb 5, 2014 at 11:17 PM, Richter, Marvin 
 marvin.rich...@jestadigital.com wrote:

  Hey guys,
 
  hope you can help me with this.
 
  I'm currently in the preparation phase of a new Project and evaluating
  possible technologies.
  What I already know: the Web part will be done with Wicket.
 
  The application will be some kind of management tool for others
  applications configuration.
  To support future applications configuration it would be nice to just
 need
  to develop Plugins for the new application and just drop them into the
  management tool.
 
  Did anyone something like this already? If so, how did you do this? Which
  technology did you use to support modularity in a wicket application?
 
  I'm thankful for any advice.
 
  Marvin
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 



Re: Modularity in Wicket Application

2014-02-05 Thread Richter, Marvin
Thanks Martin,

sometimes I’m astonished how fast you reply … ;)

The wicket-plugin project is exactly what I was looking for.

Am 05.02.2014 um 23:37 schrieb Martin Grigorov mgrigo...@apache.org:

 Hi,
 
 Look in the archives for plugin and IInitializer.
 Wicket's IInitializer is very simple solution for this.
 Also Decebal Suiu have implemented https://github.com/decebals/wicket-plugin
 
 Martin Grigorov
 Wicket Training and Consulting
 
 
 On Wed, Feb 5, 2014 at 11:17 PM, Richter, Marvin 
 marvin.rich...@jestadigital.com wrote:
 
 Hey guys,
 
 hope you can help me with this.
 
 I’m currently in the preparation phase of a new Project and evaluating
 possible technologies.
 What I already know: the Web part will be done with Wicket.
 
 The application will be some kind of management tool for others
 applications configuration.
 To support future applications configuration it would be nice to just need
 to develop „Plugins“ for the new application and just drop them into the
 management tool.
 
 Did anyone something like this already? If so, how did you do this? Which
 technology did you use to support modularity in a wicket application?
 
 I’m thankful for any advice.
 
 Marvin
 -
 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



[CALL FOR INTEREST] Integrate Wicket and Nutch for Google Summer of Code 2014

2014-02-05 Thread Lewis John Mcgibbney
Hi users@,
My name is Lewis, I am a committer over on Apache Nutch. I'm writing to the
users@ list in an attempt to interest students in participating in this
years GSoC[0].
The idea is to create a Wicket-based Web Application for Nutch as a GSoC
project.
For those that might be interested, the project idea can be seen here [1].
There are other issues linked to from this issue.
Basically we currently have a working Restlet [2] REST API for Nutch 2.x
and would love to develop a killer Wicket Web App on top.
It would be very much appreciated if any potential students could contact
me directly or head over to d...@nutch.apache.org so we can gather interest
in the project and begin to move things forward.
I've also written to the dev@wicket list regarding this topic so hopefully
there will be some interest.
Thank you in advance
Lewis

[0] https://developers.google.com/open-source/soc/?csw=1
[1] https://issues.apache.org/jira/browse/NUTCH-841
[2] http://restlet.org/

-- 
*Lewis*


Re: tinymce textarea in a modal window not letting to type

2014-02-05 Thread jchappelle
I am having this same issue in wicket 6.13.0. Any fixes as of yet?

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/tinymce-textarea-in-a-modal-window-not-letting-to-type-tp1886534p4664214.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