Re: What IDE best fits with Wicket?

[Emond Papegaaij]

That is the plugin Martijn is talking about, and I am one of the co-workers he 
mentioned. I tried the m2eclipse plugin and used it for a day. The plugin 
(version 0.9.7.200902090947) was able to checkout the project from svn and 
create eclipse projects for all modules, so far so good, although the browse 
button in the svn window didn't work. At that moment the trouble started.

Somehow, after even the slightest code change, eclipse started to rebuild the 
entire project over and over, taking ages. After some more changes (some of 
them might have been in the pom), some of my projects got corrupted and I had 
to clean everything, doing a complete rebuild. A few hours later, while I was 
working on a Java file, about 30,000 errors suddenly appeared. Somehow, 
m2eclipse had reversed some of my module-to-module dependencies. I tried 
cleaning, updating, refreshing the project configuration, nothing helped. I was 
unable to get the project to build again.

My experience with m2eclipse is that it is slow and very unstable. My last 
attempt was not the first attempt. I tried to use it several times, because 
running mvn eclipse:eclipse all the time is just a pain in the *, but every 
time I ran into some strange problem I could not solve.

Emond Papegaaij

On Thursday 26 February 2009 17:20:04 Brill Pappin wrote:
 I don't think we're talking about the same plugin then (although you
 seem to be calling it the same thing)...
 I'm referring to:

  http://m2eclipse.codehaus.org/

 It's the *only* one I've found that *actually works* properly,
 particularly for larger projects... although I run the dev version so
 I'm not sure how well the released version is working at this moment.
 Of course I could simply go back to the console and use the maven
 plugin to generate the eclipse project files, but I find the plugin to
 be light-years ahead in maintaining a clean build env.

 I guess people's experience with various tools also depends a lot on
 *how* they work not just what they work with :)


 - Brill Pappin

 On 24-Feb-09, at 12:38 PM, Martijn Dashorst wrote:
  m2eclipse is absolutely worthless for anything beyond a quickstart. It
  is constantly reparsing poms, grinding eclipse to a halt. It failed to
  generate the right project dependencies for our multimodule project
  that consists of 2 multimodule child projects. It failed miserably to
  uninstall, needing me to axe my eclipse installation.
 
  In short: my experience (and that of my co-workers) with m2eclipse is
  that it is far from ready for prime time.
 
  Martijn
 
  On Tue, Feb 24, 2009 at 5:55 PM, Brill Pappin br...@pappin.ca wrote:
  I should add something about the Eclipse maven plugins... don't go
  for the
  official eclipse Q4 plugin... use the Maven Integration 4 Eclipse
  plugin
  (and actually the development version if your jiggy with it, it
  works and
  gets updated/fixed way more often).
 
  If your on Netbeans, I think Maven will generate Netbeans project
  files for
  you as well (it will do so for eclipse), so you could actually flip
  back and
  forth if you wanted.
 
  - Brill Pappin
 
  On 23-Feb-09, at 5:19 PM, Pierre Goupil wrote:
  +1, I like Wicket Bench. And with M2Eclipse, you have the full
  sources 
  JavaDoc just by adding Wicket as a dependency, which is very
  convenient.
  But
  don't expect Wicket Bench to do too much, it's just a small,
  useful tool.
 
  Pierre
 
  Hi, I use Eclipse with Wicket Bench plugin and it works very fine.
 
  --
  Sans amis était le grand maître des mondes,
  Eprouvait manque, ce pour quoi il créa les esprits,
  Miroirs bienveillants de sa béatitude.
  Mais au vrai, il ne trouva aucun égal,
  Du calice du royaume total des âmes
  Ecume jusqu'à lui l'infinité.
 
  (Schiller, l'amitié)
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
  --
  Become a Wicket expert, learn from the best: http://wicketinaction.com
  Apache Wicket 1.3.5 is released
  Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
 
  -
  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


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

Re: What IDE best fits with Wicket?

[Emond Papegaaij]

Yes, mvn eclipse:eclipse works, but it's not really integrating maven in 
eclipse. I have to run it manually after changing the pom or the project 
structure and it often results in a complete rebuild of all projects.

On Friday 27 February 2009 10:08:58 nino martinez wael wrote:
 I just use mvn eclipse:eclipse , it works every time :)

 2009/2/27 Emond Papegaaij emond.papega...@topicus.nl

  That is the plugin Martijn is talking about, and I am one of the
  co-workers he
  mentioned. I tried the m2eclipse plugin and used it for a day. The plugin
  (version 0.9.7.200902090947) was able to checkout the project from svn
  and create eclipse projects for all modules, so far so good, although the
  browse
  button in the svn window didn't work. At that moment the trouble started.
 
  Somehow, after even the slightest code change, eclipse started to rebuild
  the
  entire project over and over, taking ages. After some more changes (some
  of them might have been in the pom), some of my projects got corrupted
  and I had
  to clean everything, doing a complete rebuild. A few hours later, while I
  was
  working on a Java file, about 30,000 errors suddenly appeared. Somehow,
  m2eclipse had reversed some of my module-to-module dependencies. I tried
  cleaning, updating, refreshing the project configuration, nothing helped.
  I was
  unable to get the project to build again.
 
  My experience with m2eclipse is that it is slow and very unstable. My
  last attempt was not the first attempt. I tried to use it several times,
  because running mvn eclipse:eclipse all the time is just a pain in the *,
  but every time I ran into some strange problem I could not solve.
 
  Emond Papegaaij
 
  On Thursday 26 February 2009 17:20:04 Brill Pappin wrote:
   I don't think we're talking about the same plugin then (although you
   seem to be calling it the same thing)...
   I'm referring to:
  
http://m2eclipse.codehaus.org/
  
   It's the *only* one I've found that *actually works* properly,
   particularly for larger projects... although I run the dev version so
   I'm not sure how well the released version is working at this moment.
   Of course I could simply go back to the console and use the maven
   plugin to generate the eclipse project files, but I find the plugin to
   be light-years ahead in maintaining a clean build env.
  
   I guess people's experience with various tools also depends a lot on
   *how* they work not just what they work with :)
  
  
   - Brill Pappin
  
   On 24-Feb-09, at 12:38 PM, Martijn Dashorst wrote:
m2eclipse is absolutely worthless for anything beyond a quickstart.
It is constantly reparsing poms, grinding eclipse to a halt. It
failed to generate the right project dependencies for our multimodule
project that consists of 2 multimodule child projects. It failed
miserably to uninstall, needing me to axe my eclipse installation.
   
In short: my experience (and that of my co-workers) with m2eclipse is
that it is far from ready for prime time.
   
Martijn
   
On Tue, Feb 24, 2009 at 5:55 PM, Brill Pappin br...@pappin.ca wrote:
I should add something about the Eclipse maven plugins... don't go
for the
official eclipse Q4 plugin... use the Maven Integration 4 Eclipse
plugin
(and actually the development version if your jiggy with it, it
works and
gets updated/fixed way more often).
   
If your on Netbeans, I think Maven will generate Netbeans project
files for
you as well (it will do so for eclipse), so you could actually flip
back and
forth if you wanted.
   
- Brill Pappin
   
On 23-Feb-09, at 5:19 PM, Pierre Goupil wrote:
+1, I like Wicket Bench. And with M2Eclipse, you have the full
sources 
JavaDoc just by adding Wicket as a dependency, which is very
convenient.
But
don't expect Wicket Bench to do too much, it's just a small,
useful tool.
   
Pierre
   
Hi, I use Eclipse with Wicket Bench plugin and it works very fine.
   
--
Sans amis était le grand maître des mondes,
Eprouvait manque, ce pour quoi il créa les esprits,
Miroirs bienveillants de sa béatitude.
Mais au vrai, il ne trouva aucun égal,
Du calice du royaume total des âmes
Ecume jusqu'à lui l'infinité.
   
(Schiller, l'amitié)
   

   - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For
additional commands, e-mail: users-h...@wicket.apache.org
   
--
Become a Wicket expert, learn from the best:
http://wicketinaction.com Apache Wicket 1.3.5 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
   
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: What IDE best fits with Wicket?

[Emond Papegaaij]

Some of the benefits are:
 - You can edit the pom and the results are immediately visible (like when 
editing java code).
 - Working with snapshots is much easier. You just checkout the project and 
m2eclipse removes the jar dependency and adds a project dependency. This saves 
you from performing a deploy and eclipse:eclipse cycle on every update.
 - Eclipse projects are created automatically for multi-module projects. You 
don't have to import them by hand.
 - You don't need a prompt to update.

On Friday 27 February 2009 11:49:21 nino martinez wael wrote:
 Sure, if you change project structure, you need to invoke mvn
 eclipse:eclipse one projects that are changed.. But it works... And true
 it's not integrated in eclipse..

 I just dont see what the integrations bring, but It might just be because I
 too have been unlucky, when I tried m2eclipse...

 The subversion (subversive) integration though, that I see the benefits of
 (and for me it works 95% of the time)...

 2009/2/27 Emond Papegaaij emond.papega...@topicus.nl

  Yes, mvn eclipse:eclipse works, but it's not really integrating maven in
  eclipse. I have to run it manually after changing the pom or the project
  structure and it often results in a complete rebuild of all projects.
 
  On Friday 27 February 2009 10:08:58 nino martinez wael wrote:
   I just use mvn eclipse:eclipse , it works every time :)
  
   2009/2/27 Emond Papegaaij emond.papega...@topicus.nl
  
That is the plugin Martijn is talking about, and I am one of the
co-workers he
mentioned. I tried the m2eclipse plugin and used it for a day. The
 
  plugin
 
(version 0.9.7.200902090947) was able to checkout the project from
svn and create eclipse projects for all modules, so far so good,
although
 
  the
 
browse
button in the svn window didn't work. At that moment the trouble
 
  started.
 
Somehow, after even the slightest code change, eclipse started to
 
  rebuild
 
the
entire project over and over, taking ages. After some more changes
 
  (some
 
of them might have been in the pom), some of my projects got
corrupted and I had
to clean everything, doing a complete rebuild. A few hours later,
while
 
  I
 
was
working on a Java file, about 30,000 errors suddenly appeared.
Somehow, m2eclipse had reversed some of my module-to-module
dependencies. I
 
  tried
 
cleaning, updating, refreshing the project configuration, nothing
 
  helped.
 
I was
unable to get the project to build again.
   
My experience with m2eclipse is that it is slow and very unstable. My
last attempt was not the first attempt. I tried to use it several
 
  times,
 
because running mvn eclipse:eclipse all the time is just a pain in
the
 
  *,
 
but every time I ran into some strange problem I could not solve.
   
Emond Papegaaij
   
On Thursday 26 February 2009 17:20:04 Brill Pappin wrote:
 I don't think we're talking about the same plugin then (although
 you seem to be calling it the same thing)...
 I'm referring to:

  http://m2eclipse.codehaus.org/

 It's the *only* one I've found that *actually works* properly,
 particularly for larger projects... although I run the dev version
 so I'm not sure how well the released version is working at this
 moment. Of course I could simply go back to the console and use the
 maven plugin to generate the eclipse project files, but I find the
 plugin
 
  to
 
 be light-years ahead in maintaining a clean build env.

 I guess people's experience with various tools also depends a lot
 on *how* they work not just what they work with :)


 - Brill Pappin

 On 24-Feb-09, at 12:38 PM, Martijn Dashorst wrote:
  m2eclipse is absolutely worthless for anything beyond a
  quickstart. It is constantly reparsing poms, grinding eclipse to
  a halt. It failed to generate the right project dependencies for
  our
 
  multimodule
 
  project that consists of 2 multimodule child projects. It failed
  miserably to uninstall, needing me to axe my eclipse
  installation.
 
  In short: my experience (and that of my co-workers) with
  m2eclipse
 
  is
 
  that it is far from ready for prime time.
 
  Martijn
 
  On Tue, Feb 24, 2009 at 5:55 PM, Brill Pappin br...@pappin.ca
 
  wrote:
  I should add something about the Eclipse maven plugins... don't
  go for the
  official eclipse Q4 plugin... use the Maven Integration 4
 
  Eclipse
 
  plugin
  (and actually the development version if your jiggy with it, it
  works and
  gets updated/fixed way more often).
 
  If your on Netbeans, I think Maven will generate Netbeans
  project files for
  you as well (it will do so for eclipse), so you could actually
 
  flip
 
  back and
  forth if you wanted.
 
  - Brill Pappin
 
  On 23

setRequired on CheckBox

[Emond Papegaaij]

Hello all,

During the development of a (somewhat) generic form component, I stumbled on 
the following error:
FormComponent can't be not required when the type is primitive class: 
[MarkupContainer [Component id = formField, page = No Page, path = 
formField.CheckBox]]

This is caused by calling setType(Boolean.TYPE) and setRequired(false) on a 
CheckBox component. setRequired checks if the type is a primitive and throws 
an exception when an attempt is made to make the component not required for a 
primitive. Although I think this is a good thing for most components, I don't 
think this behaviour can be applied on a CheckBox, because of the (slightly) 
different interpretation of required on a CheckBox (WICKET-1221). Perhaps 
CheckBox should override setRequired to not throw the Exception? Right now, I 
am required to always check a CheckBox when I set the type to Boolean.TYPE.

Best regards,
Emond Papegaaij

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: question about swarm

[Emond Papegaaij]

Hi,

Your change breaks some functionality. It is now no longer possible to grant 
permissions for anonymous inner classes at all, you are now forced to grant 
the permission on the superclass. This might seem sensible when using a hive 
file, but it is not when permissions are configured in other ways.

We create permissions by annotating components with an @InPrincipal 
annotation. It is possible to create a (abstract) component and have multiple, 
anonymous subclasses, each with their own @InPrincipal annotation.

I think, this should be fixed with a special ComponentPermission: one that 
does not only give permission to the specified class, but also to its 
subclasses. This could be achieved by extending ComponentPermission and 
overriding the implies method. The first part of the the path array should 
contain the classname of the component.

Best regards,
Emond Papegaaij

On Thursday 31 December 2009 23:31:34 Olger Warnier wrote:
 Hi Sam,
 
 Found the way to solve it. It is fixed in the trunk. Still need to fix the
  build server - so a check out and build of the whole is probably best. An
  anonymous class will act like its' parent now.
 
 Happy new year (to you all).
 
 Olger
 
 On 31 dec 2009, at 22:43, s...@sambarrow.com wrote:
  In my opinion, that's how it should work; just seems like common sense to
  me. Even for regular (non-anonymous) classes, it would be useful although
  that's not as important.
 
  As far as the technical part I have no idea. I've only been working with
  swam for 3 days. But I will do some looking at the source code.
 
  Sent via BlackBerry from T-Mobile
 
  -Original Message-
  From: Olger Warnier ol...@xs4all.nl
  Date: Thu, 31 Dec 2009 22:35:22
  To: users@wicket.apache.org
  Subject: Re: question about swarm
 
  Hi Sam  Jeremy,
 
  Together with the remark that Jeremy made - I agree, it is quite fragile
  - I had a look at the code that does the checks. I could 'assume' that an
  anonymous class needs the same rights as the 'normal' class. so when your
  CreateItemPage has the proper rights, an anonymous variant has the
  similar rights.
 
  The other way is some kind of inheritance assumption. This needs some
  kind of syntax in the hive file like the 'inherit' that is currently
  available. This inherit is more page with child component 'inheritance'
  and not like in OO thinking (If understand this completely). With this in
  mind, I would say that treating an anonymous class as the class it
  'extends' may be the best. I tried to figure out how to recognize an
  anonymous class. It seems that Class.getSimpleName =  or a search to
  $[0-9] in getName is a solution but it seems risky when you use a non-sun
  JVM.
 
  What do you think ?
 
  Kind Regards,
 
  Olger
 
  On 31 dec 2009, at 10:53, Sam Barrow wrote:
  I know I can do that, but there's no way do do it by inheritance? I have
  hundreds of anonymous subclasses throughout my application. Seems
  sensible that subclasses should inherit their parent's permissions.
 
  On Thu, 2009-12-31 at 10:41 +0100, Olger Warnier wrote:
  Hi Sam,
 
  I have added a sample to the secureform sample where the home page
  creates an anonymous class of the MySecurePage An anonymous page has a
  kind of a class name. Look for a
 
  ERROR - RequestCycle   - Not authorized to instantiate
  class org.apache.wicket.security.examples.secureform.pages.HomePage$2$1
  org.apache.wicket.authorization.UnauthorizedInstantiationException: Not
  authorized to instantiate class
  org.apache.wicket.security.examples.secureform.pages.HomePage$2$1
 
  And add the line to the hive:
 
permission ${ComponentPermission}
  org.apache.wicket.security.examples.secureform.pages.HomePage$2$1,
  render, enable;
 
  As you can see it does not contain a line with the target response page
  but a line that contains the setResponsePage call. So you need to add a
  line that contains the 'name' of the anonymous class to the hive.
 
 
  Kind Regards,
 
  Olger
 
  On 31 dec 2009, at 02:46, Sam Barrow wrote:
  I hope this is the right list for wasp/swarm.
  How do i manage permissions for an anonymous subclass?
 
  I have a page called ItemPage. I can view ItemPage, but if I try to
  redirect to an anonymous subclass of ItemPage, i get an access denied
  error.
 
  this works:
  setResponsePage(new CreateItemPage(getPage()));
 
  but this doesnt:
  setResponsePage(new CreateItemPage(getPage()) {
   @Override
   protected void onSuccess(final Serializable index) {
   setResponsePage(new ViewItemPage(getBackPage(), index));
   }
  });
 
  hive file:
 
  permission ${ComponentPermission} ${pages}.CreateItemPage, inherit,
  render;
  permission ${ComponentPermission} ${pages}.CreateItemPage, enable;
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org

Re: question about swarm

[Emond Papegaaij]

Hi Olger,

The InPrincipal annotation is something we developed as an alternative for the 
hive files (which we find difficult to maintain, not only with anonymous inner 
classes). Principals are defined by a set of classes with annotations defining 
things like implies relations between principals and DataPermissions. 
ComponentPermissions are created by scanning for components with the 
InPrincipal annotation and creating the permissions for those. We are thinking 
about releasing this code, perhaps by including it in wicket-security.

When using a hive file, you define your principals, each with a set of 
permissions. Currently, you can use ComponentPermission, DataPermission and 
AllPermissions. My suggestion is to add another permission that gives 
permissions to a component and all of its subclasses (including anonymous 
classes), something like:

permission ${ComponentSubclassPermission} MyPage, inherit, render;

This would give you permission for MyPage and its subclasses. You can define 
the alias for ComponentSubclassPermission in SwarmPolicyFileHiveFactory. I 
think that this is the way Swarm/Wasp is 'supposed to be used'.

Best regards,
Emond

On Wednesday 06 January 2010 13:09:09 Olger Warnier wrote:
 Hi Emond,
 
 Thanks for your comments, Interesting matter. Extending ComponentPermission
  to change the behavior sounds like an option. I can't find the
  @InPrincipal annotation in the wicket-security project, is this something
  specific ?
 
 When you look at it from the 'hive' side: It is the standard way of working
  with Swarm/Wasp, isn't it ? That current way has a quite fragile way to
  define the authorization rules on anonymous inner classes. How to deal
  with that ?
 
 Is it an option to contribute your annotations with a specific
  AnnotatedPermission ? That would be really great.
 
 Kind Regards,
 
 Olger
 
 On 6 jan 2010, at 12:52, Emond Papegaaij wrote:
  Hi,
 
  Your change breaks some functionality. It is now no longer possible to
  grant permissions for anonymous inner classes at all, you are now forced
  to grant the permission on the superclass. This might seem sensible when
  using a hive file, but it is not when permissions are configured in other
  ways.
 
  We create permissions by annotating components with an @InPrincipal
  annotation. It is possible to create a (abstract) component and have
  multiple, anonymous subclasses, each with their own @InPrincipal
  annotation.
 
  I think, this should be fixed with a special ComponentPermission: one
  that does not only give permission to the specified class, but also to
  its subclasses. This could be achieved by extending ComponentPermission
  and overriding the implies method. The first part of the the path array
  should contain the classname of the component.
 
  Best regards,
  Emond Papegaaij
 
  On Thursday 31 December 2009 23:31:34 Olger Warnier wrote:
  Hi Sam,
 
  Found the way to solve it. It is fixed in the trunk. Still need to fix
  the build server - so a check out and build of the whole is probably
  best. An anonymous class will act like its' parent now.
 
  Happy new year (to you all).
 
  Olger
 
  On 31 dec 2009, at 22:43, s...@sambarrow.com wrote:
  In my opinion, that's how it should work; just seems like common sense
  to me. Even for regular (non-anonymous) classes, it would be useful
  although that's not as important.
 
  As far as the technical part I have no idea. I've only been working
  with swam for 3 days. But I will do some looking at the source code.
 
  Sent via BlackBerry from T-Mobile
 
  -Original Message-
  From: Olger Warnier ol...@xs4all.nl
  Date: Thu, 31 Dec 2009 22:35:22
  To: users@wicket.apache.org
  Subject: Re: question about swarm
 
  Hi Sam  Jeremy,
 
  Together with the remark that Jeremy made - I agree, it is quite
  fragile - I had a look at the code that does the checks. I could
  'assume' that an anonymous class needs the same rights as the 'normal'
  class. so when your CreateItemPage has the proper rights, an anonymous
  variant has the similar rights.
 
  The other way is some kind of inheritance assumption. This needs some
  kind of syntax in the hive file like the 'inherit' that is currently
  available. This inherit is more page with child component 'inheritance'
  and not like in OO thinking (If understand this completely). With this
  in mind, I would say that treating an anonymous class as the class it
  'extends' may be the best. I tried to figure out how to recognize an
  anonymous class. It seems that Class.getSimpleName =  or a search to
  $[0-9] in getName is a solution but it seems risky when you use a
  non-sun JVM.
 
  What do you think ?
 
  Kind Regards,
 
  Olger
 
  On 31 dec 2009, at 10:53, Sam Barrow wrote:
  I know I can do that, but there's no way do do it by inheritance? I
  have hundreds of anonymous subclasses throughout my application. Seems
  sensible that subclasses should inherit their parent's permissions.
 
  On Thu, 2009-12-31

Re: question about swarm

[Emond Papegaaij]

Well, provided you've implemented the ComponentSubclassPermission, you could 
overwrite the alias for ComponentPermission by subclassing the 
SwarmPolicyFileHiveFactory like this:

public class MyFileHiveFactory extends SwarmPolicyFileHiveFactory {
public MyFileHiveFactory(ActionFactory actionFactory) {
super(actionFactory);
setAlias(ComponentPermission, 
my.ComponentSubclassPermission);
}
}

This would replace the usage of ComponentPermission by 
ComponentSubclassPermission and requires no change to the hive file.

Emond


On Thursday 07 January 2010 11:09:52 Olger Warnier wrote:
 Hi Emond,
 
 Very nice. Could you think of a way to support your scenario and a way to
  support anonymous classes in a way that you don't have to specify a
  MyPageClass$1$2 and we don't have to impose a change in the hive file ?
 
 Kind Regards,
 
 Olger
 
 On 6 jan 2010, at 14:03, Emond Papegaaij wrote:
  Hi Olger,
 
  The InPrincipal annotation is something we developed as an alternative
  for the hive files (which we find difficult to maintain, not only with
  anonymous inner classes). Principals are defined by a set of classes with
  annotations defining things like implies relations between principals and
  DataPermissions. ComponentPermissions are created by scanning for
  components with the InPrincipal annotation and creating the permissions
  for those. We are thinking about releasing this code, perhaps by
  including it in wicket-security.
 
  When using a hive file, you define your principals, each with a set of
  permissions. Currently, you can use ComponentPermission, DataPermission
  and AllPermissions. My suggestion is to add another permission that gives
  permissions to a component and all of its subclasses (including anonymous
  classes), something like:
 
  permission ${ComponentSubclassPermission} MyPage, inherit, render;
 
  This would give you permission for MyPage and its subclasses. You can
  define the alias for ComponentSubclassPermission in
  SwarmPolicyFileHiveFactory. I think that this is the way Swarm/Wasp is
  'supposed to be used'.
 
  Best regards,
  Emond
 
  On Wednesday 06 January 2010 13:09:09 Olger Warnier wrote:
  Hi Emond,
 
  Thanks for your comments, Interesting matter. Extending
  ComponentPermission to change the behavior sounds like an option. I
  can't find the
  @InPrincipal annotation in the wicket-security project, is this
  something specific ?
 
  When you look at it from the 'hive' side: It is the standard way of
  working with Swarm/Wasp, isn't it ? That current way has a quite fragile
  way to define the authorization rules on anonymous inner classes. How to
  deal with that ?
 
  Is it an option to contribute your annotations with a specific
  AnnotatedPermission ? That would be really great.
 
  Kind Regards,
 
  Olger
 
  On 6 jan 2010, at 12:52, Emond Papegaaij wrote:
  Hi,
 
  Your change breaks some functionality. It is now no longer possible to
  grant permissions for anonymous inner classes at all, you are now
  forced to grant the permission on the superclass. This might seem
  sensible when using a hive file, but it is not when permissions are
  configured in other ways.
 
  We create permissions by annotating components with an @InPrincipal
  annotation. It is possible to create a (abstract) component and have
  multiple, anonymous subclasses, each with their own @InPrincipal
  annotation.
 
  I think, this should be fixed with a special ComponentPermission: one
  that does not only give permission to the specified class, but also to
  its subclasses. This could be achieved by extending ComponentPermission
  and overriding the implies method. The first part of the the path array
  should contain the classname of the component.
 
  Best regards,
  Emond Papegaaij
 
  On Thursday 31 December 2009 23:31:34 Olger Warnier wrote:
  Hi Sam,
 
  Found the way to solve it. It is fixed in the trunk. Still need to fix
  the build server - so a check out and build of the whole is probably
  best. An anonymous class will act like its' parent now.
 
  Happy new year (to you all).
 
  Olger
 
  On 31 dec 2009, at 22:43, s...@sambarrow.com wrote:
  In my opinion, that's how it should work; just seems like common
  sense to me. Even for regular (non-anonymous) classes, it would be
  useful although that's not as important.
 
  As far as the technical part I have no idea. I've only been working
  with swam for 3 days. But I will do some looking at the source code.
 
  Sent via BlackBerry from T-Mobile
 
  -Original Message-
  From: Olger Warnier ol...@xs4all.nl
  Date: Thu, 31 Dec 2009 22:35:22
  To: users@wicket.apache.org
  Subject: Re: question about swarm
 
  Hi Sam  Jeremy,
 
  Together with the remark that Jeremy made - I agree, it is quite
  fragile - I had a look at the code that does the checks. I could
  'assume' that an anonymous class needs the same rights as the
  'normal' class. so when your CreateItemPage has

Re: question about swarm

[Emond Papegaaij]

Hi,

I've just reverted your change (which breaks backward compatibility) and added 
the ComponentSubclassPermission. I've updated the secure forms example to use 
this permission. To replace the default ComponentPermission with 
ComponentSubclassPermission, use the construction below (with 
org.apache.wicket.security.hive.authorization.permissions.ComponentSubclassPermission).

Best regards,
Emond Papegaaij

