Re: WicketStuff artifacts naming strategy

2011-06-29 Thread Harald Wellmann
For Maven OSGi bundle artifacts, there is a quasi-convention to have 
artifactId = Bundle-Symbolic name, so you would have


groupId: org.wicketstuff
artifactId: org.wicketstuff.foo.bar
version: 1.5

Bundle-Symbolic-Name: org.wicketstuff.foo.bar
JAR name: org.wicketstuff.foo.bar-1.5.jar

Apache Servicemix and Apache Aries use this convention, while Apache 
Commons sticks with the old names.


Having this naming scheme and the one Bruno suggested in parallel would 
help to distinguish OSGi bundles from plain old JARs.


Then again, that would mean you'd have to rename artifacts, once you 
osgify them.


Regards,
Harald


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



Why RelativePathPrefixHandler calculates path from context path ?

2011-06-29 Thread Guillaume Mary
Hi all,

I'm using Wicket 1.4.17 and my Wicket filter is mounted on a sub url of the 
context path (I declared /MyApp/* in the url-mapping of web.xml, important 
point).

I use img src=resources/. directly in the markup, without a 
ResourceReference in the Java component, and suprisingly the image is not found 
by the browser. If I declare a ResourceReference, it works. So I supposed a 
problem in the relative path calculation during the parsing of the html, I 
found RelativePathPrefixHandler class and looked at it. In its  Javadoc, it is 
said that paths are calculated relatively to the context path, and that's the 
problem.
I found a solution, patching RelativePathPrefixHandler.

But my question is : why this class is supposed to calculate paths relatively 
to context path whereas we can mount Wicket application in a sub context ?

(According to me this is more a  bug in RelativePathPrefixHandler, and ready to 
open an RFE + share my patch)

Thanks



Re: Why RelativePathPrefixHandler calculates path from context path ?

2011-06-29 Thread Martin Grigorov
Hi,

On Wed, Jun 29, 2011 at 11:26 AM, Guillaume Mary
guillaume.m...@interview-efm.com wrote:
 Hi all,

 I'm using Wicket 1.4.17 and my Wicket filter is mounted on a sub url of the 
 context path (I declared /MyApp/* in the url-mapping of web.xml, important 
 point).

 I use img src=resources/. directly in the markup, without a 
 ResourceReference in the Java component, and suprisingly the image is not 
 found by the browser. If I declare a ResourceReference, it works. So I 
 supposed a problem in the relative path calculation during the parsing of the 
 html, I found RelativePathPrefixHandler class and looked at it. In its  
 Javadoc, it is said that paths are calculated relatively to the context path, 
 and that's the problem.
 I found a solution, patching RelativePathPrefixHandler.

 But my question is : why this class is supposed to calculate paths relatively 
 to context path whereas we can mount Wicket application in a sub context ?
Because the resources are supposed to be next to WEB-INF folder.
Wicket should handle the requests to dynamic resources (pages,
callback listeners, etc.), while the static resources better should be
handled by the web container.

Why do you use 'resources' ? I guess because the resource is in the
classpath. In this case you can use wicket:link.

 (According to me this is more a  bug in RelativePathPrefixHandler, and ready 
 to open an RFE + share my patch)

 Thanks





-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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



close modal window message: Close the top-level modal window first

2011-06-29 Thread Mihai Toma
Hi,

 

I have a problem when I try to close a modal window.

 

The idea is that I have a ModalWindow created with setContent inside a
ModalWindow created with getPageCreator and when  I try to close with
ModalWindow.closeCurren() the javascript alert appear with the message
Close the top-level modal window first.

 

I create first ModalWindow also with setContent and the second one close
correctly (without javascript warning).

 

My problem is that I can't use setContent in first ModalWindow because it
takes too much time to open instead of getPageCreator.

 

Any idea on how to close the second ModalWindow if the first ModalWindow is
created using getPageCreator?

 

Thanks!

 

P.S. - My problem is the same with:
http://apache-wicket.1842946.n4.nabble.com/Fail-to-close-ModalWindow-on-top-
of-ModalWindow-td1879540.html 



Wicket 1.5-RC4.2 Session invalidate?

2011-06-29 Thread nino martinez wael
Hi

This does not work at all, my session are newer cleared.. Am I doing
something wrong or?

add(new LinkVoid(logOut) {
@Override
public void onClick() {
getSession().invalidate();

setResponsePage(WicketApplication.get().getHomePage());

}
});


Regards Nino

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



Re: Wicket 1.5-RC4.2 Session invalidate?

2011-06-29 Thread Martin Grigorov
Looks OK.
Upgrade to RC5.1. It is fixed.

On Wed, Jun 29, 2011 at 11:40 AM, nino martinez wael
nino.martinez.w...@gmail.com wrote:
 Hi

 This does not work at all, my session are newer cleared.. Am I doing
 something wrong or?

                add(new LinkVoid(logOut) {
                        @Override
                        public void onClick() {
                                getSession().invalidate();
                                
 setResponsePage(WicketApplication.get().getHomePage());

                        }
                });


 Regards Nino

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





-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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



RE: close modal window message: Close the top-level modal window first

2011-06-29 Thread Mihai Toma

I forgot to say that I use wicket 1.4.15


Hi,

 

I have a problem when I try to close a modal window.

 

The idea is that I have a ModalWindow created with setContent inside a
ModalWindow created with getPageCreator and when  I try to close with
ModalWindow.closeCurren() the javascript alert appear with the message
Close the top-level modal window first.

 

I create first ModalWindow also with setContent and the second one close
correctly (without javascript warning).

 

My problem is that I can't use setContent in first ModalWindow because it
takes too much time to open instead of getPageCreator.

 

Any idea on how to close the second ModalWindow if the first ModalWindow is
created using getPageCreator?

 

Thanks!

 

P.S. - My problem is the same with:
http://apache-wicket.1842946.n4.nabble.com/Fail-to-close-ModalWindow-on-top-
of-ModalWindow-td1879540.html 



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



Re: Wicket 1.5-RC4.2 Session invalidate?

2011-06-29 Thread nino martinez wael
ahh did'nt see it was out..

2011/6/29 Martin Grigorov mgrigo...@apache.org:
 Looks OK.
 Upgrade to RC5.1. It is fixed.

 On Wed, Jun 29, 2011 at 11:40 AM, nino martinez wael
 nino.martinez.w...@gmail.com wrote:
 Hi

 This does not work at all, my session are newer cleared.. Am I doing
 something wrong or?

                add(new LinkVoid(logOut) {
                        @Override
                        public void onClick() {
                                getSession().invalidate();
                                
 setResponsePage(WicketApplication.get().getHomePage());

                        }
                });


 Regards Nino

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





 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.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-RC4.2 Session invalidate?

2011-06-29 Thread nino martinez wael
Yup it works after upgrading to rc5.1

2011/6/29 nino martinez wael nino.martinez.w...@gmail.com:
 ahh did'nt see it was out..

 2011/6/29 Martin Grigorov mgrigo...@apache.org:
 Looks OK.
 Upgrade to RC5.1. It is fixed.

 On Wed, Jun 29, 2011 at 11:40 AM, nino martinez wael
 nino.martinez.w...@gmail.com wrote:
 Hi

 This does not work at all, my session are newer cleared.. Am I doing
 something wrong or?

                add(new LinkVoid(logOut) {
                        @Override
                        public void onClick() {
                                getSession().invalidate();
                                
 setResponsePage(WicketApplication.get().getHomePage());

                        }
                });


 Regards Nino

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





 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.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



Configure http and https with apache and jboss

2011-06-29 Thread Vishal Popat
I am trying to configure my web app to use http and https. I am using the 
following code in my Application class:
protected IRequestCycleProcessor newRequestCycleProcessor() {
HttpsConfig config = new HttpsConfig(80, 443);
return new MyHttpsRequestCycleProcessor(config);
}
WebPages such as Login, MyAccount etc have the @RequireHttps annotation.

I receive a 404 error when clicking on any page which have the @RequireHttps
A bit of debugging shows that the link its trying to access is 
https://myserver.com/myapp/login. I am trying to have my web application not 
have a context root i.e. the myapp should not be there.

I have looked at various threads which have slightly different scenarios 
without success. I have tried various other setup configs with different 
results.
Any help would be appreciated.

My setup is below:
Ubuntu 11.04
Apache/2.2.17 (Unix)
JbossAS 6
Wicket 1.4.15

I am using Apache as the front web server which I want to handle http and https
I have the following within my httpd.conf:

NameVirtualHost *:80
VirtualHost *:80
ServerName myserver.com:80

ProxyPass / http://myserver.com:8080/myapp/
ProxyPassReverse / http://myserver.com:8080/myapp/
/VirtualHost

NameVirtualHost *:443
VirtualHost *:443
ServerName myserver.com:443

SSLEngine On
SSLCertificateKeyFile /etc/ssl/private/server.key
SSLCertificateFile /etc/ssl/certs/server.crt

ProxyPass / http://myserver.com:8080/myapp/
ProxyPassReverse / http://myserver.com:8080/myapp/
/VirtualHost 

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



Re: Configure http and https with apache and jboss

2011-06-29 Thread nino martinez wael
If I had this problem to solve, I'd start off first by showing a html
file in apache over https, and next step adding in wicket without
https, and then joining them afterwards.. Asking both apache httpd
forum and this one (as you've already done) If having problems..

As a last step, i'd write a nice little blog post telling other people
how you solved it :)

2011/6/29 Vishal Popat vishal.po...@cipriati.co.uk:
 I am trying to configure my web app to use http and https. I am using the 
 following code in my Application class:
 protected IRequestCycleProcessor newRequestCycleProcessor() {
        HttpsConfig config = new HttpsConfig(80, 443);
        return new MyHttpsRequestCycleProcessor(config);
 }
 WebPages such as Login, MyAccount etc have the @RequireHttps annotation.

 I receive a 404 error when clicking on any page which have the @RequireHttps
 A bit of debugging shows that the link its trying to access is 
 https://myserver.com/myapp/login. I am trying to have my web application not 
 have a context root i.e. the myapp should not be there.

 I have looked at various threads which have slightly different scenarios 
 without success. I have tried various other setup configs with different 
 results.
 Any help would be appreciated.

 My setup is below:
 Ubuntu 11.04
 Apache/2.2.17 (Unix)
 JbossAS 6
 Wicket 1.4.15

 I am using Apache as the front web server which I want to handle http and 
 https
 I have the following within my httpd.conf:

 NameVirtualHost *:80
 VirtualHost *:80
        ServerName myserver.com:80

        ProxyPass / http://myserver.com:8080/myapp/
        ProxyPassReverse / http://myserver.com:8080/myapp/
 /VirtualHost

 NameVirtualHost *:443
 VirtualHost *:443
        ServerName myserver.com:443

        SSLEngine On
        SSLCertificateKeyFile /etc/ssl/private/server.key
        SSLCertificateFile /etc/ssl/certs/server.crt

        ProxyPass / http://myserver.com:8080/myapp/
        ProxyPassReverse / http://myserver.com:8080/myapp/
 /VirtualHost

 Regards
 Vishal
 -
 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: new user registration email verification

2011-06-29 Thread Daniel Neugebauer
It's like you already said in your first mail. For one of our websites 
the behaviour is:


1) generate some kind of a random, unique token
   s.th. like UUID.randomUUID().toString()

2) register token to user in database

3) email link including the token to the user
   (use a readily available email library)

For your application to process the link, the link should end in a 
bookmarkable page with a short URL (so it doesn't take too much space in 
the email). If you append the token like you usually do (depending on 
the UrlCodingStrategy used), the page can get the token by accessing the 
PageParameters. If you have multiple types of opt-ins/confirmations 
(user accounts, newsletters etc.) then you could use one page to process 
all tokens and let it decide which additional page should be 
instantiated and redirected to after token verification depending on the 
token type you saved in your database.


On our website we check the token for the correct pattern using a 
regular expression and then get the user's email address/data from the 
database and let the user confirm his address by re-entering it and 
continue with an account setup wizard. However, such a double-safety 
should rarely be necessary. We could as well confirm the account right 
away (or immediately show/redirect to the wizard instead); once you have 
the token you know what user is intended to be accessed so you can do 
whatever you want.


Also make sure your tokens will time out after a week or so. You may 
also want to count token requests/validations and block users in case 
the number gets too high (get the client IP address by accessing the 
servlet request and record it somewhere). Maybe we are just a bit too 
cautious but our application hosts quite some data, so it can't be wrong. :)


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



Re: Configure http and https with apache and jboss

2011-06-29 Thread vp143
I have already tested html files containing http links and https links. I can
navigate around these files including browser indicators saying the ssl cert
is fine. For this I had to add DocumentRoot /var/www.

The http part of the wicket website is working fine.
I would like to try Jboss without Wicket but cannot think of a simple way of
doing this.
I have also tried changing an http page to https which loads fine (although
the pages I have tried show some insecure elements to the page)
So far the problem seems to lie around the HttpsRequestCycleProcessor class
although the fix may lie elsewhere.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Configure-http-and-https-with-apache-and-jboss-tp3633546p3634045.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: new user registration email verification

2011-06-29 Thread Peter Ertl
Very nicely explained...

In the special case when you need the confirmation link to register for a new 
user account I would additionally recommend the following:

- Let the user enter the initial password for the account when he requests it

- Send the link with the token like Daniel explained

- When processing the confirmation link with the random UUID token, let the 
user re-enter his password on link confirmation page

This will prevent the hijacking of the confirmation link in the mail since it's 
useless without the password. IMHO this will cause the least possible annoyance 
for the user (he needs to set his initial password anyway)


Am 29.06.2011 um 21:05 schrieb Daniel Neugebauer:

 It's like you already said in your first mail. For one of our websites the 
 behaviour is:
 
 1) generate some kind of a random, unique token
   s.th. like UUID.randomUUID().toString()
 
 2) register token to user in database
 
 3) email link including the token to the user
   (use a readily available email library)
 
 For your application to process the link, the link should end in a 
 bookmarkable page with a short URL (so it doesn't take too much space in the 
 email). If you append the token like you usually do (depending on the 
 UrlCodingStrategy used), the page can get the token by accessing the 
 PageParameters. If you have multiple types of opt-ins/confirmations (user 
 accounts, newsletters etc.) then you could use one page to process all tokens 
 and let it decide which additional page should be instantiated and redirected 
 to after token verification depending on the token type you saved in your 
 database.
 
 On our website we check the token for the correct pattern using a regular 
 expression and then get the user's email address/data from the database and 
 let the user confirm his address by re-entering it and continue with an 
 account setup wizard. However, such a double-safety should rarely be 
 necessary. We could as well confirm the account right away (or immediately 
 show/redirect to the wizard instead); once you have the token you know what 
 user is intended to be accessed so you can do whatever you want.
 
 Also make sure your tokens will time out after a week or so. You may also 
 want to count token requests/validations and block users in case the number 
 gets too high (get the client IP address by accessing the servlet request and 
 record it somewhere). Maybe we are just a bit too cautious but our 
 application hosts quite some data, so it can't be wrong. :)
 
 -
 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