On Thursday 07 January 2010 12:42:17 Emond Papegaaij wrote:
 Well, provided you've implemented the ComponentSubclassPermission, you
  could overwrite the alias for ComponentPermission by subclassing the
 SwarmPolicyFileHiveFactory like this:
 
 public class MyFileHiveFactory extends SwarmPolicyFileHiveFactory {
   public MyFileHiveFactory(ActionFactory actionFactory) {
   super(actionFactory);
   setAlias(ComponentPermission, 
 my.ComponentSubclassPermission);
   }
 }
 
 This would replace the usage of ComponentPermission by
 ComponentSubclassPermission and requires no change to the hive file.
 
 Emond
 
 On Thursday 07 January 2010 11:09:52 Olger Warnier wrote:
  Hi Emond,
 
  Very nice. Could you think of a way to support your scenario and a way to
   support anonymous classes in a way that you don't have to specify a
   MyPageClass$1$2 and we don't have to impose a change in the hive file ?
 
  Kind Regards,
 
  Olger
 
  On 6 jan 2010, at 14:03, Emond Papegaaij wrote:
   Hi Olger,
  
   The InPrincipal annotation is something we developed as an alternative
   for the hive files (which we find difficult to maintain, not only with
   anonymous inner classes). Principals are defined by a set of classes
   with annotations defining things like implies relations between
   principals and DataPermissions. ComponentPermissions are created by
   scanning for components with the InPrincipal annotation and creating
   the permissions for those. We are thinking about releasing this code,
   perhaps by including it in wicket-security.
  
   When using a hive file, you define your principals, each with a set of
   permissions. Currently, you can use ComponentPermission, DataPermission
   and AllPermissions. My suggestion is to add another permission that
   gives permissions to a component and all of its subclasses (including
   anonymous classes), something like:
  
   permission ${ComponentSubclassPermission} MyPage, inherit, render;
  
   This would give you permission for MyPage and its subclasses. You can
   define the alias for ComponentSubclassPermission in
   SwarmPolicyFileHiveFactory. I think that this is the way Swarm/Wasp is
   'supposed to be used'.
  
   Best regards,
   Emond
  
   On Wednesday 06 January 2010 13:09:09 Olger Warnier wrote:
   Hi Emond,
  
   Thanks for your comments, Interesting matter. Extending
   ComponentPermission to change the behavior sounds like an option. I
   can't find the
   @InPrincipal annotation in the wicket-security project, is this
   something specific ?
  
   When you look at it from the 'hive' side: It is the standard way of
   working with Swarm/Wasp, isn't it ? That current way has a quite
   fragile way to define the authorization rules on anonymous inner
   classes. How to deal with that ?
  
   Is it an option to contribute your annotations with a specific
   AnnotatedPermission ? That would be really great.
  
   Kind Regards,
  
   Olger
  
   On 6 jan 2010, at 12:52, Emond Papegaaij wrote:
   Hi,
  
   Your change breaks some functionality. It is now no longer possible
   to grant permissions for anonymous inner classes at all, you are now
   forced to grant the permission on the superclass. This might seem
   sensible when using a hive file, but it is not when permissions are
   configured in other ways.
  
   We create permissions by annotating components with an @InPrincipal
   annotation. It is possible to create a (abstract) component and have
   multiple, anonymous subclasses, each with their own @InPrincipal
   annotation.
  
   I think, this should be fixed with a special ComponentPermission: one
   that does not only give permission to the specified class, but also
   to its subclasses. This could be achieved by extending
   ComponentPermission and overriding the implies method. The first part
   of the the path array should contain the classname of the component.
  
   Best regards,
   Emond Papegaaij
  
   On Thursday 31 December 2009 23:31:34 Olger Warnier wrote:
   Hi Sam,
  
   Found the way to solve it. It is fixed in the trunk. Still need to
   fix the build server - so a check out and build of the whole is
   probably best. An anonymous class will act like its' parent now.
  
   Happy new year (to you all).
  
   Olger
  
   On 31 dec 2009, at 22:43, s...@sambarrow.com wrote:
   In my opinion, that's how it should work; just seems like common
   sense to me. Even for regular (non-anonymous) classes, it would be
   useful although that's not as important.
  
   As far as the technical part I have

Re: wicket security future - contribute!

[Emond Papegaaij]

On Thursday 14 January 2010 00:12:41 Alexander Elsholz wrote:
 in my last wicket projects i used wicket-auth roles and swarm/wasp. i think
 swarm/wasp is a really good base for larger web-applications. but we all
  know about the problem with swarm/wasp. i developed a few extensions for
  swarm, but its a lot of code and so nobody starts to maintain and whats
  more important to develop. so wasp swarm stops on wicket 1.3.

Wicket-security certainly does not stop at wicket 1.3. A snapshot for wicket 
1.4 is available and working. I am thinking about moving wicket-security under 
the WicketStuff Core project, but it is also possible that wicket-security 
will get it's own release cycle.

 there was plans to integrate wicket-security in 1.5. @wicket developers: is
  this still relevant?

I don't know about these plans, but it is possible that this has been 
discussed.

 i think we will not find one person who develops wicket-security allone -
  so who's interested?
 its not the part brings the most fun in wicket development area but a very
  very important part of every enterprise application - so contribute! lets
  define a security-subteam.

Well, actually, I recently volunteered to maintain wicket-security. I must 
admit that my time is somewhat limited, but I think wicket-security is too 
important to leave it unmaintained. At Topicus, we still heavily depend on it 
for old, current and new projects. Suggestions (and patches) are always 
welcome!

My short-term plans are to release a stable wicket-1.4 version, so you no 
longer need to depend on a SNAPSHOT. This week, a new version for wicket-1.3 
(wicket-security-1.3.1) was released, incorporation many fixes made by Maurice 
just before his accident and some minor new features. Work on a wicket-1.5 
version has not yet started.

Best regards,
Emond Papegaaij

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

PageLink deprecated

[Emond Papegaaij]

Hi,

We just found that PageLink has been deprecated in wicket 1.4. Can someone 
explain why? I see no reason why PageLink should not be used. PageLink is the 
base for SecurePageLink (in wicket-security), which uses getPageIdentity for 
its security check. Using Link is not an option because it does not provide 
the page identity, and using BookmarkablePageLink is not an option because in 
many cases the target page is not bookmarkable.

Can PageLink please be restored?

Best regards,
Emond Papegaaij

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

Re: PageLink deprecated

[Emond Papegaaij]

The javadoc says I should use Link or BookmarkablePageLink, which, as I 
explained, are both not an option.

Emond

On Friday 15 January 2010 05:08:42 Igor Vaynberg wrote:
 what does the javadoc say?
 
 -igor
 
 On Thu, Jan 14, 2010 at 6:12 AM, Emond Papegaaij
 
 emond.papega...@topicus.nl wrote:
  Hi,
 
  We just found that PageLink has been deprecated in wicket 1.4. Can
  someone explain why? I see no reason why PageLink should not be used.
  PageLink is the base for SecurePageLink (in wicket-security), which uses
  getPageIdentity for its security check. Using Link is not an option
  because it does not provide the page identity, and using
  BookmarkablePageLink is not an option because in many cases the target
  page is not bookmarkable.
 
  Can PageLink please be restored?
 
  Best regards,
  Emond Papegaaij
 
  -
  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
 

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

Re: PageLink deprecated

[Emond Papegaaij]

I totally agree with Jeroen. The 3rd constructor is dangerous and should be 
removed. The other two, however, are lazy and create the page in the onClick 
(provided that the IPageLink interface is implemented correctly). Of course, 
it is possible to copy PageLink and IPageLink to wicket-security, but that 
would be a large API-incompatible change, for which I see no compelling 
reason.

Emond

On Monday 18 January 2010 08:44:28 Jeroen Steenbeeke wrote:
 Guys, no need to keep explaining what's wrong with passing a Page in
 the constructor, we understand that!
 
 Forget about that filthy 3rd constructor, I know it's wrong and I
 never used it anyway. That wasn't what my question was about.
 
 There are two more constructors:
 
 PageLink(String, Class)
 PageLink(String, IPageLink)
 
 Both of these do not replicate the dangerous behavior illustrated in
 this thread so far. I understand that we can easily create our own
 implementation that simulates the behavior we want. I just wanted to
 understand the reasoning for removing the whole class when only one of
 the constructors is dangerous. From what Martijn Dashorst just told
 me, it was a case of seeing as we already have Link and
 BookmarkablePageLink, we figured you could just use those instead.
 
 This is also the source of miscommunication so far. The Javadoc simply
 states what you should use instead, but does not explicitly state why.
 The assumption is that any behavior you can achieve with the
 PageLink/IPageLink combination can also be done with a simple Link.
 This does not take into account the use of the Page Identity for
 security checks however (mainly for determining link visibility,
 which, frankly, does not need an actual instance of the page in
 question), which brings us back to Emond's original point.
 
 On the other hand, one could argue that the only use for the page
 identity is for security purposes, and it would therefore be more at
 home in a specialized class in wicket-security.
 

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

Re: PageLink deprecated

[Emond Papegaaij]

That's what I'm trying to say: it can't be accomplished by either  
BookmarkablePageLink or Link. Link does not have a getPageIdentity method and 
BookmarkablePageLink only works for bookmarkable links (duh). So Link is never 
an option because of the missing getPageIdentity method and 
BookmarkablePageLink only works for bookmarkable pages. What about links to 
pages that are not bookmarkable?

Emond

On Monday 18 January 2010 17:12:49 Igor Vaynberg wrote:
 well, if the functionality can be accomplished using either
 BookmarkablePageLink or Link, why do we need yet another way to do it?
 
 -igor
 
 On Sun, Jan 17, 2010 at 11:44 PM, Jeroen Steenbeeke
 
 j.steenbeeke...@gmail.com wrote:
  Guys, no need to keep explaining what's wrong with passing a Page in
  the constructor, we understand that!
 
  Forget about that filthy 3rd constructor, I know it's wrong and I
  never used it anyway. That wasn't what my question was about.
 
  There are two more constructors:
 
  PageLink(String, Class)
  PageLink(String, IPageLink)
 
  Both of these do not replicate the dangerous behavior illustrated in
  this thread so far. I understand that we can easily create our own
  implementation that simulates the behavior we want. I just wanted to
  understand the reasoning for removing the whole class when only one of
  the constructors is dangerous. From what Martijn Dashorst just told
  me, it was a case of seeing as we already have Link and
  BookmarkablePageLink, we figured you could just use those instead.
 
  This is also the source of miscommunication so far. The Javadoc simply
  states what you should use instead, but does not explicitly state why.
  The assumption is that any behavior you can achieve with the
  PageLink/IPageLink combination can also be done with a simple Link.
  This does not take into account the use of the Page Identity for
  security checks however (mainly for determining link visibility,
  which, frankly, does not need an actual instance of the page in
  question), which brings us back to Emond's original point.
 
  On the other hand, one could argue that the only use for the page
  identity is for security purposes, and it would therefore be more at
  home in a specialized class in wicket-security.
 
  --
  Jeroen Steenbeeke
  www.fortuityframework.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
 

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

Re: PageLink deprecated

[Emond Papegaaij]

But leaving IPageLink without any classes using it seems a bit weird to me. I 
think IPageLink should be removed with PageLink and probably be moved to 
wicket-security.

On Tuesday 19 January 2010 11:36:59 Jeroen Steenbeeke wrote:
 Which is what I suggested earlier in this discussion as well. So long
 as nobody touches the IPageLink interface then simply adapting
 SecurePageLink to use IPageLink directly would work without any
 significant break in SecurePageLink's API. That way there are no icky
 constructors and no unnecessary link classes.

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

[release] Wicket Security 1.4-beta1

[Emond Papegaaij]

Wicket Security 1.4-beta1 has just been released.

This release contains all updates made by Olger Warnier in the last 6 months 
to make Wicket Security work with Wicket 1.4 and the examples he added. It 
also contains the new ComponentSubclassPermission, which makes it possible to 
authorize a class and all its subclasses. But most importantly: it is the 
first release for Wicket Security 1.4!

To include Wicket Security (with Swarm) in your project, add:

dependency
groupIdorg.apache.wicket.wicket-security/groupId
artifactIdswarm/artifactId
version1.4-beta1/version
/dependency

More information about Wicket Security can be found at:
http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security

Although this release works with Wicket 1.4, it does not yet make use of the 
generics provided in Wicket 1.4. This will be included in the next release 
(beta2), which will follow shortly.

Best regards,

Martijn and Emond

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

Re: Adding components to Pages based on conditionals

[Emond Papegaaij]

Personally, I think, it is much more elegant to call setVisible on the 
component you want to display or hide, or, when the outcome of the condition 
can change on each render, override isVisible to return the outcome of the 
condition.

Emond Papegaaij

On Friday 17 April 2009 08:50:21 Vladimir K wrote:
 Try EmptyPanel component which is shipped with Wicket.

 if (condition)
   add(new YourVisibleComponent(componentId));
 else
   add(new EmptyPanel(componentId));

 Do not forget about OOD. You can introduce createYourVisibleComponent()
 method which creates empty panel in base class and some certain component
 in derived classes.

 subbu_tce wrote:
  Hi,
  I am a new wicket user.
  How do we include / exclude content or components in pages based on
  conditions.
  What is the equivalent in Wicket to the if tag in the JSTL tag library?
 
  The reason i ask this question is because irrespective of whether i add
  the
  component in the page, i need to have the markup for the component in the
  HTML.
 
  Thanks in advance for the answers.
 
  Thanks,
  Subbu.


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

Re: debug mode

[Emond Papegaaij]

I've had similar problems when using method breakpoints on inner classes. 
Removing the breakpoint speeds up the entire application dramatically (the 
breakpoint also doesn't work). So try removing your breakpoints.

Emond

On Tuesday 14 July 2009 19:15:02 John Ipson wrote:
 Has anyone ever run across extremely slow debug mode in wicket/eclipse
 integration?

 Eclipse 3.4
 Wicket 1.4

 When choosing Run as..., the application is very fast.
 When choosing Debug as...  the application is 20 times slower.

 I watch each jar get loaded into the application at a very slow rate.

 I've run the application in Jetty and JBoss, so I believe it is a wicket
 thing.  I wonder if there is a setting in wicket.

 Thanks,
 John


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

Re: Future of Wicket Security (WASP/SWARM)

[Emond Papegaaij]

I do think this is a good idea, however it will be difficult to implement. 
WASP/SWARM already provides this setup. WASP defines the interface, where 
SWARM is the implementation of that interface. I do not know about Shiro, but 
I don't think it is implemented on top of WASP. So should SWARM be build on 
top of the abstractions provided by Shiro (does it even have those 
abstractions?) or should Shiro be build on top of WASP? Either way will 
require a lot of work.

I don't know who is the maintainer of Shiro, but I don't mind changing WASP to 
allow Shiro to be build on top of it, or the other way around (building SWARM 
on top of Shiro). Perhaps this core security framework can then be integrated 
into the wicket core. However, I doubt if such a thing can be accomplished for 
wicket 1.5 (or at all).

Best regards,
Emond Papegaaij

On Monday 25 January 2010 11:11:31 nino martinez wael wrote:
 No one has a feeling about making a super/parent security framework for
 wicket and then let providers implement their solution.. Like JPA ? It
  would mean that it would be the same using Shiro or Swarm / Wasp etc.. You
  just switch provider?
 
 2010/1/22 nino martinez wael nino.martinez.w...@gmail.com
 
  I am in doubt. What I think would be best are creating a parent framework
  like wicket ioc. And then the different security providers could use
  that.. Does it seem reasonable?
 
  That would mean keeping Wicket security at stuff, but probably extracting
  interfaces? And maybe adopting a few committers from wicket shiro /
  wicket security and if there are other integrations to a sub project at
  Apache Wicket, to make it less of a burden as Igor writes.
 
 
 
  [ ] adopt Wicket security into Apache Wicket
  [X ] keep Wicket security at Wicket Stuff
 
  2010/1/22 Martijn Dashorst martijn.dasho...@gmail.com
 
  Guys,
 
  I'd like to discuss the future of the Wicket Security project.
  Currently the project lives on/in the wicketstuff repository, but uses
  group id and package names org.apache.wicket. IMO We should either:
 
   - adopt Wicket Security into the Wicket project and move everything
  over from Wicket Stuff into a subproject within Apache Wicket (and
  adopt the committers), or
   - keep Wicket Security at wicketstuff and move it into the fold of
  wicket stuff, including groupid/package rename.
 
  Since development on wicket security 1.4 is currently happening with a
  1.4-beta1 just released, it is prudent to decide its future now (with
  a pending package rename).
 
  Considering that both the wicket security contributors and the Wicket
  PMC members are needed to make this happen, all their opinions are
  considered binding.
 
  [ ] adopt Wicket security into Apache Wicket
  [ ] keep Wicket security at Wicket Stuff
 
  Martijn
 
  -
  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: Future of Wicket Security (WASP/SWARM)

[Emond Papegaaij]

On Monday 25 January 2010 13:02:05 James Carman wrote:
 On Mon, Jan 25, 2010 at 6:11 AM, Emond Papegaaij
 
 emond.papega...@topicus.nl wrote:
  I do think this is a good idea, however it will be difficult to
  implement. WASP/SWARM already provides this setup. WASP defines the
  interface, where SWARM is the implementation of that interface. I do not
  know about Shiro, but I don't think it is implemented on top of WASP. So
  should SWARM be build on top of the abstractions provided by Shiro (does
  it even have those abstractions?) or should Shiro be build on top of
  WASP? Either way will require a lot of work.
 
 Shiro shouldn't have to know anything about WASP.  What should happen
 is Wicket-Security (or whatever we're going to call it) would declare
 a SPI interface that could be implemented to adapt any security
 framework (spring-security, shiro, etc.) to the Wicket-Security API.
 The security frameworks themselves wouldn't necessarily (most likely
 they would not) implement the interface; there would be an integration
 library (e.g. wicket-security-shiro) that bridges the gap.

That sounds a bit overkill to me. I don't think anyone will ever want to use 
SWARM in a non-Wicket application. Naturally, this is a bit different for 
Shiro and spring-security, because these are existing projects (if I'm not 
mistaken), which can also be used without Wicket.

WASP (Wicket Abstract Security Platform) is what could serve as a basis for 
what you call 'the Wicket-Security API'. It will require some work to make it 
more generic and less 'SWARM'-like, but I think the concept is quite good. 
This can then serve as a basis to build security providers, such as wicket-
security-shiro, wicket-security-spring and SWARM.

Emond Papegaaij

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

Re: Future of Wicket Security (WASP/SWARM)

[Emond Papegaaij]

On Monday 25 January 2010 14:31:47 James Carman wrote:
 On Mon, Jan 25, 2010 at 8:07 AM, Emond Papegaaij
 
 emond.papega...@topicus.nl wrote:
  That sounds a bit overkill to me. I don't think anyone will ever want to
  use SWARM in a non-Wicket application. Naturally, this is a bit different
  for Shiro and spring-security, because these are existing projects (if
  I'm not mistaken), which can also be used without Wicket.
 
 Overkill?  It's not overkill to provide a framework where you can plug
 in providers.  I didn't say that SWARM should be used outside of
 Wicket (I personally wouldn't use it anywhere because I think it's too
 complicated).  What I was saying was that any security framework for
 Wicket should allow you to bring your own security provider (shiro,
 spring-security, etc).  That's exactly what the wicket-security code
 provides right now with the AuthenticatedWebApplication,
 AuthenticatedWebSession, etc.

I didn't mean that providing a general framework for security providers is 
overkill, just that modifying SWARM to be usable outside a Wicket-environment 
is overkill. There is no need to split SWARM into a general security framework 
and a Wicket integration part.

The current wicket-security code is somewhat limited in what you can do with 
it. WASP provides a much richer (probably too rich) interface for security. I 
see WASP as a viable basis for the wicket-security API where providers can 
plug in to. One of these providers will be SWARM, but also wicket-security-
shiro and wicket-security-spring. Maybe even auth-roles.

However WASP in its current state is a too bloated for this. It will require a 
major cleanup. On the other hand, the current wicket-security API is too 
limited for a real security framework to plug in to. For this to work, we need 
to find the fine line that provides a clean, but complete API.

Emond Papegaaij

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

Re: Future of Wicket Security (WASP/SWARM)

[Emond Papegaaij]

On Monday 25 January 2010 15:22:42 James Carman wrote:
 On Mon, Jan 25, 2010 at 9:11 AM, Emond Papegaaij
  The current wicket-security code is somewhat limited in what you can do
  with it. WASP provides a much richer (probably too rich) interface for
  security. I see WASP as a viable basis for the wicket-security API where
  providers can plug in to. One of these providers will be SWARM, but also
  wicket-security- shiro and wicket-security-spring. Maybe even auth-roles.
 
 Agreed it's limited, so we should definitely make the API rich enough
 so that you can do very fine-grained authorization control or more
 coarse-grained.  Some projects (like ours) will be okay with just
 saying this page has to have this role.

I think a good security framework needs to provide an API that allows, but not 
require, fine-grained control.

  However WASP in its current state is a too bloated for this. It will
  require a major cleanup. On the other hand, the current wicket-security
  API is too limited for a real security framework to plug in to. For this
  to work, we need to find the fine line that provides a clean, but
  complete API.
 
 Agreed.  When I look at the documentation for SWARM/WASP, I cringe.
 I, being one of the (now defunct) Apache HiveMind committers, also
 take offense to the name of the HiveMind class. :)  Actually, I really
 don't like the cutesy names in the API at all.  The names don't make
 any sense?  Why is a hive called a hive for instance?  Why is the
 HiveMind class called HiveMind.  Just looking at it, it's really not
 intuitive.  There also seems to be a lot of configuration required to
 get things off the ground properly.

Most of the complicated stuff is from SWARM, which indeed requires a lot of 
configuration. The difference between WASP and SWARM is not quite clear from 
the documentation, nor is the separation of the two. Some of the naming could 
use some improvement indeed :). The HiveMind manages the Hives used in the VM. 
A Hive contains all principals and permissions of an application and 
ultimately determines if a permission is granted or not. However, the Hive 
(and mind) are part of SWARM and should not be part of a general API.

The main elements of WASP are:
 - A set of secure components
 - Several security checks
 - The ActionFactory, with a set of default actions
 - The WaspAuthorizationStrategy, which implements IAuthorizationStrategy

With this, WASP only provides an interface to make you Wicket application 
secure. It has no implementation what-so-ever on how to check the security. 
Therefore, I think it is a good starting point for creating a general security 
API for Wicket.

Emond

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

Re: Future of Wicket Security (WASP/SWARM)

[Emond Papegaaij]

On Monday 25 January 2010 15:59:53 James Carman wrote:
 On Mon, Jan 25, 2010 at 9:50 AM, Emond Papegaaij
  Most of the complicated stuff is from SWARM, which indeed requires a lot
  of configuration. The difference between WASP and SWARM is not quite
  clear from the documentation, nor is the separation of the two. Some of
  the naming could use some improvement indeed :). The HiveMind manages the
  Hives used in the VM. A Hive contains all principals and permissions of
  an application and ultimately determines if a permission is granted or
  not. However, the Hive (and mind) are part of SWARM and should not be
  part of a general API.
 
  The main elements of WASP are:
   - A set of secure components
   - Several security checks
   - The ActionFactory, with a set of default actions
   - The WaspAuthorizationStrategy, which implements IAuthorizationStrategy
 
  With this, WASP only provides an interface to make you Wicket application
  secure. It has no implementation what-so-ever on how to check the
  security. Therefore, I think it is a good starting point for creating a
  general security API for Wicket.
 
 So, what does WASP add to wicket-auth-roles that it doesn't have
 already?  Is it generic enough that we should just put it into
 wicket-auth-roles (or a new wicket-security module)?  I really don't
 like the name WASP.  I think wicket-security is intuitive enough (and
 follows the other names already out there wicket-ioc, wicket-spring,
 etc.).  I really don't like the fact that when folks ask questions
 about wicket-auth-roles, the usual answer is wicket-auth-roles is
 only a demonstration or something to that effect.  There really
 should be a sanctioned/preferred (and pluggable) security framework
 for Wicket that we can all get behind.

I think WASP is a good name for what it is now: a separate project. A general 
security framework for wicket should be named wicket-security.

WASP makes it possible to authorize single components, models of components 
and classes. This authorization can be performed on multiple levels, not just 
RENDER and ENABLE. It also provides the ISecurityCheck interface, which can be 
used to create reusable security checks. Some default implementations are 
already provided. The secure components are components that are used often, 
such as a SecurePageLink that is only visible when the target is authorized.

I don't think WASP (or wicket-security) should be integrated into wicket-auth-
roles, but auth-roles should be one of the security providers available for 
Wicket. My vision is that WASP replaces the interfaces in Wicket itself (such 
as IAuthorizationStrategy) and become part of the core of Wicket. Other 
frameworks can then build on this interface. However, as I said before, 
currently WASP is too bloated to be considered as a 'general security API'.

Emond

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

Re: [release] Wicket Security 1.4-beta1

[Emond Papegaaij]

I've just checked in a major commit on wicket-security-1.4, adding generics, 
cleaning up the API where needed and introducing a project wide source code 
formatting. This commit has changed the API of wicket-security in some places. 
If it breaks for you, please let me know, so I can fix it or provide a 
solution in another way.

If you do not want to test this commit, you can always stick to beta1, 
released last week.

Best regards,
Emond Papegaaij

On Thursday 21 January 2010 10:48:36 Emond Papegaaij wrote:
 Wicket Security 1.4-beta1 has just been released.
 
 This release contains all updates made by Olger Warnier in the last 6
  months to make Wicket Security work with Wicket 1.4 and the examples he
  added. It also contains the new ComponentSubclassPermission, which makes
  it possible to authorize a class and all its subclasses. But most
  importantly: it is the first release for Wicket Security 1.4!
 
 To include Wicket Security (with Swarm) in your project, add:
 
 dependency
 groupIdorg.apache.wicket.wicket-security/groupId
 artifactIdswarm/artifactId
 version1.4-beta1/version
 /dependency
 
 More information about Wicket Security can be found at:
 http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security
 
 Although this release works with Wicket 1.4, it does not yet make use of
  the generics provided in Wicket 1.4. This will be included in the next
  release (beta2), which will follow shortly.
 
 Best regards,
 
 Martijn and Emond
 
 -
 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

wicketpath is not valid html

[Emond Papegaaij]

Hi,

For our project, we use the Wicket Stuff HTML Validator 
(http://github.com/dashorst/wicket-stuff-markup-validator), which informs us 
of invalid HTML upfront. However, with the switch from wicket 1.3 to 1.4, this 
validator is giving many errors on the wicketpath attribute. 

This attributed used to be named wicket:path, and was renamed to wicketpath as 
part of WICKET-1877, because selenium is having trouble using wicket:path. It 
was opted to make the name configurable, but decided that 'we don't need yet 
another configuration option'. Could this please be reconsidered? I like to 
keep the wicket:path attributes in the generated markup, because they can be 
very handy for debugging, but I have to disable them to keep the HTML 
validator happy.

Best regards,
Emond Papegaaij

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

{Spam?} Re: wicketpath is not valid html

[Emond Papegaaij]

Our validator is always on in development mode, so that would require 
completely turning off the attribute (which is what I did now), but the 
attribute can be very useful for debugging, so I'm loosing that functionality 
right now. Can't it be a tri-state configuration option 
(ON/SELENIUM_COMPATIBLE/OFF)? Perhaps this can be implemented in wicket 1.5?

On Tuesday 27 April 2010 18:05:48 Igor Vaynberg wrote:
 turn off the attribute before you run your validator.
 
 -igor
 
 On Tue, Apr 27, 2010 at 12:11 AM, Emond Papegaaij
 
 emond.papega...@topicus.nl wrote:
  Hi,
  
  For our project, we use the Wicket Stuff HTML Validator
  (http://github.com/dashorst/wicket-stuff-markup-validator), which informs
  us of invalid HTML upfront. However, with the switch from wicket 1.3 to
  1.4, this validator is giving many errors on the wicketpath attribute.
  
  This attributed used to be named wicket:path, and was renamed to
  wicketpath as part of WICKET-1877, because selenium is having trouble
  using wicket:path. It was opted to make the name configurable, but
  decided that 'we don't need yet another configuration option'. Could
  this please be reconsidered? I like to keep the wicket:path attributes
  in the generated markup, because they can be very handy for debugging,
  but I have to disable them to keep the HTML validator happy.
  
  Best regards,
  Emond Papegaaij
  
  -
  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

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

{Spam?} Re: wicketpath is not valid html

[Emond Papegaaij]

I don't like changing the DTD, but I could always add it as a known wicket bug 
to HtmlValidationResponseFilter.

Emond

On Wednesday 28 April 2010 02:12:06 b...@actrix.gen.nz wrote:
 Hi,
 
 You can extend the DTD of the validator to accept the attribute.
 
 !ATTLIST yourtag
   wicketpath  CDATA  #IMPLIED
 
 
 
 Bernard
 
 On Tue, 27 Apr 2010 09:11:37 +0200, you wrote:
 Hi,
 
 For our project, we use the Wicket Stuff HTML Validator
 (http://github.com/dashorst/wicket-stuff-markup-validator), which informs
 us of invalid HTML upfront. However, with the switch from wicket 1.3 to
 1.4, this validator is giving many errors on the wicketpath attribute.
 
 This attributed used to be named wicket:path, and was renamed to
 wicketpath as part of WICKET-1877, because selenium is having trouble
 using wicket:path. It was opted to make the name configurable, but
 decided that 'we don't need yet another configuration option'. Could this
 please be reconsidered? I like to keep the wicket:path attributes in the
 generated markup, because they can be very handy for debugging, but I
 have to disable them to keep the HTML validator happy.
 
 Best regards,
 Emond Papegaaij
 
 -
 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

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

Re: [PROPOSAL] Application.runAs() Method...

[Emond Papegaaij]

In our application we use quartz for long running jobs. These threads have 
access to the application context, which contains the wicket application. In 
the execute method, we locate the application and use Application.set and 
Application.unset to set and remove the application. This is, however, not a 
'public API' and could easily be replaced by wrapping the main body in a 
Runnable and calling Application.wrap. I'm in favor of this wrap method. It 
allows you to set the application on a thread, without having to use non-
public API, and without the try/finally hassle.

I do not care how this method is implemented (that's the beauty of a good API, 
isn't it?). It could store the application in the runnable, or look it up in a 
map, as long as it works reliably, I'm fine with it :)

Emond

On Wednesday 26 May 2010 23:47:43 James Carman wrote:
 Well, this doesn't start any threads or anything.  So, it wouldn't
 immediately allow folks to start up threads.  All this would do is
 create an object that *can* be run in another thread, but have access
 to this Application in it.  Also, this is just a proposal.  I'm just
 wanting folks to give feedback about the idea.  I think this is the
 most flexible way to solve the problem we're seeing folks have.
 
 On Wed, May 26, 2010 at 4:28 PM, Joe Fawzy joewic...@gmail.com wrote:
  Hi
  Please make this configurable(can be disabled) as i am on appengine, they
  does not allow threads
  thanks
  Joe
  
  On Tue, May 25, 2010 at 4:34 PM, James Carman 
ja...@carmanconsulting.comwrote:
  Sorry, subject should be wrap() method, not runAs().
  
  On Tue, May 25, 2010 at 9:33 AM, James Carman
  
  ja...@carmanconsulting.com wrote:
   I've been thinking about this whole idea of needing to access the
   application object in different threads idea.  What if the Application
   class had a method like this:
   
   public Runnable wrap(Runnable task)
   
   Basically, the Application would create a Runnable object that can be
   run within the context of itself (by setting/clearing the ThreadLocal
   variable).  Then, you can use that Runnable anywhere to run a task
   with all of the appropriate Wickety goodness set up for you (except
   for the request cycle of course because you're not executing within a
   request cycle).  Now, what the Application stores in the Runnable
   doesn't have to be the Application itself.  We can set up a static
   MapString,WeakReferenceApplication object on the Application class
   and when an Application is constructed, it registers itself (the key
   could be a UUID.randomUUID().toString()).  Then, we could have a
   method like
   
   public static Application get(String id);
   
   on the Application class to get back the original Application object.
  
  -
  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

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

Re: [PROPOSAL] Application.runAs() Method...

[Emond Papegaaij]

On Thursday 27 May 2010 12:41:10 James Carman wrote:
 On Thu, May 27, 2010 at 2:34 AM, Emond Papegaaij
 
 emond.papega...@topicus.nl wrote:
  In our application we use quartz for long running jobs. These threads
  have access to the application context, which contains the wicket
  application. In the execute method, we locate the application and use
  Application.set and Application.unset to set and remove the application.
  This is, however, not a 'public API' and could easily be replaced by
  wrapping the main body in a Runnable and calling Application.wrap. I'm
  in favor of this wrap method. It allows you to set the application on a
  thread, without having to use non- public API, and without the
  try/finally hassle.
 
 What happens if you have multiple applications running in the same webapp?

Well, the answer is pretty simple: we only have one application per webapp. :)

If we wanted to supported multiple applications, we probably would pass the 
application in some way to the jobs (we already pass other information, such 
as the user starting the job).

  I do not care how this method is implemented (that's the beauty of a good
  API, isn't it?). It could store the application in the runnable, or look
  it up in a map, as long as it works reliably, I'm fine with it :)
 
 Right, we can figure out how to implement it later, but I think making
 this method available would be a huge step in the right direction.
 

Agreed.

Emond

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

Re: Status of wicket-security

[Emond Papegaaij]

And that conversion is now completed. We are at wicket 1.4(.9) and everything 
seems to be fine. I think we can release wicket-security-1.4.0 today. If we 
don't get to it, expect the release next week. We will post an announcement on 
this list. Until then, you can use 1.4-rc1. Nothing has changed since then, 
because no bugs were found.

Emond Papegaaij

On Friday 28 May 2010 01:38:54 Jeremy Thomerson wrote:
 See the second message at this link (the one from Martijn):
 http://apache-wicket.1842946.n4.nabble.com/Wicket-1-4-upgrade-dependent-on-
 Wicket-Security-1-4-td2031552.html
 
 Jeremy
 
 On Thu, May 27, 2010 at 6:30 PM, Marek Šabo ms...@buk.cvut.cz wrote:
  Hi,
  
  I would like to know what's the status of wicket-security. I've been
  using it for couple of months but only for simple tasks. I would like to
  dig deeper but there is like on getting started and few mailing list
  entries.
  Is there someone who works on the project or is it fading? If so, what
  is the common choice for AA layer in wicket apps besides Spring Security?
  
  Regards,
  
  --
  Marek Šabo
  
  
  -
  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: [PROPOSAL] Application.runAs() Method...

[Emond Papegaaij]

On Friday 28 May 2010 15:33:16 Sven Meier wrote:
 OK, no ITL, got it.
 
 Then, you can use that Runnable anywhere to run a task
 with all of the appropriate Wickety goodness set up for you (except
 for the request cycle of course because you're not executing within a
 request cycle).
 
 But what are the use cases for *this* proposal (beside mail generation)?

In our jobs, we sometimes need access to the security layer of the application 
via wicket-security to authenticate actions performed by the job. This only 
works when Application.get() returns the application.

Emond

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

Re: wicket clustering wicket-security

[Emond Papegaaij]

On Wednesday 02 June 2010 15:54:50 david_ wrote:
 Maybe someone knows who I can contact about this?
 I wicket-security developer maybe?

Unfortunately we don't use multiple applications in the same servlet 
container. So, I can't really help you with this. Maurice probably would have 
known how to do it, but unfortunately we can't ask him anymore. I'm almost 
sure that it should be possible (wicket-security even supports multiple logins 
on the same application). Perhaps some of the old documentation at 
http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security can help 
you, or perhaps the examples?

What I do see in WaspSession is this:
if (securityStrategy.isUserAuthenticated())
dirty();
else
invalidateNow();

I don't know what that is supposed to do, but it seems you are hitting the 
wrong branch of the if statement.

Good luck with it,
Emond

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

Re: [announce] Wicket Security 1.4 released!

[Emond Papegaaij]

On Wednesday 09 June 2010 21:30:39 ViShap wrote:
 I just stumbled upon this announce and didn't have the time to dig deep
 into the code, and the links you suggested don't mention anything, so i
 have a short question:
 
 Is it possible to use annotations instead of that manual hive-file?
 
 If not:  Is it planned or if not, why is it discarded?

With wicket-security 1.4, this is not possible. We (at Topicus) developed a 
set of annotations to replace the hive file, but at this moment it is not 
clear if (or what part) of that set of annotations can be moved to wicket-
security and when I will have the time to do it. This will not be part of 1.4, 
but perhaps 1.5.

Best regards,
Emond

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

Re: Wicket pages are invalid XHTML

[Emond Papegaaij]

Hi Ichiro,

If you want to enforce valid XHTML, take a look at the WicketStuff HTML 
Validator: http://github.com/dashorst/wicket-stuff-markup-validator

It automatically validates all pages served by the application and shows an 
error report for invalid markup.

Best regards,
Emond Papegaaij

On Thursday 16 September 2010 03:50:35 Ichiro Furusato wrote:
 Hi Jeremy,
 
 Thanks for the quick reply. Is the reason I'm seeing the wicket:id
 in my output then that I'm working in development mode? If so,
 I'd say that was a nice design decision (not surprising from what
 else I've seen in Wicket).
 
 Cheers,
 
 Ichiro
 
 On 9/16/10, Jeremy Thomerson jer...@wickettraining.com wrote:
  On Wed, Sep 15, 2010 at 8:11 PM, Ichiro Furusato
  
  ichiro.furus...@gmail.comwrote:
  Hi,
  
  I'm a new Wicket user and am unclear about a couple of things regarding
  what type of markup Wicket delivers to clients. Because some of the
  clients
  I work with have government guidelines restricting what document types
  are permitted (typically XHTML 1.0 Strict or Transitional), I'm
  concerned I might not be able to use Wicket for those projects.
  
  What I'll call the Wicket XHTML DTD is referenced as the XML namespace
  URI for wicket documents. As (from what I've seen) there is no stated
  DOCTYPE declaration, Wicket pages are expressed as well-formed XML only,
  even though they could likely validate according to the Wicket XHTML
  DTD. Unfortunately, for my applications I have a requirement to declare
  and be valid according to a W3C XHTML 1.0 DTD.
  
  It would seem from the unmodified comments found at the top of the
  Wicket
  
  XHTML DTD that the schema used at first glance is XHTML 1.0 Strict, e.g.:
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
  PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
  SYSTEM http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
  
  but on further investigation there have been modifications to the
  schema: the addition of some wicket: prefixed attributes to
  %coreattrs;.
  
  It's not industry practice to do that kind of thing, i.e., the header
  comments should identify the schema being expressed. If a DTD is
  modified the comments should be modified to relabel the schema. Any
  reference to the FPI (formal public identifier) for XHTML 1.0 would
  likewise be inappropriate since the Wicket schema has modified it. Even
  if the changes occur in a new XML namespace the schema is no longer
  XHTML 1.0 Strict and will not validate according to that DTD.
  
  There are a few questions/comments that come from the above:
1. Are the wicket attributes required for Wicket-based processing?

   Would removing them break existing functionality?

2. If the answer to #1 is no, could the web pages be run through a

   simple XSLT transform to remove the non-XHTML attributes?

3. If the answer to #2 is yes, I'm willing to supply the XSLT

   stylesheet, but I'm not on the developer team and couldn't based
   on my current workload volunteer, so I wouldn't be able to supply
   the code supporting that feature.

4. I am familiar with the XHTML modular DTDs and would be willing to

   supply an XHTML 1.0 DTD based on a new Wicket module, then
   flattened (converted into one file) based on some tools I've
  
  written.
  
   This would be a replacement for the existing Wicket XHTML DTD and
   be appropriately named, e.g.,
   
 -//Apache.org//DTD XHTML 1.0 Strict for Wicket 1.4//EN
   
   This DTD could of course be used to validate Wicket-produced web
   pages, but wouldn't be needed if the wicket: attributes were
   stripped from generated web pages. Ideally, Wicket would produce
   valid XHTML 1.0 Strict. I don't know if this is possible.
  
  Some clarification on this would be most appreciated,
  
  Thanks,
  
  Ichiro
  
  PS. on the whole I'm liking what I see with Wicket, esp. compared to
  Spring's increasingly complex, arcane and fragile approach to what
  should not be rocket science.
  
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
  
  Wicket only generates whatever HTML you want it to generate.  The only
  wicket tag (or actually, attribute) you are required to use is
  wicket:id, which will automatically be removed from your HTML in
  deployment mode.  So, use strict XHTML in your *.html files and strict
  XHTML is what will be rendered.
  
  --
  Jeremy Thomerson
  http://www.wickettraining.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

Re: Announcing the Topicus Dashboard

[Emond Papegaaij]

For people who want to try the dashboard, it depends on a patched version of 
WiQuery, which fixes several problems found in the official 1.1 release. You 
can find this version of WiQuery at https://github.com/papegaaij/wiquery .

It requires a very recent, webkit-based browser to run. We recommend Safari 
(best with webkit-nightly) or a Chromium daily build. Plain Safari works quite 
well, but with some minor issues. Google Chrome is able to display the page, 
but most of the effects do not work well.

Emond Papegaaij

On Thursday 25 November 2010 01:28:08 Martijn Dashorst wrote:
 The Topicus Dashboard is an information radiator showing build status,
 production server status, twitter timeline, train departure times,
 important events and much more.
 
 The Atlassian folks are running a competition for the Ultimate
 Wallboard and we (Topicus)  just submitted our entry for the
 competition: the Topicus Dashboard.
 
 If you like our dashboard, you are welcome to vote for it and help us
 win the 55 flatscreen display in the Atlassian (known for JIRA and
 Confluence) Ultimate Wallboard Competition:
 
 http://ultimatewallboard.com/entries/91860
 
 The entry sports a movie (the guy in the picture is Emond, a co-worker
 at Topicus)
 
 As we like to share our innovations we hosted our dashboard on github,
 and you are free to run the software and modify it for your own use
 (or your customers). The software is currently licensed using the GPL
 3.
 
 The project can be found here: https://github.com/dashorst/dashboard
 
 Most of the credits for this project go to Emond Papegaaij (and if you
 find a bug, call him, not me :)
 
 On behalf of the dashboard developers,
 
 Martijn Dashorst
 
 PS. Really: please vote and let us win the big screen TV!

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

Re: Firing JavaScript handler on AJAX panel swap

[Emond Papegaaij]

Hi Alec,

If you use WiQuery for your javascript-enabled panels, this is done 
automatically. WiQuery will add the javascript calls in the right places for 
you.

Best regards,
Emond

On Saturday 24 September 2011 19:58:05 Alec Swan wrote:
 Hello,
 
 We use panel swapping to implement tabbing. The code contributes
 javascript the head when the panels are swapped using AJAX. Some of
 our JS scripts register $(document).ready() handlers. However, these
 handler never fire during panel swap.
 
 How can we register our JS handlers so that they fire on AJAX-based panel
 swap?
 
 Thanks,
 
 Alec
 
 -
 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: Any info on wasp-swarm?

[Emond Papegaaij]

Hi Dan,

As Martin stated, wicket-security (wasp-swarm) is now part of wicketstuff-core 
and as such is released for every wicket release. It is maintained and it will 
continue to work, as all our major applications are built on top of it.

Best regards,
Emond Papegaaij

On Friday 09 December 2011 08:52:40 Martin Grigorov wrote:
 On Fri, Dec 9, 2011 at 5:46 AM, Dan Alvizu dalv...@pingidentity.com wrote:
  Hi,
  
  I'm trying to solve an authorization problem in wicket 1.5 -- I do not
  want users to have access to certain pages based on the roles that they
  have. I think wasp-swarm may be what I need, but is it being maintained
  anymore? I can't find anything current on the web since the 1.4.1
  announcement.
  
  The link on the wiki leads nowhere as well:
  
  https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/wicket-se
  curity-parent
 https://github.com/wicketstuff/core/tree/core-1.5.x/jdk-1.5-parent/wicket-se
 curity-parent
 
 You ask for 1.5.x branch ...
 
 Master branch now is against Wicket trunk (i.e. 6.0)
 
  (linked from)
  https://cwiki.apache.org/WICKET/wasp-swarm-security.html
  
  So I guess my question is three part -- is wasp-swarm what I'm looking
  for? Is it usable for wicket 1.5 or only wicket 1.4? And where the heck
  did it go? ;)
  
  Thanks,
  
  -Dan

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

Re: Shrinking the session size, simply by zipping it. Saved my day.

[Emond Papegaaij]

Thanks for the suggestion! I've just implemented this. It should be available 
in 1.5.5 and 6.0.0, see https://issues.apache.org/jira/browse/WICKET-4419 for 
details.

Best regards,
Emond

On Monday 20 February 2012 10:48:52 Josh Kamau wrote:
 Thanks for the post.
 
 I wish this could be integrated into the core.
 
 Josh.
 
 On Mon, Feb 20, 2012 at 5:32 AM, robmcguinness 
 
 robert.mcguinness@gmail.com wrote:
  very nice thanks!
  
  --
  View this message in context:
  http://apache-wicket.1842946.n4.nabble.com/Shrinking-the-session-size-simp
  ly-by-zipping-it-Saved-my-day-tp4402980p4403065.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: [RELEASE] WASP/SWARM/Wicket security 1.4.1 released, roadmap for future direction

[Emond Papegaaij]

Wicket security for 1.4 is no longer maintained and it was never released as 
part of WicketStuff core. If you want to use wicket security on 1.4, I suggest 
you build it yourself from https://github.com/dashorst/wicketstuff-security . 
This is where we put it before adding it to WicketStuff core. Starting with 
1.5, wicket security is part of core and released together with the other 
modules. The WicketStuff maven repository is no longer available, as far as I 
know.

Best regards,
Emond 

On Thursday 19 April 2012 12:20:48 Martin Grigorov wrote:
 Hi,
 
 Check wicketstuff-security-** modules at
 http://repo1.maven.org/maven2/org/wicketstuff/
 
 On Thu, Apr 19, 2012 at 12:01 PM, Leonardo D'Alimonte
 
 leonardo.dalimo...@loginet.it wrote:
  Hi everybody,
  
  I'm still having troubles downloading Swarm 1.4 from the Wicketstuff Maven
  repository, GitHub alerts me that File Not Found...
  Is this version (i know isn't the latest..) so difficult to recover??
  
  Thanks,
  Leonardo
  
  --
  View this message in context:
  http://apache-wicket.1842946.n4.nabble.com/RELEASE-WASP-SWARM-Wicket-secu
  rity-1-4-1-released-roadmap-for-future-direction-tp2543742p4570279.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: WICKET-1.5.6 Feedback messages not updated on stateless pages

[Emond Papegaaij]

I've already created the ticket (WICKET-4536) and committed a fix.

Best regards,
Emond

On Monday 07 May 2012 11:13:22 Martin Grigorov wrote:
 Hi Thomas,
 
 It seems WICKET-4468 broke it somehow.
 Please file a ticket.
 
 On Sun, May 6, 2012 at 1:55 PM, Thomas Heigl tho...@umschalt.com wrote:
  Hello,
  
  I'm currently in the process of migrating a largish Wicket 1.4 application
  to 1.5. When moving from 1.5.5 to 1.5.6 something related to feedback
  messages breaks.
  
  On all my stateless pages, feedback messages are not rendered anymore when
  using:
  
  @Override
  protected void onError(AjaxRequestTarget target, Form? form) {
  target.addChildren(MyForm.this, FeedbackPanel.class);
  }
  
  The form is correctly traversed, all FeedbackPanels are added to the ajax
  target, and the ajax response actually contains the updated markup for the
  feedback panel. Just the message itself is missing and Wicket shows the
  typical Component-targeted feedback message has been left unrendered
  message.
  
  I checked the JIRA issues for 1.5.6 but didn't see anything related to
  feedback messages. Has there been some intentional change or is something
  broken in 1.5.6?
  
  Cheers,
  
  Thomas

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

Re: wicket-atmosphere NullPointerException at initialization

[Emond Papegaaij]

You will need the atmosphere.xml, although I don't think you'll get an NPE 
when that file is missing. The NPE is probably caused by a misconfiguration in 
your web.xml. As suggested, the examples are a good starting point. The 
BroadcasterFactory is setup from the init method of the AtmosphereServlet. 
Perhaps you forgot to add AtmosphereServlet to your web.xml? AtmosphereServlet 
loads atmosphere.xml, which in turn fires up the WicketFilter.

Best regards,
Emond Papegaaij

On Wednesday 13 June 2012 13:54:54 heapifyman wrote:
 I think I had the same problem and was able to overcome it by adding
 atmosphere.xml file in src/main/webapp/META-INF and changing the web.xml.
 Both I took from the wicket examples.
 
 atmosphere.xml looks like this:
 atmosphere-handlers
 atmosphere-handler context-root=/*
 class-name=org.atmosphere.handler.ReflectorServletProcessor
 property name=filterClassName
 value=org.apache.wicket.protocol.http.WicketFilter /
 /atmosphere-handler
 /atmosphere-handlers
 
 web.xml defines atmosphere servlet instead of default wicket filter:
 servlet
 servlet-nameAtmosphereApplication/servlet-name
 servlet-classorg.atmosphere.cpr.AtmosphereServlet/servlet-class
 init-param
 param-nameapplicationClassName/param-name
 param-valueorg.heapifyman.wicketatmospheretest.AtmosphereApplication/para
 m-value /init-param
 init-param
 param-nameorg.atmosphere.useWebSocket/param-name
 param-valuetrue/param-value
 /init-param
 init-param
 param-nameorg.atmosphere.useNative/param-name
 param-valuetrue/param-value
 /init-param
 init-param
 param-nameorg.atmosphere.cpr.CometSupport.maxInactiveActivity/param-name
 param-value3/param-value
 /init-param
 init-param
 param-namefilterMappingUrlPattern/param-name
 param-value/atmo/*/param-value
 /init-param
 init-param
 param-nameorg.atmosphere.websocket.WebSocketProtocol/param-name
 param-valueorg.atmosphere.websocket.protocol.EchoProtocol/param-value
 /init-param
 load-on-startup1/load-on-startup
 /servlet
 
 servlet-mapping
 servlet-nameAtmosphereApplication/servlet-name
 url-pattern/atmo/*/url-pattern
 /servlet-mapping
 
 
 2012/6/13 Martin Grigorov mgrigo...@apache.org
 
  Hi,
  
  Check what is different between your web.xml and atmosphere.xml and
  the ones in wicket-examples.war.
  
  The NPE is caused by not set org.atmosphere.cpr.BroadcasterFactory but
  I'm not sure what exactly setups it.
  
  On Wed, Jun 13, 2012 at 11:29 AM, theAnthony anthony.ric...@gmail.com
  
  wrote:
   Hi,
   
   I wanted to play around with wicket 6.0.0-beta2 and wicket-atmosphere, I
   created a quickstart created a simple page which would display a number
  
  and
  
   that number would come from a simple bean with a method scheduled to be
   executed every X seconds which would push the new value to the EventBus.
  
  But
  
   at initialization of the application, I get a NullPointerException in
   the
   EventBus.
   
   So I went back to the quickstart and made it as simple as possible. Just
   initializing the EventBus:
   
   mvn archetype:generate -DarchetypeGroupId=org.apache.wicket
   -DarchetypeArtifactId=wicket-archetype-quickstart
   -DarchetypeVersion=6.0.0-beta2 -DgroupId=com.company.ecom
   -DartifactId=emm-client-push2
   -DarchetypeRepository=https://repository.apache.org/-DinteractiveMode=fa
   lse
   
   Once created, I added the dependency in the pom file:
   
   dependency
   
  groupIdorg.apache.wicket/groupId
  artifactIdwicket-atmosphere/artifactId
  version0.1/version
   
   /dependency
   
   And finally modified init method of the WicketApplication class:
  public void init()
  {
  
  super.init();
  
  // add your configuration here
  new EventBus(this);
  
  }
   
   And when I launch the Start.java, here is the exception
   WARN  - AbstractLifeCycle  - FAILED wicket.emm-client-push2:
   java.lang.NullPointerException
   java.lang.NullPointerException
   
  at org.apache.wicket.atmosphere.EventBus.init(EventBus.java:85)
  at
  com.bnpp.ecom.WicketApplication.init(WicketApplication.java:31)
  at
  
  org.apache.wicket.Application.initApplication(Application.java:814)
  
  at
  
  org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:379)
  
  at
  
  org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:314)
  
  at
  
  org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:102)
  
  at
  
  org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle
  .java:59) 
  at
  
  org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:74
  8) 
  at
  
  org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContex
  tHandler.java:249) 
  at
  
  org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:122
  2

Re: wicket (1.5) push with cometd or atmosphere?

[Emond Papegaaij]

As the author of wicket-atmosphere, I would recommend wicket-atmosphere :) 
Wicket 6.0 is close to a final release and atmosphere does not depend on the 
servlet container. It will use native support, if available, but falls back to 
other solutions if the container does not support websocket. Naturally, you 
cannot do websocket on a servlet container that does not support the protocol.

For Wicket 1.5, I'm not aware of any real push framework. All implementations 
I've seen let the client do an AJAX call on a notification, which adds another 
round-trip and increases server load. As far as I know, this is the only way 
to do push in Wicket 1.5. Both server and client (js) do not support pushing 
component updates to the client without initiating an AJAX-call.

Best regards,
Emond Papegaaij

On Thursday 12 July 2012 04:15:52 Decebal Suiu wrote:
 Hi
 
 I want to use a push technology (now I use comet-timer from wicketstuff) for
 some notifications in my wicket (1.5) application and I have to chose
 between cometd (wicketstuff)  or atmosphere. I like wicket-atmosphere and
 wicket-native-socket from wicket-experimental but these require wicket 6.
 Finally I want to chose a push technology that not depends on servlet
 container.
 
 Any advice, links?
 
 Thanks,
 Decebak
 
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/wicket-1-5-push-with-cometd-or-a
 tmosphere-tp4650458.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: renderHead() / wicket:head page / component order

[Emond Papegaaij]

Hi Pierre,

First of all, I strongly recommend you do not use a different 
HeaderRenderStrategy. It is likely to get removed in future versions of Wicket 
and might break libraries that depend on the normal HeaderRenderStrategy. 
Second, I suggest you use Wicket 6, because consistent resource ordering in 
Wicket 1.5 is nearly impossible.

HeaderResponseTest in Wicket 6 gives a good demonstration of the order of 
resources. It shows that normal resources are rendered child-first, starting 
at the root of the class inheritance hierarchy. If you change nothing, the 
order will be B, C, A (A is last, because its header contribution is via 
renderHead). To move A to the front, you wrap it in a PriorityHeaderItem, and 
you should be done.

On Tuesday 24 July 2012 16:24:59 Pierre Goiffon wrote:
  The order is now consistent - no matter if you contribute the CSS via
  markup (head or wicket:head) or via code (in .java).
 
 I didn't understand your statement ? Particularly the order is now
 consistent.
 
 My problem was originally about the delivery order of wicket:head
 contributions that was changed in wicket 1.5.
 Reading your statement I understand wicket:head do still render parent
 first in Wicket 1.5 but in Wicket 6 renders child first, like the other
 Java way (renderHead() right ?), so I guess I don't understand well what
 you wrote ?

In Wicket 1.5, different contributions to the header render in different ways 
and the order may not be what you'd expect it to be. The intention was to 
render child-first, but that proved difficult to implement, therefore header 
rendering has undergone major refactoring in 6. In Wicket 6, all headers are 
rendered child-first, except PriorityHeaderItems, which are rendered parent-
first.

  Wicket defines two simple rules:
  1) component-first contribution - if you use a library that provides
  Wicket components (e.g. WiQuery) then the components will contribute
  first and then your page. This way you have the last word what CSS
  rules to apply. I.e. you can override WiQuery's default CSS rules.
  2) child-component contributes after its parent - when you use
  #renderHead(IHeaderResponse) you are in control to call
  super.renderHead() at the top  of the method body or at the bottom.
  Most of the time developers put it at the top. You don't have the
  control for that for wicket:head though. Here Wicket contributes
  first the parent's markup and then the child's one.

I'm not sure how this is in Wicket 1.5, but for Wicket 6, the second point is 
not correct. Moving the call to super.renderHead to the end of the method only 
changes the order between super- and subclass header items (the items for the 
superclass are inserted at the location of the super call). wicket:head is 
rendered child-first (not parent first), just as all other header items.

Best regards,
Emond

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

Re: renderHead() / wicket:head page / component order

[Emond Papegaaij]

Hi Pierre,

First of all, I strongly recommend you do not use a different 
HeaderRenderStrategy. It is likely to get removed in future versions of Wicket 
and might break libraries that depend on the normal HeaderRenderStrategy. 
Second, I suggest you use Wicket 6, because consistent resource ordering in 
Wicket 1.5 is nearly impossible.

HeaderResponseTest in Wicket 6 gives a good demonstration of the order of 
resources. It shows that normal resources are rendered child-first, starting 
at the root of the class inheritance hierarchy. If you change nothing, the 
order will be B, C, A (A is last, because its header contribution is via 
renderHead). To move A to the front, you wrap it in a PriorityHeaderItem, and 
you should be done.

On Tuesday 24 July 2012 16:24:59 Pierre Goiffon wrote:
  The order is now consistent - no matter if you contribute the CSS via
  markup (head or wicket:head) or via code (in .java).
 
 I didn't understand your statement ? Particularly the order is now
 consistent.
 
 My problem was originally about the delivery order of wicket:head
 contributions that was changed in wicket 1.5.
 Reading your statement I understand wicket:head do still render parent
 first in Wicket 1.5 but in Wicket 6 renders child first, like the other
 Java way (renderHead() right ?), so I guess I don't understand well what
 you wrote ?

In Wicket 1.5, different contributions to the header render in different ways 
and the order may not be what you'd expect it to be. The intention was to 
render child-first, but that proved difficult to implement, therefore header 
rendering has undergone major refactoring in 6. In Wicket 6, all headers are 
rendered child-first, except PriorityHeaderItems, which are rendered parent-
first.

  Wicket defines two simple rules:
  1) component-first contribution - if you use a library that provides
  Wicket components (e.g. WiQuery) then the components will contribute
  first and then your page. This way you have the last word what CSS
  rules to apply. I.e. you can override WiQuery's default CSS rules.
  2) child-component contributes after its parent - when you use
  #renderHead(IHeaderResponse) you are in control to call
  super.renderHead() at the top  of the method body or at the bottom.
  Most of the time developers put it at the top. You don't have the
  control for that for wicket:head though. Here Wicket contributes
  first the parent's markup and then the child's one.

I'm not sure how this is in Wicket 1.5, but for Wicket 6, the second point is 
not correct. Moving the call to super.renderHead to the end of the method only 
changes the order between super- and subclass header items (the items for the 
superclass are inserted at the location of the super call). wicket:head is 
rendered child-first (not parent first), just as all other header items.

Best regards,
Emond

Resent my mail, because the first one seem to have gotten lost somewhere.

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

Re: renderHead() / wicket:head page / component order

[Emond Papegaaij]

On Monday 30 July 2012 18:18:46 Pierre Goiffon wrote:
 But one more question though : why rendering wicket:head (in the markup
 file) contributions before renderHead() (in the java file) contributions ?
 Seems to me that what you'll put in wicket:head will certainly be some
 king of static code, like the css in my problem (so like this :
 .myclass{ padding: 0;} or $(document).ready(function(){
 $(#login).focus();});). This code could need some library (JQuery for
 exemple), and you'll serve that resource using a ResourceReference so
 using renderHead() right ? If wicket:head is served before renderHead()
 then you'll have a problem...

With these things you just have to make a decision. Both orders are equally 
valid. You use wicket:head for minor adjustments in styling, others use 
wicket:head to contribute the css files and do the adjustments in renderHead. 
The idea was, that with this order, it is always possible to override any 
static wicket:head contribution from the Java code. Personally, I try to avoid 
wicket:head as much as possible and render everything from renderHead. This 
gives you the most flexibility.

Best regards,
Emond

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

Re: [6.0] wicket-atmosphere

[Emond Papegaaij]

We've noticed this problem as well. It only happens on Tomcat. I'm not sure 
what is going on, but it all starts with Tomcat loosing query parameters on 
the ws-request (url/?0-1.IBehaviorListener.0- is changed to url). This 
makes it impossible for wicket to recognize the call to a behavior, causing a 
redirect to a new page on the ws-request, which is not allowed.

The question is, is this a bug in Tomcat, Atmosphere or wicket-atmosphere. I 
would say it's a bug in Atmosphere. I've created a ticket for this:
https://github.com/Atmosphere/atmosphere/issues/553

For now, using jetty is a work around.

Best regards,
Emond

On Wednesday 08 August 2012 20:59:10 Pierre Goupil wrote:
 Hello,
 
 It looks like a problem with the WebSockets. I've tried to provide a
 Locale, but no way:
 
 class MySession extends WebSession
 {
 private static final long serialVersionUID = 1L;
 
 public MySession(final Request req)
 {
 super(req);
 }
 
 @Override
 public void setLocale(final Locale locale)
 {
 super.setLocale(new Locale(en, GB));
 }
 }
 
 and in my WicketApplication:
 
 @Override
   public Session newSession( final Request req, final Response res ) {
 return new MySession(req);
   }
 
 It all gives me the same error.
 
 BUT if I deactivate the WebSockets, it works:
 
 init-param
 param-nameorg.atmosphere.useWebSocket/param-name
 param-valueFALSE/param-value
 /init-param
 
 in my web.xml.
 
 Regards,
 
 Pierre
 
 On Wed, Aug 8, 2012 at 5:43 PM, Pierre Goupil goupilpie...@gmail.comwrote:
  Good afternoon,
  
  I'm currently trying and have wicket-atmosphere work. I've looked at the
  examples and I'm unable to post a message because of this exception:
  
  
  INFO  - EventBus   - registering component for page 0 for
  session 971E81ED0E61970FA35A1B03E5B218F8:
  ERROR - DefaultExceptionMapper - Unexpected error occurred
  java.lang.IllegalStateException: Request#getLocale() cannot return null,
  request has to have a locale set on it
  
  at org.apache.wicket.Session.init(Session.java:211)
  at
  
  org.apache.wicket.protocol.http.WebSession.init(WebSession.java:92)
  
  at
  
  org.apache.wicket.protocol.http.WebApplication.newSession(WebApplication.j
  ava:536) 
  at
  
  org.apache.wicket.Application.fetchCreateAndSetSession(Application.java:15
  57) 
  at org.apache.wicket.Session.get(Session.java:152)
  at
  
  org.apache.wicket.RestartResponseAtInterceptPageException$InterceptData.ge
  t(RestartResponseAtInterceptPageException.java:146) 
  at
  
  org.apache.wicket.RestartResponseAtInterceptPageException$1.matchedData(Re
  startResponseAtInterceptPageException.java:211) 
  at
  
  org.apache.wicket.RestartResponseAtInterceptPageException$1.getCompatibili
  tyScore(RestartResponseAtInterceptPageException.java:179) 
  at
  
  org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(Compound
  RequestMapper.java:134) 
  at
  
  org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(Request
  Cycle.java:182) 
  at
  
  org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.j
  ava:207) 
  at
  
  org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(Reque
  stCycle.java:281) 
  at
  
  org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.j
  ava:188) 
  at
  
  org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:24
  5) 
  at
  
  org.atmosphere.util.AtmosphereFilterChain.doFilter(AtmosphereFilterChain.j
  ava:154) 
  at
  
  org.atmosphere.util.AtmosphereFilterChain.invokeFilterChain(AtmosphereFilt
  erChain.java:131) 
  at
  
  org.atmosphere.handler.ReflectorServletProcessor$FilterChainServletWrapper
  .service(ReflectorServletProcessor.java:310) 
  at
  
  org.atmosphere.handler.ReflectorServletProcessor.onRequest(ReflectorServle
  tProcessor.java:168) 
  at
  
  org.atmosphere.cpr.AsynchronousProcessor.action(AsynchronousProcessor.java
  :248) 
  at
  
  org.atmosphere.cpr.AsynchronousProcessor.suspended(AsynchronousProcessor.j
  ava:166) 
  at
  
  org.atmosphere.container.TomcatWebSocketUtil.doService(TomcatWebSocketUtil
  .java:120) 
  at
  
  org.atmosphere.container.Tomcat7BIOSupportWithWebSocket.service(Tomcat7BIO
  SupportWithWebSocket.java:57) 
  at
  
  org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.
  java:1222) 
  at
  
  org.atmosphere.websocket.WebSocketProcessor.dispatch(WebSocketProcessor.ja
  va:187) 
  at
  
  org.atmosphere.websocket.WebSocketProcessor.dispatch(WebSocketProcessor.ja
  va:116) 
  at
  
  org.atmosphere.container.TomcatWebSocketHandler.onOpen(TomcatWebSocketHand
  ler.java:58) 
  at
  
  org.apache.catalina.websocket.StreamInbound.onUpgradeComplete(StreamInboun
  d.java:228) 
  at
  
  

Re: Wicket 6.0.0 + Netbeans + Atmosphere

[Emond Papegaaij]

You probably did not setup Atmosphere. Wicket-Atmosphere requires Atmosphere 
to be available in your web application. Please consult the documentation of 
Atmosphere for instructions. You can also take a look at wicket-examples 
(especially web.xml and atmosphere.xml), which includes a working Wicket-
Atmosphere example.

Best regards,
Emond

On Monday 27 August 2012 00:25:44 Mats wrote:
 Hi,
 
 I just tried to get Atmosphere up and running in Wicket 6.0.0-beta3 using
 Netbeans 7.2...
 
 I have just added the jars needed one by one. Still I get some runtime error
 at startup;
 
   @Override
   public void init() {
 super.init();
 eventBus = new EventBus(this);   SEVERE:
 WebModule[/WebUI_2]PWC1270: Exception starting filter WicketApplication ...
   }
 
 So, my question is; *Exactly what jars do I need to include in my project?*
 I'm using NetBeans with Glassfish 3.1.2
 
 This is the included jars so far...
 http://apache-wicket.1842946.n4.nabble.com/file/n4651521/jars.png
 
 Anyone that could help me?
 
 
 
 
 
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Wicket-6-0-0-Netbeans-Atmosphere
 -tp4651521.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: Do I need a custom ResourceAggregator

[Emond Papegaaij]

Yes, this is the way to do it. Most of the code in ResourceAggregator is about 
resolving dependencies and resource bundles. If your DojoRequireHeaderItem is 
never part of a bundle (which probably is the case), you can skip the 
'getItemToBeRendered' part.

Best regards,
Emond

On Sunday 09 September 2012 01:26:49 Gonzalo Aguilar Delgado wrote:
 Hello,
 
 I can answer myself.
 
 I was studing wicket code and the examples and found a solution,
 extending DecoratingHeaderResponse. It still makes me feel a little bit
 lost but it works.
 
 I copied functionality from ResourceAggregator.
 
 
 public class DojoAggregatorHeaderResponse extends
 DecoratingHeaderResponse {
 ...
 
   private void renderCombinedEventScripts()
   {
   StringBuilder combinedScript = new StringBuilder();
   ListString dojoDependencies = new ArrayListString();
   for (DojoRequireHeaderItem curItem : 
 dojoRequireItemsToBeRendered)
   {
   HeaderItem itemToBeRendered = 
 getItemToBeRendered(curItem);
   if (itemToBeRendered == curItem)
   {
   combinedScript.append(\n);
   combinedScript.append(curItem.getJavaScript());
   combinedScript.append(;);
   for(String requirement : 
 curItem.getDojoDependencies())
   {
   
 if(!dojoDependencies.contains(requirement))
   
 dojoDependencies.add(requirement);  // TODO Will be 
faster with a
 hash?
   }
   }
   else
   {
   getRealResponse().render(itemToBeRendered);
   }
 
   }
   if (combinedScript.length()  0)
   {
   getRealResponse().render(
 
 DojoRequireHeaderItem.forScript(combinedScript.append(\n).toString(),dojoD
 ependencies)); }
   }
 ...
 }
 
 
 
 Is this correct way to do it?
 
 
 Best regards,
 
 El sáb, 08-09-2012 a las 21:35 +0200, Gonzalo Aguilar Delgado escribió:
  Hello,
  
  I'm reimplementing my dojo interface again with version 6.0.0 of wicket.
  
  I need to replicate same functionality that gives ResourceAggregator +
  OnDomReadyHeaderItem.
  
  I mean, I need that every script that goes into the require when don is
  aggregated.
  
  
  require([dojo/dom, dojo/domReady!], function(dom){
  
  // All scripts here...
  
  });
  
  
  So I just want to create a new header item called DojoReadyHeaderItem
  and add everything needed to the same script at the begining of the
  page.
  
  Behaviors will do something like this:
  
  response.render(DojoReadyHeaderItem.forScript(foobar));
  
  response.render(DojoReadyHeaderItem.forScript(foobar2));
  
  And the result will be like:
  
  
  require([dojo/dom, dojo/domReady!], function(dom){
  
  foobar;
  foobar2;
  
  });
  
  
  How can I do this with current implementation?
  
  I don't know how to add my own ResourceAggregator...
  
  
  Thank you in advance.
  
  
  
  -
  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

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

Re: HazelCast and Atmosphere Integration with Wicket 6

[Emond Papegaaij]

Hi,

I don't know HazelCast, but the problem you are seeing is that EventBus.get() 
only works when the application is attached to the current thread. You either 
have to pass a reference to the EventBus to your broadcaster, or, if you have 
access to the Wicket Application, you can set it on ThreadLocal (make sure you 
unset it in a finally). wicket-atmosphere-0.4-SNAPSHOT has a  
EventBus.get(Application), where you can pass in to application to use.

Best regards,
Emonds

On Monday 10 September 2012 05:38:15 esajjkh wrote:
 Hi
 
 I am using HazelCast(HazelcastBroadcaster) and Atmosphere in Wicket 6
 application. When a new message is published the application throws a
 *WicketRunTimeException* There is no application attached with current
 thread in the follwing signature of MyHazelcastBroadcaster :
 
 class MyHazelcastBroadcaster extends HazelcastBroadcaster{
 ..
  @Override
 public void incomingBroadcast() {
  ITopic topic = Hazelcast.getTopic(getID());
 topic.addMessageListener(new SSPMessageListner() {
 
 @Override
 public void onMessage(String e) {
   * EventBus.get().post(e);*//post the event so the method
 with @Subscribe annotation should be called.
}
 });
 
 }
 }
 
 In my ApplicationClass i configured this broadcaster and Atmospher like
 this:
 ...
 MyHazelcastBroadcaster bc = (MyHazelcastBroadcaster)
 BroadcasterFactory.getDefault().get(MY_EVENT);
 bc.setUp();
 eventBus= new EventBus(this,bc)   //my broadcaster is registered with
 eventbus
 
 
 Am I missing anything? Thank you!
 
 
 
 
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/HazelCast-and-Atmosphere-Integra
 tion-with-Wicket-6-tp4651891.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: HazelCast and Atmosphere Integration with Wicket 6

[Emond Papegaaij]

Hi,

I just noticed a small error in my advice: the class is not called
ThreadLocal but ThreadContext. The idea is very simple:

try {
  ThreadContext.setApplication(application);
  /* do your thing */
} finally {
  ThreadContext.setApplication(null);
}

The problem with this code is that you might potentially overwrite the
application in ThreadContext, therefore it is better to use the new
method from wicket-atmosphere-0.4-SNAPSHOT: EventBus.get(application).
0.4 is better than 0.3 anyway, because it supports multiple tabs for
the same page, has better cleanup on disconnections and is based on
atmosphere-1.0.0, which fixes many issues.

Best regards,
Emond

On Mon, Sep 10, 2012 at 4:13 PM, esajjkh programmer.saj...@gmail.com wrote:
 Hello Emonds,

 Thank you for your help.  Will you please enlighten your idea of attaching
 application with ThreadLocal with a code snippet?



 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/HazelCast-and-Atmosphere-Integration-with-Wicket-6-tp4651891p4651894.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: HazelCast and Atmosphere Integration with Wicket 6

[Emond Papegaaij]

You will need the application. Without the application, it won't work. There 
are dozens of ways to pass the application to where you need it. For example, 
you could inject it using your favorite dependency injection framework, or you 
could pass it manually to the place where you need it.

Best regards,
Emond

On Tuesday 11 September 2012 00:56:59 esajjkh wrote:
 Hi,
 Thank you for your support. MyHazelCastBroadCaster is not a wicket component
 so when i tried to get the Application either from my application class  or
 from *Session.get().getApplcation()*  throws exception. Your help will be
 appreciated. Thank you!
 
 
 
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/HazelCast-and-Atmosphere-Integra
 tion-with-Wicket-6-tp4651891p4651905.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: HazelCast and Atmosphere Integration with Wicket 6

[Emond Papegaaij]

You can find all information about Wicket's downloads, repositories and scm on 
http://wicket.apache.org/start/download.html

Best regards,
Emond

On Tuesday 11 September 2012 04:37:36 esajjkh wrote:
 Thanks Emond, Where I can find the wicket-atmosphere 0.4-snapshot maven
 dependency?
 
 
 
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/HazelCast-and-Atmosphere-Integra
 tion-with-Wicket-6-tp4651891p4651909.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: HazelCast and Atmosphere Integration with Wicket 6

[Emond Papegaaij]

Then you probably didn't register the EventBus in your application's init 
method. Please take a look at the demo-application I've setup:
https://github.com/papegaaij/wicket-atmosphere-quickstart

It contains the minimal configuration needed for wicket-atmosphere.

Best regards,
Emond

On Wednesday 12 September 2012 04:40:41 esajjkh wrote:
 Thanks for your help and support. I am using now wicket-atmosphere 0.4
 snapshot and atmosphere 1.0.0 .
 
 I managed the reference of applicationclass in MyHazelcastBroadcaster class.
 Both classes looks like this now:
 
 class MyApplicationClass extends AuthenticatedWebApplication{
 
  .
 @Override
 protected void init() {
 super.init();
 bc = (MyHazelCastBroadcaster)
 BroadcasterFactory.getDefault().get(MY_EVENT);
 bc.setUp();
 *bc.setApplication(this);*   // setting the application in
 MyHazelCastBroadcaster
 
 eventBus = new EventBus(this, bc);
 
  
   }
 }
 
 and in MyHazelBroadcaster class I am publishing the event like this:
 
  EventBus.get(myapplication).post(message)
 
 Now it throws exception in EventBus class
 on*application.getMetaData(EVENT_BUS_KEY)*  call, as it doesn't find any
 metadata associated with this event bus :(
 Any help pease? Tack
 
 
 
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/HazelCast-and-Atmosphere-Integra
 tion-with-Wicket-6-tp4651891p4651939.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: Wicket-Atmosphere complex JS

[Emond Papegaaij]

This is most likely caused by incorrect escaping, which might be a bug in 
Wicket or Wicket-Atmosphere. Can you try to create a quickstart to demonstrate 
the problem and file a Jira ticket? You can use the example application at 
https://github.com/papegaaij/wicket-atmosphere-quickstart

Best regards,
Emond

On Sunday 11 November 2012 18:03:52 Pierre Goupil wrote:
 Hi all,
 
 When I submit complex JS to my client using target.appendJavaScript() with
 a @Subscribe method from Wicket-Atmosphere, I got this message in the
 browser console:
 
 Wicket.Ajax: Wicket.Ajax.Call.failure: Error while parsing response:
 Could not find root ajax-response element
 
 I do have an ajax-response tag and the response from the server seems to
 be all OK. Nonetheless, for a reason I'm not aware of, it fails.
 
 Did anyone encounter this error before? Is there a known work-around?
 
 When I have a simple response, it works though. The problem only occurs
 with complex responses.
 
 I'm using:
 
 wicket.version6.3.0-SNAPSHOT/wicket.version
 wicketstuff.version6.2.1/wicketstuff.version
 wicket-atmosphere.version0.5-SNAPSHOT/wicket-atmosphere.version
 
 (GIT master)
 
 Regards,
 
 Pierre

Re: Wicket 6 Atmosphere - where to configure filter-mapping dispatchers?

[Emond Papegaaij]

As far as I know, the latest versions of wicket-atmosphere and atmosphere 
should fall through to the default servlet handling if wicket does not handle 
the request. I don't know that much about servlet configuration, but I don't 
think wicket-atmoshpere changes anything in this context. You might try asking 
your question on the Atmosphere framework mailing list at google groups.

Best regards,
Emond

On Monday 12 November 2012 11:26:37 pkc wrote:
 Before atmosphere, i used a standard web.xml filter and the following
 mappings:
 
 filter-mapping
 filter-namewicket/filter-name
 url-pattern/*/url-pattern
 dispatcherREQUEST/dispatcher
 dispatcherINCLUDE/dispatcher
 dispatcherFORWARD/dispatcher
 dispatcherERROR/dispatcher
 /filter-mapping
 
 From the examples, I now define the filter in the atmosphere.xml which works
 except I don't see a way to configure the dispatchers for FORWARD and
 ERROR.
 
 atmosphere-handlers
   atmosphere-handler context-root=/*
   class-name=org.atmosphere.handler.ReflectorServletProcessor
   property name=filterClassName
 value=org.apache.wicket.protocol.http.WicketFilter /
   /atmosphere-handler
 /atmosphere-handlers
 
 This is the last obstacle to my 1.5 to 6.2 migration and I already put a lot
 of work into it so any help is greatly appreciated.
 
 
 
 
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Wicket-6-Atmosphere-where-to-con
 figure-filter-mapping-dispatchers-tp4653794.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: Wicket-Atmosphere complex JS

[Emond Papegaaij]

I found the link to the wiki page explaining how to fix this:
https://github.com/Atmosphere/atmosphere/wiki/Multiply-messages-arrives-as-
single-response-body-or-message-received-are-incomplete

It seems the trackMessageLength option needs to be enabled in the js, and some 
additional code is needed server side. From what I see, neither one will work 
without the other. Can you try if the solution provided at wiki works? To pass 
the additional option in the js, just copy jquery.wicketatmosphere.js, add the 
parameter and register the new file as a replacement resource in the 
application. Also please create a Jira issue for this. If you could post your 
findings there, that would help me tremendously, because my time to work on 
Wicket is very limited at the moment.

Best regards,
Emond

On Tuesday 13 November 2012 16:03:30 Martin Grigorov wrote:
 The problem is that Atmosphere sends the response in chunks.
 Jean Francois explained in Atmosphere mailing lists that a special
 Atmosphere has to be used that will collect the whole response before
 flushing it.
 
 
 On Tue, Nov 13, 2012 at 3:25 PM, Emond Papegaaij emond.papega...@topicus.nl
  wrote:
  
  This is most likely caused by incorrect escaping, which might be a bug in
  Wicket or Wicket-Atmosphere. Can you try to create a quickstart to
  demonstrate
  the problem and file a Jira ticket? You can use the example application at
  https://github.com/papegaaij/wicket-atmosphere-quickstart
  
  Best regards,
  Emond
  
  On Sunday 11 November 2012 18:03:52 Pierre Goupil wrote:
   Hi all,
   
   When I submit complex JS to my client using target.appendJavaScript()
  
  with
  
   a @Subscribe method from Wicket-Atmosphere, I got this message in the
   browser console:
   
   Wicket.Ajax: Wicket.Ajax.Call.failure: Error while parsing response:
   Could not find root ajax-response element
   
   I do have an ajax-response tag and the response from the server seems
  
  to
  
   be all OK. Nonetheless, for a reason I'm not aware of, it fails.
   
   Did anyone encounter this error before? Is there a known work-around?
   
   When I have a simple response, it works though. The problem only occurs
   with complex responses.
   
   I'm using:
   wicket.version6.3.0-SNAPSHOT/wicket.version
   wicketstuff.version6.2.1/wicketstuff.version
  
  wicket-atmosphere.version0.5-SNAPSHOT/wicket-atmosphere.version
  
   (GIT master)
   
   Regards,
   
   Pierre

Re: Example of wicket atmosphere with channel

[Emond Papegaaij]

I presume you are refering to WICKET-4879, There are no examples of the new
API yet, but the changes are not that big. I did not really implement
channels, but made the changes that would allow you to implement channels.
It is now possible to post an event to a single client (rather than all
clients), either via the AtmosphereResource for that client, or its UUID. I
also added a contextAwareFilter() to @Subscribe, which allows you to access
the RequestCycle and session from the filter. This can be used to
differentiate on the receiver of the event, where filter() can only be used
to differentiate on the content of the event. Be careful with this new
method though, because it will not scale very will with large numbers of
concurrent users.

Looking at the code again, I think I'm going to change the Predicate into a
Function on AtmosphereResource. That would allow you to keep track of some
attributes in AtmosphereRequest on which to write your filter, which puts a
lot less weight on the server than setting up a RequestCycle.

Best regards,
Emond Papegaaij


On Thu, Dec 20, 2012 at 8:31 PM, Noven noven_...@yahoo.com wrote:

 Hi,

 I just saw new features released at wicket 6.40. And I am interested to
 see example code of the atmosphere channel. Where can i find the example of
 this feature?

 Thanks.

Re: Wicket Atmosphere does not run in Firefox 17

[Emond Papegaaij]

It seems you hosting provider does not support websockets. For some reason,
in Chrome the downgrade to 'streaming' works fine, but in Firefox it does
not. Firefox keeps trying to establish a ws connection, which fails over
and over again. I think this is a problem in Atmosphere. You could try
asking this question at their google groups. I've created a ticket
(WICKET-4946) for passing parameters to atmosphere, which would allow you
to disable websocket.

Best regards,
Emond Papegaaij


On Mon, Dec 24, 2012 at 12:22 PM, Noven noven_...@yahoo.com wrote:


 Hi,

 Thank you for your reply before. I did not change anything in firefox. If
 I have to, I can't use this feature.
 I doubt if the problem caused from firefox. When the quickstart deployed
 in my localhost (both tomcat and jetty), it run well in firefox.


 
  From: Andreas Kuhtz andreas.ku...@gmail.com
 To: users@wicket.apache.org; Noven noven_...@yahoo.com
 Sent: Monday, December 24, 2012 5:21 PM
 Subject: Re: Wicket Atmosphere does not run in Firefox 17


 Hi,

 Have you configured a proxy in firefox? if so, you may enable the ws://*
 to use the proxy, not only http and https.
 Hope this helps.

 Cheers


 2012/12/24 Noven noven_...@yahoo.com

 Hi All,
 
 I just tried deploy the wicket-atmosphere-quickstart here at
 http://api.bola54.com into tomcat v.7.0.32
 
 It's able run well on safari and chrome, but fail run on newest firefox
 v.17.
 
 By using the same tomcat version, I am able to run it on firefox v.17 in
 my localhost but failed at http://api.bola54.com.
 
 
 Did anybody know this issue before?
 
 
 Thank you.

Re: Wicket Atmosphere does not run in Firefox 17

[Emond Papegaaij]

Disabling WS will cause atmosphere to fall back on a different protocol, such 
as http streaming or polling. WS is designed to support 2-way communication, 
http is not. These other implementations might not be as reliable or might 
consume more resources. This page contains a nice description of the benefits 
of WS:
http://www.websocket.org/quantum.html

Best regards,
Emond

On Monday 07 January 2013 17:48:34 Noven wrote:
 Emond,
 
 Finally I can make it run in Firefox by disable using websocket in web.xml
 
 
 init-param
 param-nameorg.atmosphere.useWebSocket/param-name
 param-valuefalse/param-value
 /init-param
 
 
 Don't know if there's drawback doing that since it comes as default setting
 in the quickstart.
 
 
 Regards,
 Noven
 
 
 
  From: Emond Papegaaij emond.papega...@gmail.com
 To: users@wicket.apache.org; Noven noven_...@yahoo.com
 Sent: Thursday, December 27, 2012 2:29 PM
 Subject: Re: Wicket Atmosphere does not run in Firefox 17
 
 It seems you hosting provider does not support websockets. For some reason,
 in Chrome the downgrade to 'streaming' works fine, but in Firefox it does
 not. Firefox keeps trying to establish a ws connection, which fails over
 and over again. I think this is a problem in Atmosphere. You could try
 asking this question at their google groups. I've created a ticket
 (WICKET-4946) for passing parameters to atmosphere, which would allow you
 to disable websocket.
 
 Best regards,
 Emond Papegaaij
 
 On Mon, Dec 24, 2012 at 12:22 PM, Noven noven_...@yahoo.com wrote:
  Hi,
  
  Thank you for your reply before. I did not change anything in firefox. If
  I have to, I can't use this feature.
  I doubt if the problem caused from firefox. When the quickstart deployed
  in my localhost (both tomcat and jetty), it run well in firefox.
  
  
  
 
   From: Andreas Kuhtz andreas.ku...@gmail.com
 
  To: users@wicket.apache.org; Noven noven_...@yahoo.com
  Sent: Monday, December 24, 2012 5:21 PM
  Subject: Re: Wicket Atmosphere does not run in Firefox 17
  
  
  Hi,
  
  Have you configured a proxy in firefox? if so, you may enable the ws://*
  to use the proxy, not only http and https.
  Hope this helps.
  
  Cheers
  
  
  2012/12/24 Noven noven_...@yahoo.com
  
  Hi All,
  
  I just tried deploy the wicket-atmosphere-quickstart here at
  
  http://api.bola54.com into tomcat v.7.0.32
  
  It's able run well on safari and chrome, but fail run on newest firefox
  
  v.17.
  
  By using the same tomcat version, I am able to run it on firefox v.17 in
  
  my localhost but failed at http://api.bola54.com.
  
  Did anybody know this issue before?
  
  
  Thank you.

Re: Wicket Atmosphere does not run in Firefox 17

[Emond Papegaaij]

The quickstart does work on Firefox, but not on your provider. You should only 
enable WS if your provider supports it. Atmosphere tries to autodetect the 
capabilities of the browser and server to determine the best protocol to use. 
For some reason, this system fails to detect that WS is not working on your 
server, but only on Firefox. Chrome reverts to streaming and IE does not 
support WS at all, so it starts with streaming right away.

Best regards,
Emond

On Tuesday 08 January 2013 17:25:07 Noven wrote:
 Emond,
 
 Thank you for the link.
 Btw didn't you find the quickstart does not work in firefox?
 
 I will enable WS back and figure it out how to fix in firefox.
 
 Regards,
 Noven
 
 
 
 
 
  From: Emond Papegaaij emond.papega...@topicus.nl
 To: users@wicket.apache.org; Noven noven_...@yahoo.com
 Sent: Tuesday, January 8, 2013 3:38 PM
 Subject: Re: Wicket Atmosphere does not run in Firefox 17
 
 Disabling WS will cause atmosphere to fall back on a different protocol,
 such as http streaming or polling. WS is designed to support 2-way
 communication, http is not. These other implementations might not be as
 reliable or might consume more resources. This page contains a nice
 description of the benefits of WS:
 http://www.websocket.org/quantum.html
 
 Best regards,
 Emond
 
 On Monday 07 January 2013 17:48:34 Noven wrote:
  Emond,
  
  Finally I can make it run in Firefox by disable using websocket in web.xml
  
  
  init-param
 
  param-nameorg.atmosphere.useWebSocket/param-name
  param-valuefalse/param-value
  /init-param
 
  Don't know if there's drawback doing that since it comes as default
  setting
  in the quickstart.
  
  
  Regards,
  Noven
  
  
  
 
   From: Emond Papegaaij emond.papega...@gmail.com
 
  To: users@wicket.apache.org; Noven noven_...@yahoo.com
  Sent: Thursday, December 27, 2012 2:29 PM
  Subject: Re: Wicket Atmosphere does not run in Firefox 17
  
  It seems you hosting provider does not support websockets. For some
  reason,
  in Chrome the downgrade to 'streaming' works fine, but in Firefox it does
  not. Firefox keeps trying to establish a ws connection, which fails over
  and over again. I think this is a problem in Atmosphere. You could try
  asking this question at their google groups. I've created a ticket
  (WICKET-4946) for passing parameters to atmosphere, which would allow you
  to disable websocket.
  
  Best regards,
  Emond Papegaaij
  
  On Mon, Dec 24, 2012 at 12:22 PM, Noven noven_...@yahoo.com wrote:
   Hi,
   
   Thank you for your reply before. I did not change anything in firefox.
   If
   I have to, I can't use this feature.
   I doubt if the problem caused from firefox. When the quickstart deployed
   in my localhost (both tomcat and jetty), it run well in firefox.
   
   
   
  
From: Andreas Kuhtz andreas.ku...@gmail.com
  
   To: users@wicket.apache.org; Noven noven_...@yahoo.com
   Sent: Monday, December 24, 2012 5:21 PM
   Subject: Re: Wicket Atmosphere does not run in Firefox 17
   
   
   Hi,
   
   Have you configured a proxy in firefox? if so, you may enable the
   ws://*
   to use the proxy, not only http and https.
   Hope this helps.
   
   Cheers
   
   
   2012/12/24 Noven noven_...@yahoo.com
   
   Hi All,
   
   I just tried deploy the wicket-atmosphere-quickstart here at
   
   http://api.bola54.com into tomcat v.7.0.32
   
   It's able run well on safari and chrome, but fail run on newest firefox
   
   v.17.
   
   By using the same tomcat version, I am able to run it on firefox v.17
   in
   
   my localhost but failed at http://api.bola54.com.
   
   Did anybody know this issue before?
   
   
   Thank you.

Re: [wicket-atmosphere] resource UUID

[Emond Papegaaij]

Hi Pierre,

The UUID is bound to a page when atmosphere makes to call back to the server, 
which makes sense because before then, there is no AtmosphereResource, which 
means there cannot be a UUID. I think this is a bit of a design flaw, because 
it is not possible to listen to the registration of this uuid. I'll see if I 
can add a listener to EventBus to act on the registration and removal of 
tracked pages: https://issues.apache.org/jira/browse/WICKET-4957 . I'll try to 
fix this later today.

For the testcase, you can use post with a resource and take the resource from 
the Broadcaster:
  BroadcasterFactory.getDefault() to get the BroadcasterFactory
  factory.lookup... to get the Broadcaster
  broadcaster.getAtmosphereResources() and pick one

Best regards,
Emond

On Monday 07 January 2013 22:43:43 Pierre Goupil wrote:
 Good evening,
 
 As asked in WICKET-4879
 https://issues.apache.org/jira/browse/WICKET-4879I was supposed to
 create a quickstart demonstrating that
 Application.get().getEventBus().post(MyObject, pageUuid) sends its messages
 to all connected clients.
 
 I'd like to apologize here because I haven't created it yet: it's been 1
 month since I'm sick and / or in holidays and I've only managed to create
 it this evening. My bad, sorry.
 
 So I'm in the process of creating this quickstart and I have a problem,
 when I do:
 
 AtmosphereBehavior.getUUID(this)
 
 in a WebPage (a sub-class of it, in fact) it always returns null. So I'm
 unable to have a working post(MyObject, pageUuid).
 
 Does anyone has an idea regarding this?
 
 I use wicket-atmosphere 0.7-SNAPSHOT: in 0.4-SNAPSHOT it used to work well
 (at least the UUID retrieving part) but it looks like it's not the case
 anymore.
 
 Thanks in advance,
 
 Pierre Goupil

Re: [wicket-atmosphere] resource UUID

[Emond Papegaaij]

I've just pushed the fix for WICKET-4957: you can now listen to the 
registration of resources for pages.

Best regards,
Emond

On Tuesday 08 January 2013 23:49:36 Pierre Goupil wrote:
 Emond,
 
 I've tried it like you said and it almost works! It works in the sense that
 I'm able to send an event to only one resource : that alone is fine in
 itself.
 
 But unfortunately, when doing: broadcaster.getAtmosphereResources() I don't
 know which browser corresponds to which resource. So I definitively need
 your functionality of resource creation listening.
 
 Keep up the good work!
 
 Cheers,
 
 Pierre
 
 On Tue, Jan 8, 2013 at 2:07 PM, Pierre Goupil goupilpie...@gmail.comwrote:
  Excellent, Emond! I'll try it like you said and tell you what happens.
  
  Cheers,
  
  Pierre
  
  
  On Tue, Jan 8, 2013 at 1:55 PM, Emond Papegaaij 
  
  emond.papega...@topicus.nl wrote:
  Hi Pierre,
  
  The UUID is bound to a page when atmosphere makes to call back to the
  server,
  which makes sense because before then, there is no AtmosphereResource,
  which
  means there cannot be a UUID. I think this is a bit of a design flaw,
  because
  it is not possible to listen to the registration of this uuid. I'll see
  if I
  can add a listener to EventBus to act on the registration and removal of
  tracked pages: https://issues.apache.org/jira/browse/WICKET-4957 . I'll
  try to
  fix this later today.
  
  For the testcase, you can use post with a resource and take the resource
  from
  
  the Broadcaster:
BroadcasterFactory.getDefault() to get the BroadcasterFactory
factory.lookup... to get the Broadcaster
broadcaster.getAtmosphereResources() and pick one
  
  Best regards,
  Emond
  
  On Monday 07 January 2013 22:43:43 Pierre Goupil wrote:
   Good evening,
   
   As asked in WICKET-4879
   https://issues.apache.org/jira/browse/WICKET-4879I was supposed to
   create a quickstart demonstrating that
   Application.get().getEventBus().post(MyObject, pageUuid) sends its
  
  messages
  
   to all connected clients.
   
   I'd like to apologize here because I haven't created it yet: it's been
   1
   month since I'm sick and / or in holidays and I've only managed to
  
  create
  
   it this evening. My bad, sorry.
   
   So I'm in the process of creating this quickstart and I have a problem,
   when I do:
   
   AtmosphereBehavior.getUUID(this)
   
   in a WebPage (a sub-class of it, in fact) it always returns null. So
   I'm
   unable to have a working post(MyObject, pageUuid).
   
   Does anyone has an idea regarding this?
   
   I use wicket-atmosphere 0.7-SNAPSHOT: in 0.4-SNAPSHOT it used to work
  
  well
  
   (at least the UUID retrieving part) but it looks like it's not the case
   anymore.
   
   Thanks in advance,
   
   Pierre Goupil
  
  --
  Parce que c'est la nuit qu'il est beau de croire à la lumière.
  
  Edmond Rostand

Re: [wicket-atmosphere] atmosphere version

[Emond Papegaaij]

With recent versions of wicket-atmosphere, you are required to add this 
parameter to the AtmosphereServlet:
init-param
param-nameorg.atmosphere.cpr.broadcastFilterClasses/param-name
param-valueorg.apache.wicket.atmosphere.TrackMessageSizeFilter/param-
value
/init-param

Did you add that?

Best regards,
Emond


On Tuesday 08 January 2013 23:52:40 Pierre Goupil wrote:
 Good evening,
 
 Which version of the atmosphere runtime am I supposed to use with
 wicket-atmosphere?
 
 In my app, when I use atmosphere 1.0.0 everything works, but when I use
 atmosphere 1.0.4 or 1.0.5, no Comet channel works. I use wicket-atmosphere
 0.7-SNAPSHOT.
 
 Regards,
 
 Pierre

Re: [wicket-atmosphere] resource UUID

[Emond Papegaaij]

You should register it with EventBus.addRegistrationListener and a page should 
not implement the interface, it is meant as an application global listener.

Emond

On Thursday 10 January 2013 15:50:12 Pierre Goupil wrote:
 Indeed. I've tried this in my page constructor:
 
 Application.get().getEventBus().registerPage(hp + UUID.randomUUID(),
 this);
 
 But it doesn't do the trick. Sorry to bug you, but I can't find the right
 method!
 
 Regards,
 
 Pierre
 
 On Thu, Jan 10, 2013 at 3:30 PM, Martin Grigorov 
mgrigo...@apache.orgwrote:
  You have to register it in the EventBus
  
  
  On Thu, Jan 10, 2013 at 4:27 PM, Pierre Goupil goupilpie...@gmail.com
  
  wrote:
   Hi Emond,
   
   I must be doing something wrong, as it doesn't work. I have implemented
   ResourceRegistrationListener in my HomePage and I set the UUIDs in the
   method resourceRegistered() but my logs show that it's never called.
   
   Is there any more than implementing ResourceRegistrationListener that
   I'm
   supposed to do?
   
   Regards,
   
   Pierre
   
   
   On Thu, Jan 10, 2013 at 1:05 PM, Emond Papegaaij 
   emond.papega...@topicus.nl
   
wrote:

I've just pushed the fix for WICKET-4957: you can now listen to the
registration of resources for pages.

Best regards,
Emond

On Tuesday 08 January 2013 23:49:36 Pierre Goupil wrote:
 Emond,
 
 I've tried it like you said and it almost works! It works in the
  
  sense
  
that

 I'm able to send an event to only one resource : that alone is fine
  
  in
  
 itself.
 
 But unfortunately, when doing: broadcaster.getAtmosphereResources()
 I

don't

 know which browser corresponds to which resource. So I definitively
   
   need
   
 your functionality of resource creation listening.
 
 Keep up the good work!
 
 Cheers,
 
 Pierre
 
 On Tue, Jan 8, 2013 at 2:07 PM, Pierre Goupil 
  
  goupilpie...@gmail.com
  
wrote:
  Excellent, Emond! I'll try it like you said and tell you what
   
   happens.
   
  Cheers,
  
  Pierre
  
  
  On Tue, Jan 8, 2013 at 1:55 PM, Emond Papegaaij 
  
  emond.papega...@topicus.nl wrote:
  Hi Pierre,
  
  The UUID is bound to a page when atmosphere makes to call back to
   
   the
   
  server,
  which makes sense because before then, there is no
   
   AtmosphereResource,
   
  which
  means there cannot be a UUID. I think this is a bit of a design
   
   flaw,
   
  because
  it is not possible to listen to the registration of this uuid.
  
  I'll
  
see

  if I
  can add a listener to EventBus to act on the registration and
   
   removal
   
of

  tracked pages: https://issues.apache.org/jira/browse/WICKET-4957.

I'll

  try to
  fix this later today.
  
  For the testcase, you can use post with a resource and take the

resource

  from
  
  the Broadcaster:
BroadcasterFactory.getDefault() to get the BroadcasterFactory
factory.lookup... to get the Broadcaster
broadcaster.getAtmosphereResources() and pick one
  
  Best regards,
  Emond
  
  On Monday 07 January 2013 22:43:43 Pierre Goupil wrote:
   Good evening,
   
   As asked in WICKET-4879
   https://issues.apache.org/jira/browse/WICKET-4879I was
  
  supposed
  
to

   create a quickstart demonstrating that
   Application.get().getEventBus().post(MyObject, pageUuid) sends
  
  its
  
  messages
  
   to all connected clients.
  
   I'd like to apologize here because I haven't created it yet:
  it's
  
been

   1
   month since I'm sick and / or in holidays and I've only managed
  
  to
  
  create
  
   it this evening. My bad, sorry.
   
   So I'm in the process of creating this quickstart and I have a

problem,

   when I do:
   
   AtmosphereBehavior.getUUID(this)
   
   in a WebPage (a sub-class of it, in fact) it always returns
  
  null.
  
   So
   
   I'm
   unable to have a working post(MyObject, pageUuid).
   
   Does anyone has an idea regarding this?
   
   I use wicket-atmosphere 0.7-SNAPSHOT: in 0.4-SNAPSHOT it used
   to

work

  well
  
   (at least the UUID retrieving part) but it looks like it's not
  
  the
  
case

   anymore.
   
   Thanks in advance,
   
   Pierre Goupil
  
  --
  Parce que c'est la nuit qu'il est beau de croire à la lumière.
  
  Edmond Rostand
   
   --
   Parce que c'est la nuit qu'il est beau de croire à la lumière.
   
   Edmond Rostand
  
  --
  Martin Grigorov
  jWeekend
  Training, Consulting, Development
  http://jWeekend.com http://jweekend.com/

Re: [wicket-atmosphere] atmosphere version

[Emond Papegaaij]

Yes, it should work with any 1.0 version. I think you should try to verify the 
AJAX-messges, perhaps with Wicket's AJAX-debugger.

Best regards,
Emond

On Friday 11 January 2013 17:06:09 Pierre Goupil wrote:
 Sure! But it doesn't help. And as I said, there is no error in my logs,
 neither client-side nor server-side.
 
 As I understand things, it should work with any version of Atmosphere
 starting from 1.0.0, right?
 
 Do you have any clue?
 
 Regards,
 
 Pierre
 
 
 
 
 On Thu, Jan 10, 2013 at 1:07 PM, Emond Papegaaij emond.papega...@topicus.nl
  wrote:
  
  With recent versions of wicket-atmosphere, you are required to add this
  parameter to the AtmosphereServlet:
  init-param
  
  param-nameorg.atmosphere.cpr.broadcastFilterClasses/param-name
  
  param-valueorg.apache.wicket.atmosphere.TrackMessageSizeFilter/param-
  value
  /init-param
  
  Did you add that?
  
  Best regards,
  Emond
  
  On Tuesday 08 January 2013 23:52:40 Pierre Goupil wrote:
   Good evening,
   
   Which version of the atmosphere runtime am I supposed to use with
   wicket-atmosphere?
   
   In my app, when I use atmosphere 1.0.0 everything works, but when I use
   atmosphere 1.0.4 or 1.0.5, no Comet channel works. I use
  
  wicket-atmosphere
  
   0.7-SNAPSHOT.
   
   Regards,
   
   Pierre

Re: [wicket-atmosphere] atmosphere version

[Emond Papegaaij]

That's good to hear. I totally forgot about that option. It was added some
time ago and is indeed needed for Wicket. Without it the behavior does not
work because it is stateful.

Best regards,
Emond
Op 11 jan. 2013 19:01 schreef Pierre Goupil goupilpie...@gmail.com het
volgende:

 I've found it! I had a HttpSession supported: false in my start-up Tomcat
 logs when using Atmosphere 1.0.5. I don't know why, but I assume it's a
 default behaviour change because when using Atmosphere 1.0.0 and changing
 nothing else, I had: HttpSession supported: true. So I've followed
 instructions on this page:

 https://github.com/Atmosphere/atmosphere/wiki/Enabling-HttpSession-Supportand
 it works like a charm!

 Cheers, men!

 Pierre


 On Fri, Jan 11, 2013 at 5:22 PM, Emond Papegaaij 
 emond.papega...@topicus.nl
  wrote:

  Yes, it should work with any 1.0 version. I think you should try to
 verify
  the
  AJAX-messges, perhaps with Wicket's AJAX-debugger.
 
  Best regards,
  Emond
 
  On Friday 11 January 2013 17:06:09 Pierre Goupil wrote:
   Sure! But it doesn't help. And as I said, there is no error in my logs,
   neither client-side nor server-side.
  
   As I understand things, it should work with any version of Atmosphere
   starting from 1.0.0, right?
  
   Do you have any clue?
  
   Regards,
  
   Pierre
  
  
  
  
   On Thu, Jan 10, 2013 at 1:07 PM, Emond Papegaaij 
  emond.papega...@topicus.nl
wrote:
   
With recent versions of wicket-atmosphere, you are required to add
 this
parameter to the AtmosphereServlet:
init-param
   
   
  param-nameorg.atmosphere.cpr.broadcastFilterClasses/param-name
   
   
  param-valueorg.apache.wicket.atmosphere.TrackMessageSizeFilter/param-
value
/init-param
   
Did you add that?
   
Best regards,
Emond
   
On Tuesday 08 January 2013 23:52:40 Pierre Goupil wrote:
 Good evening,

 Which version of the atmosphere runtime am I supposed to use with
 wicket-atmosphere?

 In my app, when I use atmosphere 1.0.0 everything works, but when I
  use
 atmosphere 1.0.4 or 1.0.5, no Comet channel works. I use
   
wicket-atmosphere
   
 0.7-SNAPSHOT.

 Regards,

 Pierre
 



 --
 Parce que c'est la nuit qu'il est beau de croire à la lumière.

 Edmond Rostand

Re: [wicket-atmosphere] resource UUID

[Emond Papegaaij]

I don't see why this piece of code would be needed. You are creating a new 
broadcaster for every resource, that doesn't sound like a good idea. Perhaps 
someone at the Atmosphere Google groups can help you with this. It might be 
that something is wrong with the Broadcaster.broadcast(String, Resource) 
method.

Best regards,
Emond

On Wednesday 30 January 2013 21:33:21 Pierre Goupil wrote:
 Good evening,
 
 I managed to have it work, at long last. What happened is that in the
 quickstart I provided, I issued a EventBus.get().post(event, pageUuid) and
 it worked as expected: I was able to post an event to only one client of my
 choice.
 
 Unfortunately, in my project, which makes heavy use of Comet / WebSockets,
 it didn't work, and with the same EventBus code! But my code and component
 tree are far more complex in my project, so this is not entirely a surprise.
 
 Nonetheless, I modified the EventBus#post(AtmosphereResource resource,
 PageKey pageKey, CollectionEventSubscription subscriptionsForPage, Object
 event) to: EventBus#post(AtmosphereResource resource, PageKey pageKey,
 CollectionEventSubscription subscriptionsForPage, Object event,, String
 resourceUuid ).
 
 And I added this small piece of code:
 
 if (application.createRequestCycle(request,
 response).processRequestAndDetach())
 {
 Broadcaster singleBroadcaster =
 BroadcasterFactory.getDefault().lookup(
 DefaultBroadcaster.class, resourceUuid, true);
 singleBroadcaster.setID(resourceUuid);
 resource.setBroadcaster(singleBroadcaster);
 singleBroadcaster.addAtmosphereResource(resource);
 singleBroadcaster.broadcast(response.toString());
 }
 
 And it does work!
 
 What shall I do, now? Open a Jira ticket? Issue a pull-request? Or just let
 you introduce this tiny bit of code?
 
 Thanks for the good, hard work!
 
 Regards,
 
 Pierre Goupil
 
 
 On Thu, Jan 10, 2013 at 4:22 PM, Emond Papegaaij emond.papega...@topicus.nl
  wrote:
  
  You should register it with EventBus.addRegistrationListener and a page
  should
  not implement the interface, it is meant as an application global
  listener.
  
  Emond
  
  On Thursday 10 January 2013 15:50:12 Pierre Goupil wrote:
   Indeed. I've tried this in my page constructor:
   
   Application.get().getEventBus().registerPage(hp + UUID.randomUUID(),
   this);
   
   But it doesn't do the trick. Sorry to bug you, but I can't find the
   right
   method!
   
   Regards,
   
   Pierre
   
   On Thu, Jan 10, 2013 at 3:30 PM, Martin Grigorov
  
  mgrigo...@apache.orgwrote:
You have to register it in the EventBus


On Thu, Jan 10, 2013 at 4:27 PM, Pierre Goupil goupilpie...@gmail.com

wrote:
 Hi Emond,
 
 I must be doing something wrong, as it doesn't work. I have
  
  implemented
  
 ResourceRegistrationListener in my HomePage and I set the UUIDs in
  
  the
  
 method resourceRegistered() but my logs show that it's never called.
 
 Is there any more than implementing ResourceRegistrationListener
 that
 I'm
 supposed to do?
 
 Regards,
 
 Pierre
 
 
 On Thu, Jan 10, 2013 at 1:05 PM, Emond Papegaaij 
 emond.papega...@topicus.nl
 
  wrote:
  
  I've just pushed the fix for WICKET-4957: you can now listen to
  the
  registration of resources for pages.
  
  Best regards,
  Emond
  
  On Tuesday 08 January 2013 23:49:36 Pierre Goupil wrote:
   Emond,
   
   I've tried it like you said and it almost works! It works in the

sense

  that
  
   I'm able to send an event to only one resource : that alone is
  
  fine
  
in

   itself.
  
   But unfortunately, when doing:
  broadcaster.getAtmosphereResources()
  
   I
  
  don't
  
   know which browser corresponds to which resource. So I
  
  definitively
  
 need
 
   your functionality of resource creation listening.
   
   Keep up the good work!
   
   Cheers,
   
   Pierre
   
   On Tue, Jan 8, 2013 at 2:07 PM, Pierre Goupil 

goupilpie...@gmail.com

  wrote:
Excellent, Emond! I'll try it like you said and tell you what
 
 happens.
 
Cheers,

Pierre


On Tue, Jan 8, 2013 at 1:55 PM, Emond Papegaaij 

emond.papega...@topicus.nl wrote:
Hi Pierre,

The UUID is bound to a page when atmosphere makes to call
  
  back to
  
 the
 
server,
which makes sense because before then, there is no
 
 AtmosphereResource,
 
which
means there cannot be a UUID. I think this is a bit of a
  
  design
  
 flaw,
 
because
it is not possible to listen to the registration of this
uuid.

I'll

  see
  
if I

Re: Another Wicket 6 migration issue: drag and drop (so far done with wiquery)

[Emond Papegaaij]

DroppableBehavior is the replacement of DroppableAjaxBehavior. You use it
like this:

final DroppableBehavior droppableBehavior = new DroppableBehavior();
droppableBehavior.setDropEvent( new AjaxDropCallback() {
protected void drop(AjaxRequestTarget target, Component source,
Component dropped) {
// [...]
}
} );
droppableBehavior.setAccept( new DroppableAccept( .fileItem ) );
droppableBehavior.setHoverClass( dropHover );
add( droppableBehavior );

Best regards,
Emond


On Fri, Feb 15, 2013 at 2:20 PM, Martin Dietze d...@fh-wedel.de wrote:

 Another thing I am stuck trying to port my project from Wicket
 1.4.x to 6.6.0 is DND-mechanics which so far had been
 implemented using wiquery 1.2.

 As I see the 'DroppableAjaxBehavior' class has disappeared from
 wiquery since the 6.0 release. However no mention could be found
 on either migration pages or mailing lists.

 So far DND had been implemented like this:

 | final DroppableAjaxBehavior droppableBehavior = new
 DroppableAjaxBehaviorItemFoo() {
 | @Override
 | public void onDrop( ItemFoo item, AjaxRequestTarget target ) {
 |   // [...]
 | }
 | };
 | droppableBehaviour.getDroppableBehavior().setAccept( new
 DroppableAccept( .fileItem ) );
 | droppableBehaviour.getDroppableBehavior().setHoverClass( dropHover );
 | add( droppableBehaviour );

 Now as there's no DroppableAjaxBehavior anymore and no hint on
 what replaced it I'm lost. I found a DroppableBehavior coming with
 wiquery 6.2.0, but I can't see how this could be a simple
 replacement, and to make things worse, there does not seem to be
 any sample code for 6.2.0-based DND around.

 Any hints?

 Cheers,

 M'bert

 --
 --- / http://herbert.the-little-red-haired-girl.org /
 -
 =+=
 WE ARE THE BORG - RESISTANCE IS VOLTAGE DIVIDED BY CURRENT!

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

Re: [wicket-atmosphere] Spring Security context while rendering subscribed components

[Emond Papegaaij]

Hi,

I'm sorry for the late reply, but I haven't been well last week.
Wicket-atmosphere follows the wicket request cycle. Perhaps you can add a
RequestCycleListener to setup the context? Keep in mind though that this
listener is also called for normal requests. Let me know if this is ok for
you. Another solution would be to add another listener system, but I think
it's better to try to use existing systems before adding another wheel.

Best regards,
Emond
Op 8 mrt. 2013 14:31 schreef Andrei Badea andrei.ba...@movzx.net het
volgende:

 Our Wicket application uses Spring Security for authentication and
 authorization. All service methods check that the current user (in the
 Spring Security context) has the right to execute the method.

 When the subscribed components are rendered for an Atmosphere broadcast,
 the security context is not the right one. We call EventBus.post() in a
 background (non-HTTP) thread, so there is no security context at all (and
 even if it were, its user would not be the right one).

 I can use ResourceRegistrationListener to keep track of the
 resource-UUID-to-user assignment, but I see no way to set the user into the
 security context before the subscribed components are rendered. Is there
 one? If not, it is conceivable to add one, such as some sort of hook to
 EventBus.post()? The security context would ideally be set around
 postToSingleResource(), and it must be reset after all resources have been
 handled.

 Thank you,

 Andrei


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

Re: wicket-atmosphere issues

[Emond Papegaaij]

On Monday 25 March 2013 00:59:30 Leonid Bogdanov wrote:
 Hello!
 
 I'm playing with the wicket-atmosphere module and, while generally it
 works fine, I stumbled upon a couple of issues:
 
 1) Suppose I have a Page with a method marked with @Subscribe
 annotation, this subscribtion has a filter attached. Is it possible to get
 the Page instance inside the filter to, e.g., access Page instance
 variables when deciding on event filtering?

Filtering is performed outside the scope of the pages. Fetching pages from the 
page store is very expensive, especially if you are going to push events to 
many pages. I suggest you put data you need for filtering in the atmosphere 
resource, which is available in the filter. If that's not possible, you can 
try a contextAwareFilter, but beware of the performance issues.

 2) It seems like sometimes empty Atmosphere messages are sent to a page
 when a filter rejected the specific message. For such events I have the
 following log record on the server [Atmosphere-AsyncWrite-1] INFO 
 o.a.w.atmosphere.AtmosphereBehavior - onBroadcast: 0|msg| and there is a
 JS error in a browser after receiveing the event
 ERROR: Wicket.Ajax.Call.failure: Error while parsing response: Could not
 find root ajax-response element What is the purpose of sending empty
 messages to a browser?

This seems like a bug. Please file a bug report with a quickstart. You can use 
https://github.com/papegaaij/wicket-atmosphere-quickstart as a starting point.

 3) In my app Apache Shiro framework is integrated via a plugin adapted
 from fiftyfive-wicket-shiro project. User credentials are checked in an
 AJAX login form. In order to prevent a session fixation attack there is a
 call to invalidate old and create new session right before credentials
 check: getSession().replaceSession(); // inside
 AjaxFallbackButton.onSubmit() After integration with Atmosphere this code
 no longer works, an exception in thrown on login attempt:
 
cut IllegalStateException in Session
I'm not sure what happens here. It seems Wicket tries to read an attribute 
from the invalidated session. Does this happen even without a suspended 
connected?

Best regards,
Emond

Re: wicket-atmosphere EventBus.post throwing Null pointer exception sometime

[Emond Papegaaij]

Hi,

I suggest you try upgrading wicket, wicket-atmosphere and atmosphere to 
more recent versions first. The version of wicket-atmosphere you are using 
is almost a year old. The most recent version is 0.12. Several bugs have 
been fixed since then.

Best regards,
Emond

On Friday 09 August 2013 14:04:36 souvikbhattacharyas wrote:
 Hi,
Recently I am stuck with problem of Wicket-atmosphere and it seems 
to be
 very strange to me.
 In my application, I am publishing data through Hazelcast and after
 HazelCast receives data, it uses wicket atmosphere's EventBus.post() 
method
 to push the data and then methods with @subscribe annotation 
receives the
 same and process. Now it's working fine but sometime it's giving 
nullpointer
 exception. There is no proper scenario when EventBus.post() will 
through
 null pointer exception but suddenly it's giving nullpointer exception for
 few EventBus.post() and after few exception EventBus.post() again start
 working. This become very strange thing to me now. I am giving all the 
code
 below. Please help me to identify the issue why I am getting the error.
 
 *hazelcast.verison = 2.2
 wicket-atmosphere.version = 0.5
 atmosphere.version = 1.0.4*
 
 *Web.xml*
 
 servlet
 servlet-namewicket/servlet-name
 
 servlet-classorg.atmosphere.cpr.AtmosphereServlet/servlet-class
 init-param
 param-nameapplicationClassName/param-name
 param-valueWebPortal/param-value
 /init-param
 init-param
 param-namelistings/param-name
 param-valuefalse/param-value
 /init-param
 init-param
 param-nameconfiguration/param-name
 param-valuedeployment/param-value
 /init-param
 init-param
 param-nameorg.atmosphere.useWebSocket/param-
name
 param-valuefalse/param-value
 /init-param
 init-param
 param-nameorg.atmosphere.useNative/param-name
 param-valuetrue/param-value
 /init-param
 init-param
 param-nameorg.atmosphere.cpr.sessionSupport/param-
name
 param-valuetrue/param-value
 /init-param
 init-param
 param-namefilterMappingUrlPattern/param-name
 param-value/ssp/*/param-value
 /init-param
 init-param
 
 param-nameorg.atmosphere.cpr.broadcastFilterClasses/param-
name
 
 param-valueorg.atmosphere.client.TrackMessageSizeFilter/param-
value
 /init-param
 load-on-startup0/load-on-startup
 /servlet
 
 *atmosphere.xml*
 
 atmosphere-handlers
 atmosphere-handler context-root=/*
 class-
name=org.atmosphere.handler.ReflectorServletProcessor
 property name=filterClassName
 value=org.apache.wicket.protocol.http.WicketFilter /
 /atmosphere-handler
 /atmosphere-handlers
 
 *WebPortal object:*
 
 public class WebPortal extends AuthenticatedWebApplication {
 
 public WebPortal() {
 
 EventBus eventbus = new EventBus(this);
 HazelcastBroadcaster bc = (HazelcastBroadcaster)
 BroadcasterFactory.getDefault()
 .get(HazelcastBroadcaster.class, confEvnt);
 bc.setApplication(this);
 bc.getBroadcasterConfig().addFilter(new
 TrackMessageSizeFilter());
 bc.getBroadcasterConfig().setBroadcasterCache(new
 HeaderBroadcasterCache());
 }
 }
 
 *HazelcastBroadcaster*
 
 public class HazelcastBroadcaster extends AbstractBroadcasterProxy 
{
 
 private ITopic topic;
 private WebApplication application;
 private static HazelcastInstance hazelcastInstance =
 SspHazelcast.getInstance();
 
 public HazelcastBroadcaster(String id, AtmosphereConfig config) {
 this(id, URI.create(http://localhost:6379;), config);
}
 
 public HazelcastBroadcaster(String id, URI uri, AtmosphereConfig
 config) {
 super(id, uri, config);
 }
 
 @Override
 public void incomingBroadcast() {
 topic.addMessageListener(new MessageListenerString() {
 @Override
 public void onMessage(MessageString message) {

Re: wicket-atmosphere EventBus.post throwing Null pointer exception sometime

[Emond Papegaaij]

Hi,

As you can see in the ticket, we are unable to reproduce this problem. It is 
likely to be related to a particular way of using wicket-atmosphere. If you 
can provide us with a quickstart (you can clone the wicket-atmosphere-
quickstart project at 
https://github.com/papegaaij/wicket-atmosphere-quickstart), we can probably 
help you.

Best regards,
Emond

On Tuesday 13 August 2013 02:14:12 souvikbhattacharyas wrote:
 HI Emond,
Thanks for your reply. We have updated all the jar's but no luck. What 
we
 found is the error is related to
 https://issues.apache.org/jira/browse/WICKET-5282 . So, this is not a
 atmosphere error rather error in wicket component. Is any wayout to 
solve
 the issue
 
 
 
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/wicket-atmosphere-EventBus-post- 
 throwing-Null-pointer-exception-sometime-tp4660815p4660862.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: wicket-atmosphere EventBus.post throwing Null pointer exception sometime

[Emond Papegaaij]

As you can see in the web.xml, the WicketFilter runs under /app. You can 
start it in jetty using the maven jetty plugin: mvn jetty:run (which will make 
the application available under localhost:8080/app)

On Tuesday 13 August 2013 03:21:20 souvikbhattacharyas wrote:
 Hi,
 I have compiled the mentioned application and deployed in the glassfish
 server. But what is the url to run the same and also let me know how to 
run
 it on Jetty.
 
 
 
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/wicket-atmosphere-EventBus-post- 
 throwing-Null-pointer-exception-sometime-tp4660815p4660865.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: [OT] thanks

[Emond Papegaaij]

Hi Pierre,

Good to hear you like it! Unfortunately, we are still waiting for the rest of 
the server stack to support websockets before we can actually use it in 
production applications. Hopefully, with the release of jee7 (with jsr356) 
maintainers of httpd and ajp will finally realize they need to support 
websockets as well.

Best regards,
Emond

On Wednesday 14 August 2013 12:01:05 Pierre Goupil wrote:
 Good morning,
 
 All apologies for this totally off-topic message, but I would like to say a
 big THANK YOU to Emond for his work on wicket-atmosphere.
 
 His code is far from trivial, yet it is a real pleasure to use it.
 According to me, the killer-feature is the fact that we have an
 AjaxRequestTarget to work with which triggers a Comet / WebSocket 
response.
 
 Thanks again, man!
 
 Pierre

Re: [OT] thanks

[Emond Papegaaij]

We depend heavily on ajp. Our application server needs to know the exact 
url the request was made to. This is very hard to get right with plain http 
proxying (if not impossible). The main reason we use httpd in front of our 
application server(s) is for load balancing and status information (serving 
a 503 when the application is down). Tomcat's (or JBoss in our case) 
performance has never been an issue.

Best regards,
Emond

On Wednesday 14 August 2013 07:50:50 Dan Retzlaff wrote:
 Have you considered nginx? We use httpd but our reverse-proxying 
needs are
 pretty simple. I've been meaning to try nginx.
 
 http://nginx.org/en/docs/http/websocket.html
 
 On Wed, Aug 14, 2013 at 7:42 AM, Pierre Goupil 
goupilpie...@gmail.comwrote:
  I use only Tomcat (7.0.40) and I must admit that with NIO connector 
and
  useNative=true, the performance looks nice. I have no use for an 
httpd for
  the moment, but I'm not in production.
  
  I plan to load test my app, if you're interested, I can communicate the
  results to you.
  
  As a side-note, on the Tomcat list, many people are starting to talk 
about
  better WebSockets support in Tomcat 8 and the dev seem to realize 
that
  there is a strong expectation for them, so maybe they'll try and 
convince
  to work hand-in-hand with the httpd / AJP people?
  
  Anyway, thanks again and keep up the good work!
  
  And of course a big thank you to the people from the great Wicket, 
too!
  
  :-)
  
  Regards,
  
  Pierre
  
  
  On Wed, Aug 14, 2013 at 3:33 PM, Emond Papegaaij 
  emond.papega...@topicus.nl
  
   wrote:
   
   Hi Pierre,
   
   Good to hear you like it! Unfortunately, we are still waiting for the
  
  rest
  
   of
   the server stack to support websockets before we can actually use 
it in
   production applications. Hopefully, with the release of jee7 (with
  
  jsr356)
  
   maintainers of httpd and ajp will finally realize they need to support
   websockets as well.
   
   Best regards,
   Emond
   
   On Wednesday 14 August 2013 12:01:05 Pierre Goupil wrote:
Good morning,

All apologies for this totally off-topic message, but I would like to
   
   say a
   
big THANK YOU to Emond for his work on wicket-atmosphere.

His code is far from trivial, yet it is a real pleasure to use it.
According to me, the killer-feature is the fact that we have an
AjaxRequestTarget to work with which triggers a Comet / 
WebSocket
   
   response.
   
Thanks again, man!

Pierre
  
  --
  Un truc bien avec la musique, c'est que quand elle te frappe, tu n'as 
pas
  mal.
  Alors frappez-moi de musique !
  Frappez-moi de musique, maintenant !
  
  (Bob Marley : Trenchtown Rock)

Re: Wicket CDI Status

[Emond Papegaaij]

Hi Diogo,

Please note that wicket-cdi-1.1 is still experimental. I do have high
confidence it will work fine, but it has not been tested extensively. The
API is mostly compatible with the current wicket-cdi module. One of the
changes is that the constructor of the CdiConfiguration no longer takes a
BeanManager. CDI 1.1 has several portable ways of looking up this
BeanManager. A fallback is added (see CdiConfiguration), in case your
environment does not provide any of the portable lookup methods, but
Glassfish should. Also, it is no longer possible to disable injection of
various Wicket classes. Components, behaviors, sessions and the application
are always injected.

A major difference in behavior is the way conversations are propagated. The
current cdi module uses non-portable code (which only works with Weld) to
propagate the conversation. wicket-cdi-1.1 always propagates the
conversation via the url (with the cid query-parameter), which is portable
across all CDI 1.1 providers.

As Martin mentioned, wicket-cdi-1.1 requires a recent version of Weld (if
used with Weld). Weld 2.1.1 (which has not yet been released) has some
fixes regarding warning floods (https://issues.jboss.org/browse/WELD-1547).
Until then, you either have to ignore the warnings or lower the logging
level.

To use wicket-cdi-1.1, once wicket 6.13 is released, add the following
dependency:
dependency
  groupIdorg.apache.wicket/groupId
  artifactIdwicket-cdi-1.1/artifactId
  version0.2/version
/dependency

Until then, you can test with 0.2-SNAPSHOT. You can find the details for
the snapshot repository on our download page.

If you find any issues with wicket-cdi-1.1, please file JIRA issues and
assign them to me.

Best regards,
Emond Papegaaij


On Wed, Dec 4, 2013 at 7:02 PM, Diogo Casado diogocas...@gmail.com wrote:

 It looks like it is running with glassfish4 snapshot 4.1 b4m1.
 They use the latest version of weld on it.
 Well.. I will continue this way..
 Do you have an idea on when we will have v6.13 with cdi1.1?
 Thank you very much.

 On Wed, Dec 4, 2013 at 2:07 PM, Martin Grigorov mgrigo...@apache.org
 wrote:
  Hi,
 
  I am not very into CDI business but here are some solutions:
  - upgrade Weld to 2.1.0 in Glassfish 4, if this is possible. The
 exception
  is caused by a bug in Weld 2.0.x
  - use Wicket 6.9.0. This will work unless you use @Inject in anonymous
  Wicket components. I personally never thought about this pattern before
  Wicket 6.9.1. I guess you don't use it too
  - Wicket 6.13.0 will bring wicket-cdi-1.1 module. But again it will work
  only if you use it with Weld 2.1.x
 
 
  On Wed, Dec 4, 2013 at 5:01 PM, Diogo Casado diogocas...@gmail.com
 wrote:
 
  Hello guys..
 
  I'm setting up a Glassfish4 environment with wicket 6.12.0 and I
  previously started using cdi to inject entity managers.
  On Tomee, cdi was working but I decided that this particular
  application will need a more robust JavaEE server (specially because
  of OpenJPA slow pace).
 
  Anyway.. I'm getting warnings everywhere and specially this exception
  that just broke the app:
  WELD-70 Simple bean [EnhancedAnnotatedTypeImpl]  class
  comLoginPage$1 cannot be a non-static inner class
 
  The offending class is basically a anonymous Form.. I conclude that
  any anonymous class would cause this.
 
  Found this ticket: https://issues.apache.org/jira/browse/WICKET-5264
  I guess it happened before and was fixed in v6.9.0 but I'm still
  facing this issue with v6.12.0.
 
  So basically.. what's the best option:
  - Apply some fix to this situation;
  - Stick with a JavaEE6 with Glassfish3 while using v6.x + cdi and in
  near future go for JavaEE7 Glassfish4 + Wicket v7.x  cdi 1.1 (when
  ready)
  - Should I forget cdi =\
 
  I appreciate guidance.
 
  Thanks.
 
  -
  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: Wicket CDI Status

[Emond Papegaaij]

The new module should be fully functional, including all scopes. The
performance should be much better than with the old module, due to
InjectionTarget caching. The biggest changes are in conversation
propagation. If you do not use the conversation scope, the transition to
the new module should be very smooth.

Best regards,
Emond
Op 5 dec. 2013 20:24 schreef Diogo Casado diogocas...@gmail.com:

 Thanks Emond,

 I will watch the progress and report back.
 For now.. I'm ignoring the warnings and using a snapshot from glassfish.
 I'm using CDI just for EntityManager injection..and it's just
 RequestScoped.
 So.. from what I saw in the current version, the biggest problem would
 be if it was context oriented.

 Regards,
 Diogo C.


 On Wed, Dec 4, 2013 at 7:01 PM, Emond Papegaaij
 emond.papega...@gmail.com wrote:
  Hi Diogo,
 
  Please note that wicket-cdi-1.1 is still experimental. I do have high
  confidence it will work fine, but it has not been tested extensively. The
  API is mostly compatible with the current wicket-cdi module. One of the
  changes is that the constructor of the CdiConfiguration no longer takes a
  BeanManager. CDI 1.1 has several portable ways of looking up this
  BeanManager. A fallback is added (see CdiConfiguration), in case your
  environment does not provide any of the portable lookup methods, but
  Glassfish should. Also, it is no longer possible to disable injection of
  various Wicket classes. Components, behaviors, sessions and the
 application
  are always injected.
 
  A major difference in behavior is the way conversations are propagated.
 The
  current cdi module uses non-portable code (which only works with Weld) to
  propagate the conversation. wicket-cdi-1.1 always propagates the
  conversation via the url (with the cid query-parameter), which is
 portable
  across all CDI 1.1 providers.
 
  As Martin mentioned, wicket-cdi-1.1 requires a recent version of Weld (if
  used with Weld). Weld 2.1.1 (which has not yet been released) has some
  fixes regarding warning floods (
 https://issues.jboss.org/browse/WELD-1547).
  Until then, you either have to ignore the warnings or lower the logging
  level.
 
  To use wicket-cdi-1.1, once wicket 6.13 is released, add the following
  dependency:
  dependency
groupIdorg.apache.wicket/groupId
artifactIdwicket-cdi-1.1/artifactId
version0.2/version
  /dependency
 
  Until then, you can test with 0.2-SNAPSHOT. You can find the details for
  the snapshot repository on our download page.
 
  If you find any issues with wicket-cdi-1.1, please file JIRA issues and
  assign them to me.
 
  Best regards,
  Emond Papegaaij
 
 
  On Wed, Dec 4, 2013 at 7:02 PM, Diogo Casado diogocas...@gmail.com
 wrote:
 
  It looks like it is running with glassfish4 snapshot 4.1 b4m1.
  They use the latest version of weld on it.
  Well.. I will continue this way..
  Do you have an idea on when we will have v6.13 with cdi1.1?
  Thank you very much.
 
  On Wed, Dec 4, 2013 at 2:07 PM, Martin Grigorov mgrigo...@apache.org
  wrote:
   Hi,
  
   I am not very into CDI business but here are some solutions:
   - upgrade Weld to 2.1.0 in Glassfish 4, if this is possible. The
  exception
   is caused by a bug in Weld 2.0.x
   - use Wicket 6.9.0. This will work unless you use @Inject in anonymous
   Wicket components. I personally never thought about this pattern
 before
   Wicket 6.9.1. I guess you don't use it too
   - Wicket 6.13.0 will bring wicket-cdi-1.1 module. But again it will
 work
   only if you use it with Weld 2.1.x
  
  
   On Wed, Dec 4, 2013 at 5:01 PM, Diogo Casado diogocas...@gmail.com
  wrote:
  
   Hello guys..
  
   I'm setting up a Glassfish4 environment with wicket 6.12.0 and I
   previously started using cdi to inject entity managers.
   On Tomee, cdi was working but I decided that this particular
   application will need a more robust JavaEE server (specially because
   of OpenJPA slow pace).
  
   Anyway.. I'm getting warnings everywhere and specially this exception
   that just broke the app:
   WELD-70 Simple bean [EnhancedAnnotatedTypeImpl]  class
   comLoginPage$1 cannot be a non-static inner class
  
   The offending class is basically a anonymous Form.. I conclude that
   any anonymous class would cause this.
  
   Found this ticket: https://issues.apache.org/jira/browse/WICKET-5264
   I guess it happened before and was fixed in v6.9.0 but I'm still
   facing this issue with v6.12.0.
  
   So basically.. what's the best option:
   - Apply some fix to this situation;
   - Stick with a JavaEE6 with Glassfish3 while using v6.x + cdi and in
   near future go for JavaEE7 Glassfish4 + Wicket v7.x  cdi 1.1 (when
   ready)
   - Should I forget cdi =\
  
   I appreciate guidance.
  
   Thanks.
  
   -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket CDI Status

[Emond Papegaaij]

Hi Diogo,

It already is:
https://github.com/apache/wicket/blob/wicket-6.x/wicket-experimental/wicket-cdi-1.1/pom.xml#L45

There are no dependencies on weld packages, as wicket-cdi-1.1 is fully 
portable. It only has a testing dependency on cdi-unit, which depends on 
weld.

Emond

On Tuesday 10 December 2013 09:07:52 Diogo Casado wrote:
 Edmond,
 
 Please when you assembly the package for the new CDI version, use
 scope provided for javax.* and org.jboss.* dependencies.
 I'm fixing the plumbing of my project and several undesired packages
 are being assembled because of current wicket-cdi.
 Thank you for your efforts!
 
 - Diogo
 
 On Thu, Dec 5, 2013 at 6:09 PM, Emond Papegaaij
 
 emond.papega...@gmail.com wrote:
  The new module should be fully functional, including all scopes. The
  performance should be much better than with the old module, due to
  InjectionTarget caching. The biggest changes are in conversation
  propagation. If you do not use the conversation scope, the transition 
to
  the new module should be very smooth.
  
  Best regards,
  Emond
  
  Op 5 dec. 2013 20:24 schreef Diogo Casado 
diogocas...@gmail.com:
  Thanks Emond,
  
  I will watch the progress and report back.
  For now.. I'm ignoring the warnings and using a snapshot from 
glassfish.
  I'm using CDI just for EntityManager injection..and it's just
  RequestScoped.
  So.. from what I saw in the current version, the biggest problem 
would
  be if it was context oriented.
  
  Regards,
  Diogo C.
  
  
  On Wed, Dec 4, 2013 at 7:01 PM, Emond Papegaaij
  
  emond.papega...@gmail.com wrote:
   Hi Diogo,
   
   Please note that wicket-cdi-1.1 is still experimental. I do have high
   confidence it will work fine, but it has not been tested extensively.
   The
   API is mostly compatible with the current wicket-cdi module. One of 
the
   changes is that the constructor of the CdiConfiguration no longer 
takes
   a
   BeanManager. CDI 1.1 has several portable ways of looking up this
   BeanManager. A fallback is added (see CdiConfiguration), in case 
your
   environment does not provide any of the portable lookup 
methods, but
   Glassfish should. Also, it is no longer possible to disable injection
   of
   various Wicket classes. Components, behaviors, sessions and the
  
  application
  
   are always injected.
   
   A major difference in behavior is the way conversations are 
propagated.
  
  The
  
   current cdi module uses non-portable code (which only works with 
Weld)
   to
   propagate the conversation. wicket-cdi-1.1 always propagates the
   conversation via the url (with the cid query-parameter), which is
  
  portable
  
   across all CDI 1.1 providers.
   
   As Martin mentioned, wicket-cdi-1.1 requires a recent version of 
Weld
   (if
   used with Weld). Weld 2.1.1 (which has not yet been released) has 
some
   fixes regarding warning floods (
  
  https://issues.jboss.org/browse/WELD-1547).
  
   Until then, you either have to ignore the warnings or lower the 
logging
   level.
   
   To use wicket-cdi-1.1, once wicket 6.13 is released, add the 
following
   dependency:
   dependency
   
 groupIdorg.apache.wicket/groupId
 artifactIdwicket-cdi-1.1/artifactId
 version0.2/version
   
   /dependency
   
   Until then, you can test with 0.2-SNAPSHOT. You can find the 
details
   for
   the snapshot repository on our download page.
   
   If you find any issues with wicket-cdi-1.1, please file JIRA issues and
   assign them to me.
   
   Best regards,
   Emond Papegaaij
   
   
   On Wed, Dec 4, 2013 at 7:02 PM, Diogo Casado 
diogocas...@gmail.com
  
  wrote:

Re: Wicket CDI 1.1

[Emond Papegaaij]

Did you migrate to wicket-cdi-1.1? To inject a non-managed class, use
NonContextual.of(MyClass.class).inject(instance). Components, however, are
injected by wicket-cdi itself. You should not need to inject those manually.

Best regards,
Emond
Op 4 apr. 2014 20:54 schreef David Beer david.m.b...@gmail.com:

 Hi All

 I am in the process of moving my application to JavaEE7 and CDI 1.1. Things
 are going well all except for some CDI values. I have an @Stateless Session
 bean used for my DAO which I then Inject into various classes. The issue I
 have is that some of the classes don't get the reference Injected properly
 and give a NPE. With wicket CDI I was able to call
 CdiContainer.get().getNonContextualManager().inject(this); to Inject the
 reference properly.

 I know CDI 1.1 is different but I can't work out how to Inject the
 Component with Wicket CDI 1.1?

 Here is the code in my WicketApplication init():

  new CdiConfiguration().setPropagation(NONE).configure(this);

 Thanks

 David

Re: Wicket atmosphere

[Emond Papegaaij]

Hi Duto,

I've just pushed the upgrade to the latest version of Atmosphere to the 
wicket-6.x and master branches. It should be in the next release of wicket-
atmosphere for both versions. I've also changed the 
TrackMessageSizeFilter to extend the atmosphere class.

Best regards,
Emond

On Monday 05 May 2014 14:08:20 Olivier Dutrieux wrote:
 Could you please update the wicket-atmosphere with the last release 
2.1.4 :
 I know that this version depend of jquery 2.0.3+ but there is a pure
 javascript version (no jquery depend) :
 
 https://github.com/Atmosphere/atmosphere-javascript
 
 And I notice that's your version of TrackMessageSizeFilter don't extend 
the
 org.atmosphere.client.TrackMessageSizeFilter but it's necessary to be 
use
 everywhere my atmosphere : check line 72 of this JavaScriptProtocol file 
for
 why :
 
 https://github.com/Atmosphere/atmosphere/blob/atmosphere-project-2.1.4/modul
 
es/cpr/src/main/java/org/atmosphere/interceptor/JavaScriptProtocol.java#L
72
 
 I can pull a request if you want.
 
 Duto
 
 -
 Duto
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Wicket-atmosphere-tp4665687.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: Wicket atmosphere

[Emond Papegaaij]

I replied to your mail already, but it seems my message was lost in the mail 
outage. Atmosphere and the JS are upgraded on the wicket-6.x and 
master branches. I've also fixed the filter.

https://issues.apache.org/jira/browse/WICKET-5589

Best regards,
Emond

On Monday 05 May 2014 14:08:20 Olivier Dutrieux wrote:
 Could you please update the wicket-atmosphere with the last release 
2.1.4 :
 I know that this version depend of jquery 2.0.3+ but there is a pure
 javascript version (no jquery depend) :
 
 https://github.com/Atmosphere/atmosphere-javascript
 
 And I notice that's your version of TrackMessageSizeFilter don't extend 
the
 org.atmosphere.client.TrackMessageSizeFilter but it's necessary to be 
use
 everywhere my atmosphere : check line 72 of this JavaScriptProtocol file 
for
 why :
 
 https://github.com/Atmosphere/atmosphere/blob/atmosphere-project-2.1.4/modul
 
es/cpr/src/main/java/org/atmosphere/interceptor/JavaScriptProtocol.java#L
72
 
 I can pull a request if you want.
 
 Duto
 
 -
 Duto
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Wicket-atmosphere-tp4665687.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: Wicket atmosphere

[Emond Papegaaij]

Could you create a JIRA issue for this, so we (and other users) can track
this issue? A short sample is not needed, because I can see in the code
that this can indeed go wrong. I'll make sure this gets fixed in the next
version.

Best regards,
Emond


On Sat, May 17, 2014 at 3:59 PM, Olivier Dutrieux 
olivier.dutri...@pasteur.fr wrote:

 Hello Emond,

 Very thanks to the update but I found a problem when I use long polling
 for the transport :

 When the EventBus loop to the list of AtmosphereResource (on post
 method) and if the update is too long of each AtmosphereResource, the
 list of AtmosphereResource is update and reorder (because atmosphere
 remove and registry the AtmosphereResource due to long polling) and then
 the loop on EventBus never stop and update is infinitie.

 To solve the probleme I do that on line 366 of EventBus.java :

 for (AtmosphereResource resource :
 ImmutableList.copyOf(broadcaster.getAtmosphereResources()))

 rather than

 for (AtmosphereResource resource : broadcaster.getAtmosphereResources())


 I can if you want attach I short sample.

 Duto


 Le 17/05/2014 01:22, Papegaaij [via Apache Wicket] a écrit :
  I replied to your mail already, but it seems my message was lost in
  the mail
  outage. Atmosphere and the JS are upgraded on the wicket-6.x and
  master branches. I've also fixed the filter.
 
  https://issues.apache.org/jira/browse/WICKET-5589
 
  Best regards,
  Emond
 
  On Monday 05 May 2014 14:08:20 Olivier Dutrieux wrote:
   Could you please update the wicket-atmosphere with the last release
  2.1.4 :
   I know that this version depend of jquery 2.0.3+ but there is a pure
   javascript version (no jquery depend) :
  
   https://github.com/Atmosphere/atmosphere-javascript
  
   And I notice that's your version of TrackMessageSizeFilter don't extend
  the
   org.atmosphere.client.TrackMessageSizeFilter but it's necessary to be
  use
   everywhere my atmosphere : check line 72 of this JavaScriptProtocol
  file
  for
   why :
  
  
 
 https://github.com/Atmosphere/atmosphere/blob/atmosphere-project-2.1.4/modul
  
  es/cpr/src/main/java/org/atmosphere/interceptor/JavaScriptProtocol.java#L
  72
 
  
   I can pull a request if you want.
  
   Duto
  
   -
   Duto
   --
   View this message in context:
  
 
 http://apache-wicket.1842946.n4.nabble.com/Wicket-atmosphere-tp4665687.html
   Sent from the Users forum mailing list archive at Nabble.com.
  
   -
   To unsubscribe, e-mail: [hidden email]
  /user/SendEmail.jtp?type=nodenode=4665902i=0
   For additional commands, e-mail: [hidden email]
  /user/SendEmail.jtp?type=nodenode=4665902i=1
 
 
 
  
  If you reply to this email, your message will be added to the
  discussion below:
 
 http://apache-wicket.1842946.n4.nabble.com/Wicket-atmosphere-tp4665687p4665902.html
 
  To unsubscribe from Wicket atmosphere, click here
  
 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=4665687code=b2xpdmllci5kdXRyaWV1eEBwYXN0ZXVyLmZyfDQ2NjU2ODd8LTExODI0MjM1MTg=
 .
  NAML
  
 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
 
 

 --
 Olivier Dutrieux
 Groupe Projets (Tél : 31 62)


 -
 Duto
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Wicket-atmosphere-tp4665687p4665909.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: Change in configuring AtmosphereServlet init-params

[Emond Papegaaij]

You are right. The filter allows the client to know the length of pushed 
messages. I believe it was also needed for very long messages. The problem 
with the default filter was, that the separator was far too common to use for 
wicket's Ajax responses and the default implementation did not offer a way to 
change the separator. This was fixed in recent versions of Atmosphere. In 
fact, changes to the API broke the old one, so I needed to replace it with the 
improved default.

Best regards,
Emond

On Sunday 11 January 2015 21:54:36 Martin Grigorov wrote:
 Only Emond knows the details ...
 AFAIK TrackMessageSizeFilter was needed to overcome a problem in Atmosphere
 + Wicket's XML response.
 It seems Atmosphere 2.20+ provides the solution by itself so Wicket's one
 is not needed anymore.
 
 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov
 
 On Fri, Jan 9, 2015 at 3:41 PM, Daniel Stoch daniel.st...@gmail.com wrote:
  On Fri, Jan 9, 2015 at 2:37 PM, Martin Grigorov mgrigo...@apache.org
  
  wrote:
   Hi,
   
   I think this changes was needed to upgrade from Atmosphere 2.18 to 2.22.
   AFAIK this change is needed by Atmosphere itself.
   Wicket-Atmosphere doesn't use these parameters.
  
  Ok, I know that. But how did you (or Emond ;)) know how to changed it,
  maybe I should look into Atmosphere documentation?
  The old TrackMessageSizeFilter comes from Wicket-Atmosphere, so there
  was some reason to setup such parameter.
  
  --
  Daniel
  
   Martin Grigorov
   Wicket Training and Consulting
   https://twitter.com/mtgrigorov
   
   On Fri, Jan 9, 2015 at 11:07 AM, Daniel Stoch daniel.st...@gmail.com
   
   wrote:
   Hi,
   
   In the most recent version of atmosphere-example the init-params were
   changed in servlet configuration (in web.xml).
   
   From:
   init-param
   
 param-nameorg.atmosphere.cpr.broadcastFilterClasses/param-name
  
  param-valueorg.apache.wicket.atmosphere.TrackMessageSizeFilter/param-va
  lue 
   /init-param
   
   To:
   init-param
   
 param-nameorg.atmosphere.cpr.AtmosphereInterceptor/param-name
  
  param-valueorg.atmosphere.client.TrackMessageSizeInterceptor/param-valu
  e 
   /init-param
   init-param
  
  param-nameorg.atmosphere.client.TrackMessageSizeInterceptor.delimiter/p
  aram-name 
 param-value![CDATA[|msg|]]/param-value
   
   /init-param
   
   What is the reason of this change, what these parameters are used for?
   Actual version does not work for me and I need to know how to debug
   this. Any tip will be helpful.
   
   --
   Best regards,
   Daniel
   
   -
   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


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

Re: Wicket CDI and Asynchronous (and Websockets)

[Emond Papegaaij]

Hi Sebastien,

I did not see any CDI related discussion on dev yet. What needs to be changed 
to wicket-cdi?

Best regards,
Emond

On Saturday 07 February 2015 21:57:11 Sebastien wrote:
 Dear all,
 
 I think I've now a full working version of my usecase: in EJB/@Asynchronous
 mode (stateless and stateful) and in CDI using Executors.
 It is not yet usable because it requires a change in wicket-cdi-1.1 which
 should be discussed in dev@.
 
 Anyhow, I would never be able to achieve it without the invaluable help of
 Martin I thank (once again) a lot!
 I also would like to say thank you to the few people that tried to solve
 this puzzle; I know there are because I saw fork(s) !..
 
 Best regards,
 Sebastien.
 
 On Fri, Feb 6, 2015 at 5:22 PM, Sebastien seb...@gmail.com wrote:
  Dear all,
  
  In a usecase I've explained in a recent discussion [1], I would like to
  enhance it a little to finally obtain:
  
  1/ An ajax button that launch 2/
  2/ A CDI injected EJB that executes an *asynchronous* time consuming
  operation
  3/ Getting back to the wicket side to complete the ajax operation.
  4/ A listener that has been provided to the EJB which, when events are
  fired, retrieve websockets information from the wicket Session (previously
  stored) and send a notification to the UI/user trough the websocket.
  
  For me, that's a very nice usecase: Imagine the user clicks on a button
  for a long running operation, then he continues using the site, navigate
  between pages etc... and is notified from time to time on the progress of
  the operation through websockets...
  
  I can make work either 3/ or 4/ but not both in conjunction, I get this
  (now famous) error:
  *There is no application attached to current thread EJB default*
  
  I unfortunately have to say I am not a CDI expert, and there is a lot of
  XxxScoped possible annotation, I tried all possible combination that would
  be logical IMO regarding the doc, read everything I could, but now I'm
  stuck... I am almost sure this is feasible, but maybe not as so easy as it
  seems
  
  I've prepared a concrete quickstart [2], it just need to be compiled and
  deployed in WidlyFly (JBoss 8), due to the websockets...
  
  I know I am asking for a real favor but I would be very thankful to the
  person(s) who would be able to make it work! I will leave the quickstart
  in
  my github's repo so any other user whiling to achieve the same usecase
  would already have a starting point...
  
  Thanks a lot in advance,
  Sebastien.
  
  [1]
  http://mail-archives.apache.org/mod_mbox/wicket-dev/201410.mbox/%3CCAAJwaY
  WCTTQDmu2pg3K=qyvgvhujgndaytjubc8sn+7fz-d...@mail.gmail.com%3E [2]
  https://github.com/sebfz1/wicket-quickstart-cdi-async


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

Re: wicket atmosphere broadcast to all except for orign page

[Emond Papegaaij]

The @Subscribe annotation has 2 filter options. In this case, I would go for 
the first: 'filter()'. The Predicate type you need to specify gets an 
AtmosphereEvent, where the payload is set to the object you are broadcasted. 
If you change this object to a little more than just a message, you can add 
the UUID from AtmosphereBehavior.getUUID(page) to this event. In the Predicate 
you can now check this UUID agains event.getResource().uuid(). If these match, 
you know the message is sent to the page that triggered the event and needs to 
be skipped (let the predicate return false).

Best regards,
Emond

On Monday 23 February 2015 14:14:47 fachhoch wrote:
 I  am trying to use wicket atmosphere,   I want  to broadcast msg for all
 the resources except  for the  one  which  broadcasted  the msg, please
 advice how to exclude   a  resource .
 
 In a  page on click of a link I call Event.get().post  and this same page
 has  a  public method with @org.apache.wicket.atmosphere.Subscribe
 annotation ,this method gets called  when  msg is broadcasted.  I want to
 broadcast msg to  all other sessions except  for  current session which
 broadcasted , please advice.
 
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/wicket-atmosphere-broadcast-to-a
 ll-except-for-orign-page-tp4669723.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: CsrfPreventionRequestCycleListener Link 400

[Emond Papegaaij]

Hi François,

Since 8.0.0-M2 (and 7.5.0) the CsrfPreventionRequestCycleListener will block 
requests without an Origin and Referer header. The reason for this is that is 
possible for an attacker to prevent a browser from sending a referer header 
(for example with rel="noreferrer"). When you open a link in a new tab, your 
browser probably does not send these headers and Wicket blocks the action-
request.

You can configure this behavior in CsrfPreventionRequestCycleListener with 
setNoOriginAction. As said, the default is 'ABORT'. If you set it to 
'SUPPRESS', Wicket will render the page, but not execute Link.onClick. This 
will open the new tab with the page containing the link. If you set it to 
'ALLOW', Wicket will allow the request, but this may undermine the protection 
offered by CsrfPreventionRequestCycleListener.

If your link simply points to a different page, I'd recommend to use a 
BookmarkablePageLink. A request to simply render a page will never be blocked 
by CsrfPreventionRequestCycleListener, so a BookmarkablePageLink will always 
work. Naturaly for this to work, your target page needs to be bookmarkable.

You can also subclass CsrfPreventionRequestCycleListener and override 
'protected boolean isChecked(IRequestHandler handler)' to whitelist specific 
requests. Perhaps you can tag safe links and skip checking those. This 
solution offers you the most flexibility, but requires more work and you need 
to be very precise in what requests to allow.

Best regards,
Emond


On zondag 13 november 2016 18:33:52 CET Francois Meillet wrote:
> Hi,
> 
> When I use a CsrfPreventionRequestCycleListener, clicking a Link<> while
> holding the command key does not open link in new tab. (Wicket 8.0.0-M2 /
> OSX)
> 
> I get this error :
> 
> HTTP ERROR 400
> Problem accessing /. Reason: Origin does not correspond to request
> 
> 
> Clicking a BookmarkablePageLink is ok.
> 
> 
> François
> 
> 
> -
> 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: Possible Issues with Page Store

[Emond Papegaaij]

Before you spend another day on troubleshooting again: check WICKET-6457. It's 
a regression caused by the fix for WICKET-6387 which will cause the pagestore 
to keep growing on some containers (like wildfly). It is fixed in 7.8.1 which 
is 
in the process of being released at this moment.

Emond

On donderdag 7 september 2017 11:45:19 CEST Brian Cullen wrote:
> As is the way with these things I find that this issue has already been
> addressed by WICKET-6387 and is fixed in Wicket 7.8.
 
> I wish I had found that earlier.
> 
> Brian.
> 
> 
> 
> -Original Message-
> From: Brian Cullen [mailto:brian.cul...@cdl.co.uk] 
> Sent: 07 September 2017 11:42
> To: 'users@wicket.apache.org' 
> Subject: Possible Issues with Page Store
> 
> Hello,
> 
> I'm working with Wicket 7.7 and have hit something I don't understand
> relating to how pages are written and retrieved from the DiskDataStore. I'm
> not sure if this is the correct list to post this but I would appreciate
> any assistance people can provide.
 
> Essentially the issue I'm having is that as part of the end of the request
> cycle the commitRequest method is called on the PageManager. This
> eventually translates to a call to storeTouchedPages on the
> PageStoreManager. As I understand it this method creates a session entry if
> necessary and then stores the page instances with it - this, by default,
> leads to the DiskDataStore saving each page asynchronously.
 
> The issue I have is where the setSessionAttributes method is called after
> storing the pages. This leads to the session attribute listeners being
> called. In this case the object is of type PageStoreManager$SessionEntry
> which clears the page store when the valueUnbound method is invoked on it.
> If you are using the default asynch page store then there is always a
> chance that the page will be stored after the setSessionAttributes method
> call clears the page store but there doesn't seem to be any guarantee of
> this - if it was a synchronous store it will never work as far as I can
> tell.
 
> Obviously this will only be an issue if the page isn't in the session cache
> for some reason but to my limited understanding of this area it doesn't
> seem like the functionality is correct. Can anyone advise, is this a bug or
> am I looking at this the wrong way?
 
> Finally, on a related point, when I was investigating this issue I noticed
> that the asynchronous flag of the application StoreSettings is never used.
> There is a check at DefaultPageManagerProvider:60 to make sure that the
> underlying data source can support asynchronous operation but I would have
> thought that the StoreSettings should also be checked as part of this if
> statement - is that the case?
 
> Regards,
> 
> Brian.
> 
> 
>  
> 
>  
> 
 
> 
> Please consider the environment - Do you really need to print this email?
> 
> This email is intended only for the person(s) named above and may contain
> private and confidential information. If it has come to you in error,
> please destroy and permanently delete any copy in your possession, and
> contact us on +44 (0)161 480 4420. The information in this email is
> copyright © CDL Group Holdings Limited. We cannot accept liability for any
> loss or damage sustained as a result of software viruses. It is your
> responsibility to carry out such virus checking as is necessary before
> opening any attachment.
 
> Cheshire Datasystems Limited uses software which automatically screens
> incoming emails for inappropriate content and attachments. If the software
> identifies such content or attachment, the email will be forwarded to our
> Technology department for checking. You should be aware that any email that
> you send to Cheshire Datasystems Limited is subject to this procedure.
> ---
> --- Cheshire Datasystems Limited, Strata House, Kings Reach Road, Stockport,
> SK4 2HD Registered in England and Wales with company number 3991057 VAT
> registration: 727 1188 33



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

Re: Performance issue (possible bug since 7.2.0…up to and including 8.0.0-M8)

[Emond Papegaaij]

Martin is right. It seems like you found a regression in the changes made for 
WICKET-6021. In general, the performance was increased by those changes, but 
evidently not in this case. Please create a JIRA issue and attach a quickstart 
that shows the problem. That should help us debug this regression.

Best regards,
Emond

On woensdag 13 december 2017 05:39:15 CET Martin Makundi wrote:
> Performance is no joking mantter =)
> 
> 2017-12-13 3:56 GMT+02:00 Lon Varscsak :
> > Haha, sure…I was sure someone was going to argue with me. :P
> > 
> > -Lon
> > 
> > On Tue, Dec 12, 2017 at 6:23 PM, Martin Makundi <
> > 
> > martin.maku...@koodaripalvelut.com> wrote:
> > > Good find! Sounds like a bug, file to jira?
> > > 
> > > 2017-12-12 23:38 GMT+02:00 Lon Varscsak :
> > > > Okay, so here's the situation, I have a component where an Ajax
> > > > request
> > > > displays a large table (1000ish rows).  It display fast, no problem,
> > 
> > not
> > 
> > > a
> > > 
> > > > great use of resources (not paginating), but ignore that for now.  I
> > 
> > then
> > 
> > > > have another Ajax request where I tell the wicket component to not be
> > > > visible and refresh an area.  No problem so far (although slightly
> > 
> > slow,
> > 
> > > > since it's not generating much html, should be faster).  Now EVERY
> > > > Ajax
> > > > request that updates the same area (with the component not in the
> > > > html)
> > > > takes a long time to respond (half second), even though it should be
> > > > returning in ms, because the html is pretty minimal.
> > > > 
> > > > I hooked it up to a profiler and found that it's spending a large
> > 
> > amount
> > 
> > > of
> > > 
> > > > CPU time in
> > > > MarkupContainer$MarkupChildIterator.refreshInternalIteratorIfNeeded().
> > > 
> > > I'm
> > > 
> > > > not sure why it would be traversing the component hierarchy of the
> > 
> > table
> > 
> > > > that's not even visible…but I don't know enough of the architecture of
> > > > wicket to really say…which is why I've come here. :)
> > > > 
> > > > I've gone back to 7.1.0 and can confirm that in that version this
> > > 
> > > "problem"
> > > 
> > > > does not exist.  The Ajax request is as fast as if I've never loaded
> > 
> > the
> > 
> > > > large table.
> > > > 
> > > > So I've attached a link to a Quickstart showing the problem (currently
> > > > configured for 8.0.0-M8, but can be complied down to 7.0.0).  When
> > > 
> > > loading
> > > 
> > > > the page, first click the refresh link…this will essentially refresh
> > 
> > all
> > 
> > > > the contents in an Ajax request and give you a sense of how fast it
> > > > _should_ be.  The table has not been visible yet, so there have been
> > > > no
> > > > ListView items created yet.  Then click "show table", this will
> > 
> > generate
> > 
> > > 2k
> > > 
> > > > dummy rows and redisplay the area.  It's obviously slower because it's
> > > > generating 350k of html (but surprisingly fast :P).  Then click hide
> > > > table.  It takes about the same amount of time to hide the table as it
> > > 
> > > does
> > > 
> > > > to show it, which is odd, because the html being regenerated is the
> > 
> > same
> > 
> > > as
> > > 
> > > > if there were no table displayed.  Then go ahead and click "refresh"
> > 
> > and
> > 
> > > > you'll see that refreshing a basically empty component is slow because
> > > 
> > > it's
> > > 
> > > > referencing all the components in the wicket hierarchy (
> > > > MarkupChildIterator.refreshInternalIteratorIfNeeded)even though
> > 
> > they're
> > 
> > > > not
> > > > visible.
> > > > 
> > > > Thoughts?  I recognize that the first response will be "don't display
> > > 
> > > 1000
> > > 
> > > > rows", but lets ignore that for now.
> > > > 
> > > > Thanks!
> > > > 
> > > > -Lon
> > > > 
> > > > Here's the link to the Quickstart:
> > > > https://www.dropbox.com/s/l0uxsibmh24nsoh/slownesstest.tar.gz?dl=0



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

Re: Release WiQuery for Wicket 8

[Emond Papegaaij]

Hi Thomas,

The easiest way is to just run 'mvn install' and depend on 8.0-SNAPSHOT. I did 
not do a release, as I cannot push to central. If you want to run your tests 
on some CI server, you probably have to push the artifacts to a local repo 
also.

Best regards,
Emond

On woensdag 6 juni 2018 11:36:54 CEST Thomas Heigl wrote:
> Hi Emond,
> 
> How can I test this? Did you do a milestone release or do I have to build
> from source and push to my local artifact repo?
> 
> Best,
> 
> Thomas
> 
> On Tue, Jun 5, 2018 at 3:01 PM, Emond Papegaaij 
> wrote:
> > I've just pushed a massive upgrade of all components. Removed all
> > deprecated
> > parts, upgraded jQuery UI to 1.12.1 and did some more cleanup and
> > refactoring.
> > Please test the changes in your project. The tests pass and the demo runs
> > fine, but my project only uses a limited set of the UI components.
> > 
> > Best regards,
> > Emond
> > 
> > On zaterdag 2 juni 2018 10:31:31 CEST you wrote:
> > > I'm planning to upgrade jQuery UI to the latest version next week. We
> > > are
> > > currently migrating all our applications to wicket 8 and also depend on
> > > wiquery quite a lot. It does however seem that jQuery UI is mostly dead.
> > > The rest of the world probably switched to yet another fancy JavaScript
> > 
> > ui
> > 
> > > library. At least the will make it easy to stay up to date with the
> > 
> > latest
> > 
> > > version :)
> > > 
> > > I can't push a release to central, but perhaps Martin can do that when
> > 
> > I'm
> > 
> > > done? For now you can use a snapshot build. It works, but the UI API
> > 
> > might
> > 
> > > change a bit before the 8.0 release.
> > > 
> > > Best regards,
> > > Emond Papegaaij
> > > 
> > > Op vr 1 jun. 2018 17:36 schreef Thomas Heigl :
> > > > Hi Ernesto,
> > > > 
> > > > I'm not sure how many people are still using it. But as I said, my
> > 
> > project
> > 
> > > > heavily depends on it.
> > > > 
> > > > @papegaaij has resolved all the compile errors against 8.0.0-M9 (
> > > > https://github.com/wicketstuff/wiquery) and a simple release of 8.0.0
> > > > would
> > > > be enough for me.
> > > > 
> > > > Best,
> > > > 
> > > > Thomas
> > > > 
> > > > On Fri, Jun 1, 2018 at 5:05 PM, Ernesto Reinaldo Barreiro <
> > > > 
> > > > reier...@gmail.com> wrote:
> > > > > Hi,
> > > > > 
> > > > > I do not know who is actually using this project. I use to
> > 
> > contribute to
> > 
> > > > it
> > > > 
> > > > > a few years ago. I haven't used it for ages..
> > > > > 
> > > > > On Fri, Jun 1, 2018 at 3:39 PM, Thomas Heigl 
> > > > 
> > > > wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Following the release of Wicket 8.0.0 and WicketStuff 8.0.0, could
> > > > > 
> > > > > somebody
> > > > > 
> > > > > > please cut a release of WiQuery compatible with the new version?
> > > > > > 
> > > > > > Our application still heavily relies on WiQuery and we can't move
> > 
> > to
> > 
> > > > > Wicket
> > > > > 
> > > > > > 8 without it.
> > > > > > 
> > > > > > Best,
> > > > > > 
> > > > > > Thomas
> > > > > 
> > > > > --
> > > > > Regards - Ernesto Reinaldo Barreiro
> > 
> > -
> > 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: Release WiQuery for Wicket 8

[Emond Papegaaij]

You are right, I still had the artifacts in my local repo. The old 
configuration did not build anymore due to changes in the jar-plugin. I'll 
look into it.

Emond

On woensdag 6 juni 2018 11:57:43 CEST Thomas Heigl wrote:
> The culprit is:
> 
> https://github.com/wicketstuff/wiquery/commit/0235691174ceeede22b588d2f67868
> b940d9be3a
> On Wed, Jun 6, 2018 at 11:51 AM, Thomas Heigl  wrote:
> > `mvn clean install` fails for me because no test-jar is built for the core
> > module:
> > 
> > [INFO] WiQuery Parent 8.0-SNAPSHOT  SUCCESS [
> > 
> >>  0.353 s]
> >> 
> >> [INFO] WiQuery Core Project ... SUCCESS [
> >> 
> >>  2.673 s]
> >> 
> >> [INFO] WiQuery jQuery UI Project .. FAILURE [
> >> 
> >>  0.023 s]
> >> 
> >> [INFO] WiQuery Demo Project 8.0-SNAPSHOT .. SKIPPED
> >> [INFO] 
> >> 
> >> [INFO] BUILD FAILURE
> >> [INFO] 
> >> 
> >> [INFO] Total time: 3.720 s
> >> [INFO] Finished at: 2018-06-06T11:48:16+02:00
> >> [INFO] 
> >> 
> >> [ERROR] Failed to execute goal on project wiquery-jquery-ui: Could not
> >> resolve dependencies for project org.wicketstuff.wiquery:
> >> wiquery-jquery-ui:jar:8.0-SNAPSHOT: Failure to find
> >> org.wicketstuff.wiquery:wiquery-core:jar:tests:8.0-SNAPSHOT in
> >> https://oss.sonatype.org/content/repositories/snapshots was cached in
> >> the local repository, resolution will not be reattempted until the update
> >> interval of sonatype-nexus-snapshots has elapsed or updates are forced ->
> >> [Help 1]
> >> [ERROR]
> > 
> > Did you change something about test-jar configuration? I do not see
> > `test-jar` generation enabled in the POM file.
> > 
> > On Wed, Jun 6, 2018 at 11:43 AM, Emond Papegaaij <
> > 
> > emond.papega...@topicus.nl> wrote:
> >> Hi Thomas,
> >> 
> >> The easiest way is to just run 'mvn install' and depend on 8.0-SNAPSHOT.
> >> I did
> >> not do a release, as I cannot push to central. If you want to run your
> >> tests
> >> on some CI server, you probably have to push the artifacts to a local
> >> repo
> >> also.
> >> 
> >> Best regards,
> >> Emond
> >> 
> >> On woensdag 6 juni 2018 11:36:54 CEST Thomas Heigl wrote:
> >> > Hi Emond,
> >> > 
> >> > How can I test this? Did you do a milestone release or do I have to
> >> 
> >> build
> >> 
> >> > from source and push to my local artifact repo?
> >> > 
> >> > Best,
> >> > 
> >> > Thomas
> >> > 
> >> > On Tue, Jun 5, 2018 at 3:01 PM, Emond Papegaaij <
> >> 
> >> emond.papega...@topicus.nl>
> >> 
> >> > wrote:
> >> > > I've just pushed a massive upgrade of all components. Removed all
> >> > > deprecated
> >> > > parts, upgraded jQuery UI to 1.12.1 and did some more cleanup and
> >> > > refactoring.
> >> > > Please test the changes in your project. The tests pass and the demo
> >> 
> >> runs
> >> 
> >> > > fine, but my project only uses a limited set of the UI components.
> >> > > 
> >> > > Best regards,
> >> > > Emond
> >> > > 
> >> > > On zaterdag 2 juni 2018 10:31:31 CEST you wrote:
> >> > > > I'm planning to upgrade jQuery UI to the latest version next week.
> >> 
> >> We
> >> 
> >> > > > are
> >> > > > currently migrating all our applications to wicket 8 and also
> >> 
> >> depend on
> >> 
> >> > > > wiquery quite a lot. It does however seem that jQuery UI is mostly
> >> 
> >> dead.
> >> 
> >> > > > The rest of the world probably switched to yet another fancy
> >> 
> >> JavaScript
> >> 
> >> > > ui
> >> > > 
> >> > > > library. At least the will make it easy to stay up to date with the
> >> > > 
> >> > > latest
> >> > > 
> >> > > > version :)
> &g

Re: Release WiQuery for Wicket 8

[Emond Papegaaij]

I've fixed the problem. The setup currently used is discouraged and broken in 
m2e, but I don't feel like restructuring the whole thing to get rid of this 
test-jar.

Emond

On woensdag 6 juni 2018 11:57:43 CEST Thomas Heigl wrote:
> The culprit is:
> 
> https://github.com/wicketstuff/wiquery/commit/0235691174ceeede22b588d2f67868
> b940d9be3a
> On Wed, Jun 6, 2018 at 11:51 AM, Thomas Heigl  wrote:
> > `mvn clean install` fails for me because no test-jar is built for the core
> > module:
> > 
> > [INFO] WiQuery Parent 8.0-SNAPSHOT  SUCCESS [
> > 
> >>  0.353 s]
> >> 
> >> [INFO] WiQuery Core Project ... SUCCESS [
> >> 
> >>  2.673 s]
> >> 
> >> [INFO] WiQuery jQuery UI Project .. FAILURE [
> >> 
> >>  0.023 s]
> >> 
> >> [INFO] WiQuery Demo Project 8.0-SNAPSHOT .. SKIPPED
> >> [INFO] 
> >> 
> >> [INFO] BUILD FAILURE
> >> [INFO] 
> >> 
> >> [INFO] Total time: 3.720 s
> >> [INFO] Finished at: 2018-06-06T11:48:16+02:00
> >> [INFO] 
> >> 
> >> [ERROR] Failed to execute goal on project wiquery-jquery-ui: Could not
> >> resolve dependencies for project org.wicketstuff.wiquery:
> >> wiquery-jquery-ui:jar:8.0-SNAPSHOT: Failure to find
> >> org.wicketstuff.wiquery:wiquery-core:jar:tests:8.0-SNAPSHOT in
> >> https://oss.sonatype.org/content/repositories/snapshots was cached in
> >> the local repository, resolution will not be reattempted until the update
> >> interval of sonatype-nexus-snapshots has elapsed or updates are forced ->
> >> [Help 1]
> >> [ERROR]
> > 
> > Did you change something about test-jar configuration? I do not see
> > `test-jar` generation enabled in the POM file.
> > 
> > On Wed, Jun 6, 2018 at 11:43 AM, Emond Papegaaij <
> > 
> > emond.papega...@topicus.nl> wrote:
> >> Hi Thomas,
> >> 
> >> The easiest way is to just run 'mvn install' and depend on 8.0-SNAPSHOT.
> >> I did
> >> not do a release, as I cannot push to central. If you want to run your
> >> tests
> >> on some CI server, you probably have to push the artifacts to a local
> >> repo
> >> also.
> >> 
> >> Best regards,
> >> Emond
> >> 
> >> On woensdag 6 juni 2018 11:36:54 CEST Thomas Heigl wrote:
> >> > Hi Emond,
> >> > 
> >> > How can I test this? Did you do a milestone release or do I have to
> >> 
> >> build
> >> 
> >> > from source and push to my local artifact repo?
> >> > 
> >> > Best,
> >> > 
> >> > Thomas
> >> > 
> >> > On Tue, Jun 5, 2018 at 3:01 PM, Emond Papegaaij <
> >> 
> >> emond.papega...@topicus.nl>
> >> 
> >> > wrote:
> >> > > I've just pushed a massive upgrade of all components. Removed all
> >> > > deprecated
> >> > > parts, upgraded jQuery UI to 1.12.1 and did some more cleanup and
> >> > > refactoring.
> >> > > Please test the changes in your project. The tests pass and the demo
> >> 
> >> runs
> >> 
> >> > > fine, but my project only uses a limited set of the UI components.
> >> > > 
> >> > > Best regards,
> >> > > Emond
> >> > > 
> >> > > On zaterdag 2 juni 2018 10:31:31 CEST you wrote:
> >> > > > I'm planning to upgrade jQuery UI to the latest version next week.
> >> 
> >> We
> >> 
> >> > > > are
> >> > > > currently migrating all our applications to wicket 8 and also
> >> 
> >> depend on
> >> 
> >> > > > wiquery quite a lot. It does however seem that jQuery UI is mostly
> >> 
> >> dead.
> >> 
> >> > > > The rest of the world probably switched to yet another fancy
> >> 
> >> JavaScript
> >> 
> >> > > ui
> >> > > 
> >> > > > library. At least the will make it easy to stay up to date with the
> >> > > 
> >> > > latest
> >> > > 
> >> > > > version :)
> &g

Re: Release WiQuery for Wicket 8

[Emond Papegaaij]

On donderdag 7 juni 2018 17:10:16 CEST Martin Grigorov wrote:
> 8.0 is on its way to Maven Central!

Thanks for the help with the release Martin, and Thomas thanks for testing!

Emond



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

Re: Release WiQuery for Wicket 8

[Emond Papegaaij]

I did not build the javadoc, but I actually don't know why. But as I don't 
care about these javadoc errors, I've disabled lint. You should be able to 
build now.

Emond

On donderdag 7 juni 2018 16:32:16 CEST Martin Grigorov wrote:
> There are many javadoc related errors in this project. mvn install fails
> with:
> 
> [WARNING] The requested profile "frontend" could not be activated because
> it does not exist.
> [WARNING] The requested profile "buildbot" could not be activated because
> it does not exist.
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.7:jar (attach-javadocs) on
> project wiquery-core: MavenReportException: Error while creating archive:
> [ERROR] Exit code: 1 -
> /home/martin/git/wiquery/wiquery-core/src/main/java/org/wicketstuff/wiquery/
> core/util/WiQueryUtil.java:46: warning: no @return
> [ERROR] public static ResourceReference getJQueryResourceReference()
> [ERROR]^
> [ERROR]
> /home/martin/git/wiquery/wiquery-core/src/main/java/org/wicketstuff/wiquery/
> core/events/Event.java:78: warning: no @return
> [ERROR] public abstract JsScope callback();
> [ERROR]^
> [ERROR]
> /home/martin/git/wiquery/wiquery-core/src/main/java/org/wicketstuff/wiquery/
> core/events/Event.java:53: warning: no @param for eventLabels
> [ERROR] public Event(EventLabel... eventLabels)
> [ERROR]   ^
> [ERROR]
> /home/martin/git/wiquery/wiquery-core/src/main/java/org/wicketstuff/wiquery/
> core/javascript/DefaultChainableStatement.java:49: warning: no @param for
> label
> [ERROR] public DefaultChainableStatement(String label, CharSequence... args)
> 
> 
> 
> How did you build it with Java 8 ?
> 
> 
> On Thu, Jun 7, 2018 at 3:55 PM, Martin Grigorov 
> 
> wrote:
> > OK. I will make a release!
> > 
> > On Thu, Jun 7, 2018 at 3:25 PM, Thomas Heigl  wrote:
> >> Hi Emond,
> >> 
> >> I did some exploratory testing against the current build. I checked
> >> Dialog,
> >> Autocomplete, Accordion, Slider, Sortable, and Tooltip and all seem to be
> >> working at first glance.
> >> 
> >> All my tests pass as well.
> >> 
> >> Best,
> >> 
> >> Thomas
> >> 
> >> On Wed, Jun 6, 2018 at 1:07 PM, Emond Papegaaij <
> >> emond.papega...@topicus.nl>
> >> 
> >> wrote:
> >> > I've fixed the problem. The setup currently used is discouraged and
> >> 
> >> broken
> >> 
> >> > in
> >> > m2e, but I don't feel like restructuring the whole thing to get rid of
> >> > this
> >> > test-jar.
> >> > 
> >> > Emond
> >> > 
> >> > On woensdag 6 juni 2018 11:57:43 CEST Thomas Heigl wrote:
> >> > > The culprit is:
> >> > > 
> >> > > https://github.com/wicketstuff/wiquery/commit/
> >> > 
> >> > 0235691174ceeede22b588d2f67868
> >> > 
> >> > > b940d9be3a
> >> > > On Wed, Jun 6, 2018 at 11:51 AM, Thomas Heigl 
> >> > 
> >> > wrote:
> >> > > > `mvn clean install` fails for me because no test-jar is built for
> >> 
> >> the
> >> 
> >> > core
> >> > 
> >> > > > module:
> >> > > > 
> >> > > > [INFO] WiQuery Parent 8.0-SNAPSHOT  SUCCESS
> >> 
> >> [
> >> 
> >> > > >>  0.353 s]
> >> > > >> 
> >> > > >> [INFO] WiQuery Core Project ...
> >> 
> >> SUCCESS [
> >> 
> >> > > >>  2.673 s]
> >> > > >> 
> >> > > >> [INFO] WiQuery jQuery UI Project ..
> >> 
> >> FAILURE [
> >> 
> >> > > >>  0.023 s]
> >> > > >> 
> >> > > >> [INFO] WiQuery Demo Project 8.0-SNAPSHOT ..
> >> > > >> SKIPPED
> >> > > >> [INFO] --
> >> 
> >> --
> >> 
> >> > > >> 
> >> > > >> [INFO] BUILD FAILURE
> >> > > >> [INFO] --
> >> 
> >> ------
> >> 
> >> > > >> 
> >> > > >> [INFO] Total time: 3.720 s
> >> > > >&

Re: Release WiQuery for Wicket 8

[Emond Papegaaij]

I'm planning to upgrade jQuery UI to the latest version next week. We are
currently migrating all our applications to wicket 8 and also depend on
wiquery quite a lot. It does however seem that jQuery UI is mostly dead.
The rest of the world probably switched to yet another fancy JavaScript ui
library. At least the will make it easy to stay up to date with the latest
version :)

I can't push a release to central, but perhaps Martin can do that when I'm
done? For now you can use a snapshot build. It works, but the UI API might
change a bit before the 8.0 release.

Best regards,
Emond Papegaaij


Op vr 1 jun. 2018 17:36 schreef Thomas Heigl :

> Hi Ernesto,
>
> I'm not sure how many people are still using it. But as I said, my project
> heavily depends on it.
>
> @papegaaij has resolved all the compile errors against 8.0.0-M9 (
> https://github.com/wicketstuff/wiquery) and a simple release of 8.0.0
> would
> be enough for me.
>
> Best,
>
> Thomas
>
> On Fri, Jun 1, 2018 at 5:05 PM, Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
> > Hi,
> >
> > I do not know who is actually using this project. I use to contribute to
> it
> > a few years ago. I haven't used it for ages..
> >
> > On Fri, Jun 1, 2018 at 3:39 PM, Thomas Heigl 
> wrote:
> >
> > > Hi,
> > >
> > > Following the release of Wicket 8.0.0 and WicketStuff 8.0.0, could
> > somebody
> > > please cut a release of WiQuery compatible with the new version?
> > >
> > > Our application still heavily relies on WiQuery and we can't move to
> > Wicket
> > > 8 without it.
> > >
> > > Best,
> > >
> > > Thomas
> > >
> >
> >
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
> >
>

Re: Release WiQuery for Wicket 8

[Emond Papegaaij]

I've just pushed a massive upgrade of all components. Removed all deprecated 
parts, upgraded jQuery UI to 1.12.1 and did some more cleanup and refactoring. 
Please test the changes in your project. The tests pass and the demo runs 
fine, but my project only uses a limited set of the UI components.

Best regards,
Emond

On zaterdag 2 juni 2018 10:31:31 CEST you wrote:
> I'm planning to upgrade jQuery UI to the latest version next week. We are
> currently migrating all our applications to wicket 8 and also depend on
> wiquery quite a lot. It does however seem that jQuery UI is mostly dead.
> The rest of the world probably switched to yet another fancy JavaScript ui
> library. At least the will make it easy to stay up to date with the latest
> version :)
> 
> I can't push a release to central, but perhaps Martin can do that when I'm
> done? For now you can use a snapshot build. It works, but the UI API might
> change a bit before the 8.0 release.
> 
> Best regards,
> Emond Papegaaij
> 
> Op vr 1 jun. 2018 17:36 schreef Thomas Heigl :
> > Hi Ernesto,
> > 
> > I'm not sure how many people are still using it. But as I said, my project
> > heavily depends on it.
> > 
> > @papegaaij has resolved all the compile errors against 8.0.0-M9 (
> > https://github.com/wicketstuff/wiquery) and a simple release of 8.0.0
> > would
> > be enough for me.
> > 
> > Best,
> > 
> > Thomas
> > 
> > On Fri, Jun 1, 2018 at 5:05 PM, Ernesto Reinaldo Barreiro <
> > 
> > reier...@gmail.com> wrote:
> > > Hi,
> > > 
> > > I do not know who is actually using this project. I use to contribute to
> > 
> > it
> > 
> > > a few years ago. I haven't used it for ages..
> > > 
> > > On Fri, Jun 1, 2018 at 3:39 PM, Thomas Heigl 
> > 
> > wrote:
> > > > Hi,
> > > > 
> > > > Following the release of Wicket 8.0.0 and WicketStuff 8.0.0, could
> > > 
> > > somebody
> > > 
> > > > please cut a release of WiQuery compatible with the new version?
> > > > 
> > > > Our application still heavily relies on WiQuery and we can't move to
> > > 
> > > Wicket
> > > 
> > > > 8 without it.
> > > > 
> > > > Best,
> > > > 
> > > > Thomas
> > > 
> > > --
> > > Regards - Ernesto Reinaldo Barreiro





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

Re: Issues upgrading to Wicket 8.0.0-M9

[Emond Papegaaij]

On maandag 19 februari 2018 11:22:30 CET Thomas Heigl wrote:
> 1. Current WiQuery version is not compatible with M9
> 
> It still depends on WicketEventJQueryResourceReference. It would be great
> if someone could cut a milestone release for WiQuery as well, so I can do
> further testing with my application.

I've just pushed a fix for this. WiQuery master now compiles against M9. Please 
not that wiquery-jquery-ui is hopelessly outdated. I hope to get that fixed in 
the comming month. However, it seems jquery-ui is dead as well (which does 
make it easier to stay up to date from now on :) ).

Best regards,
Emond



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

Re: Session#invalidateNow() question

[Emond Papegaaij]

Hi,

The javadoc states 'Whether the session is invalid now, or will be invalidated 
by the end of the request.' The first part is no longer true. The javadoc also 
states that you normally should not need this method (why is it part of the 
public API then?)

I think we can fix the method by setting the same metadata on the session. 
destroy should set the boolean to true and bind should remove it again.

Best regards,
Emond

On zaterdag 10 maart 2018 11:42:27 CET Sven Meier wrote:
> Hi,
> 
> invalidateNow() calls destroy(), which clears the SESSION_INVALIDATED
> request cycle flag.
> 
> isSessionInvalidated()'s javadoc states that 'clients should rarely need
> this method', but apparently they do. @Edmond: do you think we can/should
> improve that?
> 
> Have fun
> Sven
> 
> Am 09.03.2018 um 16:22 schrieb Gabor Friedrich:
> > Hello everybody,
> > 
> > We are in the process of migrating to wicket 7.10.0.
> > 
> > With reference to WICKET-6530, I have the following piece of code:
> > 
> > ...
> > 
> > @Override
> > public void onClick() {
> > 
> > // DO SOMETHING
> > 
> > final Session session = Session.get();
> > session.invalidateNow();
> > final boolean *isSessionInvalidated *= session.isSessionInvalidated(); //
> > false
> > 
> > // DO SOMETHING
> > 
> > }
> > 
> > ...
> > 
> > My question is: why is the value of  *isSessionInvalidated *always
> > *false?*. Note: in wicket 7.9.0 the value of *isSessionInvalidated *is
> > always true.
> > 
> > 
> > Thank you,
> > Gabor
> 
> -
> 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: NPE on session invalidation

[Emond Papegaaij]

I think it should be enough to change the javadoc. The method returns
true when the session was invalidated *during the current request*.
Without a request there is no way of telling whether the session is
invalidated or not. IMHO throwing an exception is fine, but this
behavior should be documented. If a default must be chosen, I'd opt
for false not true. Without a request there is no way the session can
be marked for invalidation, so it should not return true.

Best regards,
Emond

On Tue, Apr 3, 2018 at 5:42 PM, Martin Grigorov  wrote:
> On Tue, Apr 3, 2018 at 4:17 PM, Rakesh A  wrote:
>
>> Actually, we've bit more complex scenario I should say; we've multiple
>> webapps running on tomcat with SSO valve configured; which means logout on
>> one application kills the session on other applications and we've session
>> implementation class with logout & session invalidation handling.
>> In both cases logout/invalidate, we try to do some cleanup (at a high level
>> both call one method), which has this check 'isSessionInvalidated()' before
>> proceeding with cleanup.
>>
>
> You didn't answer my question (or I didn't understand your answer).
> Why do you need to use "isSessionInvalidated()" in your cleanup method ?
> Is the cleanup method called in some other cases ? If it is just called by
> logout/onInvalidate then there is no need to check "isSessionInvalidated()".
>
> But I agree that isSessionInvalidated should be improved to return true if
> there is no RequestCycle. If there is no RequestCycle then there is no
> Request, so there is no Session. But then the name would be confusing - one
> cannot be sure whether there was no session on first place or it has been
> invalidated.
> In any case this method is public and there is nothing saying that it is an
> internal API, so there should not be any assumptions.
>
>
>>
>> Regards,
>> Rakesh.A
>>
>> --
>> Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-
>> f1842947.html
>>
>> -
>> 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: Wicket 8 CsrfPrevention issue

[Emond Papegaaij]

I checked the answers and comments on that post, and they are
incorrect. When you
place your application behind a reverse http proxy, you need to make sure the
proxy passes the correct headers to your application and you application needs
to use these headers.

For WildFly, you need to add proxy-address-forwarding="true" to the http-
listener. This will instruct Undertow to read the headers passed by the proxy.

On your proxy you will want to set these headers (this is nginx config):
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
proxy_set_header X-Forwarded-Port $proxy_x_forwarded_port;

Best regards,
Emond Papegaaij

On Sat, Dec 22, 2018 at 7:31 PM Chris Turchin  wrote:
>
> This might help:
> https://stackoverflow.com/questions/46337253/apache-reverse-proxy-and-wicket-csrfpreventionrequestcyclelistener
>
> On Sat, Dec 22, 2018 at 3:28 AM ShengChe Hsiao  wrote:
> >
> > Dear all
> >
> > I use apache httpd as wildlfy's backend proxy server to redirect http
> > request to https request, when i add CsrfPreventionRequestCycleListener to
> > my application , it showd error message:
> >
> > [org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener]
> > (default task-48) Possible CSRF attack, request URL: http://
> > etalking.chc.edu.tw/agency/index, Origin: https://etalking.chc.edu.tw,
> > action: aborted with error 400 Origin does not correspond to request
> >
> > How can i conquer this?
> > 
> > --->
> > To boldly go where no man has gone before.
> > 
> > --->
> > We do this not because it is easy. We do this because it is hard.
> > -
> > -->
> > If I have seen further it is by standing on the shoulders of giants.
> > --
> > ->
> > front...@gmail.com
> > ->
>
>
>
> --
> Chris Turchin 
>
> -
> 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: Wicket 8 CsrfPrevention issue

[Emond Papegaaij]

I checked the answers and comments on that post, and they are wrong. When you 
place your application behind a reverse http proxy, you need to make sure the 
proxy passes the correct headers to your application and you application needs 
to use these headers.

For WildFly, you need to add proxy-address-forwarding="true" to the http-
listener. This will instruct Undertow to read the headers passed by the proxy.

On your proxy you will want to set these headers (this is nginx config):
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
proxy_set_header X-Forwarded-Port $proxy_x_forwarded_port;

Best regards,
Emond Papegaaij

On zaterdag 22 december 2018 12:46:11 CET Chris Turchin wrote:
> This might help:
> https://stackoverflow.com/questions/46337253/apache-reverse-proxy-and-wicket
> -csrfpreventionrequestcyclelistener
> On Sat, Dec 22, 2018 at 3:28 AM ShengChe Hsiao  wrote:
> > Dear all
> > 
> > I use apache httpd as wildlfy's backend proxy server to redirect http
> > request to https request, when i add CsrfPreventionRequestCycleListener to
> > my application , it showd error message:
> > 
> > [org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener]
> > (default task-48) Possible CSRF attack, request URL: http://
> > etalking.chc.edu.tw/agency/index, Origin: https://etalking.chc.edu.tw,
> > action: aborted with error 400 Origin does not correspond to request
> > 
> > How can i conquer this?
> > 
> > --->
> > To boldly go where no man has gone before.
> > 
> > --->
> > We do this not because it is easy. We do this because it is hard.
> > -
> > -->
> > If I have seen further it is by standing on the shoulders of giants.
> > --
> > ->
> > front...@gmail.com
> > --
> > --->





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

Re: getPageClass locks the page

[Emond Papegaaij]

Hi,

Some time ago, we faced a similar issue. A custom component accessed
pages after they were unlocked, causing stale locks. Back then I filed
an issue (WICKET-6558), but haven't had time to implement the fix.
Locking pages after commitRequest should be blocked.

Best regards,
Emond

On Tue, Aug 13, 2019 at 8:57 AM Sven Meier  wrote:
>
> Hi,
>
> PageAccessSynchronizer#detach() unlocks all pages.
>
> Is your request logger running after that?
>
> Have fun
> Sven
>
>
> On 13.08.19 07:46, Martin Grigorov wrote:
> > Hi,
> >
> > If the page is not unlocked then it is a bug.
> > But it is strange that no one faced it before. This code is in use since
> > Wicket 1.5.0.
> >
> > On Tue, Aug 13, 2019 at 7:38 AM Andrew Kondratev 
> > wrote:
> >
> >> Hi!
> >>
> >> My colleague noticed some dodgy behavior, which I think could be a bug.
> >> Just asking here if it's known, befor I try to create a quickstart or PR.
> >>
> >> * page is rendered
> >> * user interacts with a page causing ajax request (clicking checkbox)
> >> * the wicket PageAccessSynchronizer locks, renders and unlocks the page
> >> with that id
> >> * after that, custom request logger asks for the className of the current
> >> page
> >> * the PageProvider doesn't have it on hand, so has to ask for the page from
> >> DefaultMapperContext#getPageInstance
> >> * that in turn locks the page again -- without unlocking it
> >> * so subsequent interaction with the same component blows up after a minute
> >> of not being able to get the lock for the page
> >>
> >> Wicket 8.5.0
> >>
> >> The stack trace
> >> org.apache.wicket.page.CouldNotLockPageException: Could not lock page 86.
> >> Attempt lasted 1 minute
> >> at
> >> org.apache.wicket.page
> >> .PageAccessSynchronizer.lockPage(PageAccessSynchronizer.java:168)
> >> at
> >> org.apache.wicket.page
> >> .PageAccessSynchronizer$2.getPage(PageAccessSynchronizer.java:246)
> >> at
> >>
> >> org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperContext.java:101)
> >> at
> >>
> >> org.apache.wicket.core.request.handler.PageProvider$Provision.resolve(PageProvider.java:412)
> >> at
> >>
> >> org.apache.wicket.core.request.handler.PageProvider.getProvision(PageProvider.java:163)
> >> at
> >>
> >> org.apache.wicket.core.request.handler.PageProvider.getPageInstance(PageProvider.java:171)
> >> at
> >>
> >> org.apache.wicket.core.request.handler.PageProvider.getPageClass(PageProvider.java:257)
> >> at
> >>
> >> org.apache.wicket.core.request.handler.ListenerRequestHandler.getPageClass(ListenerRequestHandler.java:108)
> >> at
> >>
> >> org.apache.wicket.protocol.https.HttpsMapper.getDesiredSchemeFor(HttpsMapper.java:199)
> >> at
> >>
> >> org.apache.wicket.protocol.https.HttpsMapper.mapRequest(HttpsMapper.java:103)
> >> at
> >>
> >> org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(CompoundRequestMapper.java:147)
> >> at
> >>
> >> org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(RequestCycle.java:193)
> >> at
> >>
> >> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:243)
> >> at
> >>
> >> com.mycompany.core.web.framework.MyRequestCycle.processRequest(MyRequestCycle.java:129)
> >> at
> >>
> >> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:221)
> >> at
> >>
> >> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:275)
> >> at
> >>
> >> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:206)
> >> at
> >>
> >> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:299)
> >> at
> >>
> >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> >> at
> >>
> >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> >> at
> >>
> >> com.mycompany.core.web.filter.ResponseHeadersFilter.doFilter(ResponseHeadersFilter.java:31)
> >> at
> >>
> >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> >> at
> >>
> >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> >> at
> >>
> >> com.mycompany.core.web.filter.MDCEnhancingFilter.lambda$doFilterInternal$0(MDCEnhancingFilter.java:29)
> >> at
> >>
> >> com.mycompany.common.logging.LoggingContextUtil$VoidCallable.call(LoggingContextUtil.java:168)
> >> at
> >>
> >> com.mycompany.common.logging.LoggingContextUtil$VoidCallable.call(LoggingContextUtil.java:163)
> >> at
> >>
> >> com.mycompany.common.logging.LoggingContextUtil.runWithLoggingContext(LoggingContextUtil.java:65)
> >> at
> >>
> >> com.mycompany.common.logging.LoggingContextUtil.runWithLoggingContext(LoggingContextUtil.java:34)
> >> at
> >>
> >> com.mycompany.core.web.filter.MDCEnhancingFilter.doFilterInternal(MDCEnhancingFilter.java:29)
> >> at
> >>
> >> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >> at
> >>
> >>