Re: Configure http and https with apache and jboss
On Wed, Jun 29, 2011 at 8:58 PM, Vishal Popat
vishal.po...@cipriati.co.uk wrote:
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);
What is MyHttpsRequestCycleProcessor ? This is your class which I
guess extends from Wicket's HttpsRequestCycleProcessor.
Maybe here is the problem. It seems HttpsConfig's httpsPort is ignored.
}
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
--
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: Why RelativePathPrefixHandler calculates path from context path ?
Martin Grigorov-4 wrote: 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. I agree with the point that resources should be handled by the web container: if I write src=xxx.gif, I expect that the web container will serve the resource. So in that case RelativePathPrefixHandler is good. But that's the important point: I use 'resources' in order to use the Wicket Resource mecanism. Writing src=resources/com./xxx.gif makes Wicket answering the request, without any ResourceReference declared in Java (lazy guy !). So, for that specific case I expected that RelativePathPrefixHandler recalculate correctly the path, going up to the wicket filter and not to the context path. As I read your answer, I think that using Wicket resources url in the markup without declaring ResourceReference is a bad practise. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Why-RelativePathPrefixHandler-calculates-path-from-context-path-tp3632353p3634976.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: Why RelativePathPrefixHandler calculates path from context path ?
Hi, On Thu, Jun 30, 2011 at 10:26 AM, guillaume.mary guillaume.m...@interview-efm.com wrote: Martin Grigorov-4 wrote: 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. I agree with the point that resources should be handled by the web container: if I write src=xxx.gif, I expect that the web container will serve the resource. So in that case RelativePathPrefixHandler is good. But that's the important point: I use 'resources' in order to use the Wicket Resource mecanism. Writing src=resources/com./xxx.gif makes Wicket answering the request, without any ResourceReference declared in Java (lazy guy !). So, for that specific case I expected that RelativePathPrefixHandler recalculate correctly the path, going up to the wicket filter and not to the context path. As I read your answer, I think that using Wicket resources url in the markup without declaring ResourceReference is a bad practise. I just said that RelativePathPrefixHandler has different purpose and what you need is wicket:linkimg src=my.gif//wicket:link It supports parent folder as well (see org.apache.wicket.settings.IResourceSettings.setParentFolderPlaceholder(String)) -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Why-RelativePathPrefixHandler-calculates-path-from-context-path-tp3632353p3634976.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 -- 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: Configure http and https with apache and jboss
The MyHttpsRequestCycleProcessor was just used to debug i.e. no changes of code. The same problem is there without my custom class. You say the httpsPort is being ignored. How can I check this? What should be outputted if I print the url as nothing is being outputted? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Configure-http-and-https-with-apache-and-jboss-tp3633546p3635048.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
Application with name 'xxxx' already exists.
Hi, the last hours I wanted to give the 1.5-RC a try. But there is one Exception which doesn't have an effect but it's just irritating: After deploying a Web-Application (The Hello-World-Example) on a GF 3.1. I'll receive this error: SCHWERWIEGEND: WebModule[/X-web]PWC1270: Exception starting filter xxx java.lang.InstantiationException at org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:124) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4625) at org.apache.catalina.core.StandardContext.start(StandardContext.java:5316) at com.sun.enterprise.web.WebModule.start(WebModule.java:500) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:755) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1980) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1630) at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100) at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130) at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269) at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:286) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370) at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465) at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222) at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168) at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.IllegalStateException: Application with name 'X' already exists.' at org.apache.wicket.Application.setName(Application.java:847) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:307) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:284) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:266) at org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:120) ... 40 more It doesn't affect the functionality of the web-page. It's served as usual. On the GF is nothing else deployed (Ok. Just one Database Pool). Yours marc - 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
Put a breakpoint at org.apache.wicket.protocol.https.SwitchProtocolRequestTarget.respond(RequestCycle) and see what port is passed to org.apache.wicket.protocol.https.SwitchProtocolRequestTarget.getUrl(String, Integer, HttpServletRequest) On Thu, Jun 30, 2011 at 11:01 AM, vp143 vishal.po...@cipriati.co.uk wrote: The MyHttpsRequestCycleProcessor was just used to debug i.e. no changes of code. The same problem is there without my custom class. You say the httpsPort is being ignored. How can I check this? What should be outputted if I print the url as nothing is being outputted? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Configure-http-and-https-with-apache-and-jboss-tp3633546p3635048.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 -- 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: Application with name 'xxxx' already exists.
This can happen when you have two WicketFilter declarations in web.xml with the same name. On Thu, Jun 30, 2011 at 9:00 AM, me mli...@e-beyond.de wrote: Hi, the last hours I wanted to give the 1.5-RC a try. But there is one Exception which doesn't have an effect but it's just irritating: After deploying a Web-Application (The Hello-World-Example) on a GF 3.1. I'll receive this error: SCHWERWIEGEND: WebModule[/X-web]PWC1270: Exception starting filter xxx java.lang.InstantiationException at org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:124) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4625) at org.apache.catalina.core.StandardContext.start(StandardContext.java:5316) at com.sun.enterprise.web.WebModule.start(WebModule.java:500) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:755) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1980) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1630) at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100) at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130) at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269) at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:286) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370) at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465) at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222) at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168) at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.IllegalStateException: Application with name 'X' already exists.' at org.apache.wicket.Application.setName(Application.java:847) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:307) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:284) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:266) at org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:120) ... 40 more It doesn't affect the functionality of the web-page. It's served as usual. On the GF is nothing else deployed (Ok. Just one Database Pool). Yours marc - 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
Re: Configure http and https with apache and jboss
The port being passed was null. The code in HttpsRequestCycleProcessor that
sets the port is:
Integer port = null;
if (protocol == Protocol.HTTP) {
if (processor.getConfig().getHttpPort() != 80) {
port = processor.getConfig().getHttpPort();
}
}
else if (protocol == Protocol.HTTPS) {
if (processor.getConfig().getHttpsPort() != 443) {
port = processor.getConfig().getHttpsPort();
}
}
Why is the port only set if its not 80 or 443. If its 80 or 443 then its
null. I guess if its the default ports then they do not need to be set?
I amended the code so that a port is set, but still no difference i.e. I
still get a 404.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Configure-http-and-https-with-apache-and-jboss-tp3633546p3635246.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: Configure http and https with apache and jboss
Right.
443 is not needed if the protocol is HTTPS.
It should be something in the setup of the web servers ...
On Thu, Jun 30, 2011 at 1:04 PM, vp143 vishal.po...@cipriati.co.uk wrote:
The port being passed was null. The code in HttpsRequestCycleProcessor that
sets the port is:
Integer port = null;
if (protocol == Protocol.HTTP) {
if (processor.getConfig().getHttpPort() != 80) {
port = processor.getConfig().getHttpPort();
}
}
else if (protocol == Protocol.HTTPS) {
if (processor.getConfig().getHttpsPort() != 443) {
port = processor.getConfig().getHttpsPort();
}
}
Why is the port only set if its not 80 or 443. If its 80 or 443 then its
null. I guess if its the default ports then they do not need to be set?
I amended the code so that a port is set, but still no difference i.e. I
still get a 404.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Configure-http-and-https-with-apache-and-jboss-tp3633546p3635246.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
--
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: Configure http and https with apache and jboss
One additional point... if I take out
protected IRequestCycleProcessor newRequestCycleProcessor() {
HttpsConfig config = new HttpsConfig(80, 443);
return new HttpsRequestCycleProcessor(config);
}
and I navigate manually to an https link i.e. https://myserver.com/login.
Everything looks fine, loads, padlock etc is working as expected.
So I am sure them the answer is in
HttpsRequestCycleProcessor/SwitchProtocolRequestTarget although the fix may
be in the setup of the web server.
Any other suggestions on what to look out for in
HttpsRequestCycleProcessor/SwitchProtocolRequestTarget classes?
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Configure-http-and-https-with-apache-and-jboss-tp3633546p3635299.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: Configure http and https with apache and jboss
On Thu, Jun 30, 2011 at 1:34 PM, vp143 vishal.po...@cipriati.co.uk wrote:
One additional point... if I take out
protected IRequestCycleProcessor newRequestCycleProcessor() {
HttpsConfig config = new HttpsConfig(80, 443);
return new HttpsRequestCycleProcessor(config);
}
and I navigate manually to an https link i.e. https://myserver.com/login.
In your previous mails you used /myapp as context path. Your Apache
config also setups it.
Now you say that the page is reachable without /myapp ?!
Everything looks fine, loads, padlock etc is working as expected.
So I am sure them the answer is in
HttpsRequestCycleProcessor/SwitchProtocolRequestTarget although the fix may
be in the setup of the web server.
Any other suggestions on what to look out for in
HttpsRequestCycleProcessor/SwitchProtocolRequestTarget classes?
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Configure-http-and-https-with-apache-and-jboss-tp3633546p3635299.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
--
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: Configure http and https with apache and jboss
/myapp is only used within the apache httpd.conf and not accessing it through the browser. The pages are accessed like http://myserver.com/ and hopefully https://myserver.com/login A debug output from getUrl shows the link obtained is https://myserver.com/myapp/login (I think from request.getRequestURI()) -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Configure-http-and-https-with-apache-and-jboss-tp3633546p3635405.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
Behaviors beforeRender broken
Hi all, I wanted to use a Behavior to customize the components in my application (Wicket 1.4.2) by modifying some properties in the behaviors beforeRender method. But I had to find that this method is never called, neither is afterRender. The other methods of the behavior are invoked but those are not suitable for my needs (can't modify visibilty e.g. because that yields an exception). I found an bug entry about this problem and acording to the comments this seems to be a conecptual problem and won't be fixed. So I was wondering if there is a suitable alternative to be used instead of a behavior. For example I would like a component to decide for itself if it should be visible in the current context by evaluating stuff like login status of the user or it's content. Would be great if I could get some pointers on how to do this in a sensible way with wicket. Cheers, Chris - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: WicketStuff artifacts naming strategy
The preffix is 'wicketstuff-', not 'org.wicketstuff.' Is this ok? *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Wed, Jun 29, 2011 at 4:01 AM, Harald Wellmann harald.wellm...@gmx.dewrote: 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-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: WicketStuff artifacts naming strategy
I haven't seen that syntax before of having the group id in the artifact id, at least not with the longer group ids (reverse domain). On Thu, Jun 30, 2011 at 11:02 AM, Bruno Borges bruno.bor...@gmail.com wrote: The preffix is 'wicketstuff-', not 'org.wicketstuff.' Is this ok? *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Wed, Jun 29, 2011 at 4:01 AM, Harald Wellmann harald.wellm...@gmx.dewrote: 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-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: WicketStuff artifacts naming strategy
Yes, me neither. That's why I asked. The preffix I'm using is wicketstuff-, but Harald mentioned org.wicketstuff. I don't want to use that, it's too verbose. *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Thu, Jun 30, 2011 at 12:06 PM, James Carman ja...@carmanconsulting.comwrote: I haven't seen that syntax before of having the group id in the artifact id, at least not with the longer group ids (reverse domain). On Thu, Jun 30, 2011 at 11:02 AM, Bruno Borges bruno.bor...@gmail.com wrote: The preffix is 'wicketstuff-', not 'org.wicketstuff.' Is this ok? *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Wed, Jun 29, 2011 at 4:01 AM, Harald Wellmann harald.wellm...@gmx.de wrote: 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-unsubscribe@wicket.**apache.org 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: WicketStuff artifacts naming strategy
Harald said that org.wicketstuff. convention is used by OSGi-ed projects. On Thu, Jun 30, 2011 at 6:09 PM, Bruno Borges bruno.bor...@gmail.com wrote: Yes, me neither. That's why I asked. The preffix I'm using is wicketstuff-, but Harald mentioned org.wicketstuff. I don't want to use that, it's too verbose. *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Thu, Jun 30, 2011 at 12:06 PM, James Carman ja...@carmanconsulting.comwrote: I haven't seen that syntax before of having the group id in the artifact id, at least not with the longer group ids (reverse domain). On Thu, Jun 30, 2011 at 11:02 AM, Bruno Borges bruno.bor...@gmail.com wrote: The preffix is 'wicketstuff-', not 'org.wicketstuff.' Is this ok? *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Wed, Jun 29, 2011 at 4:01 AM, Harald Wellmann harald.wellm...@gmx.de wrote: 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-unsubscribe@wicket.**apache.org 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 -- 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: WicketStuff artifacts naming strategy
But is it necessary to rename the artifactId to OSGify a module? I'm just asking. Not that I'm going back to rename all again. :-) *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Thu, Jun 30, 2011 at 12:20 PM, Martin Grigorov mgrigo...@apache.orgwrote: Harald said that org.wicketstuff. convention is used by OSGi-ed projects. On Thu, Jun 30, 2011 at 6:09 PM, Bruno Borges bruno.bor...@gmail.com wrote: Yes, me neither. That's why I asked. The preffix I'm using is wicketstuff-, but Harald mentioned org.wicketstuff. I don't want to use that, it's too verbose. *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Thu, Jun 30, 2011 at 12:06 PM, James Carman ja...@carmanconsulting.comwrote: I haven't seen that syntax before of having the group id in the artifact id, at least not with the longer group ids (reverse domain). On Thu, Jun 30, 2011 at 11:02 AM, Bruno Borges bruno.bor...@gmail.com wrote: The preffix is 'wicketstuff-', not 'org.wicketstuff.' Is this ok? *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Wed, Jun 29, 2011 at 4:01 AM, Harald Wellmann harald.wellm...@gmx.de wrote: 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-unsubscribe@wicket.**apache.org 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 -- 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: WicketStuff artifacts naming strategy
And repetitive Sent from my Android device. Please excuse typos and brevity. On Jun 30, 2011 11:12 AM, Bruno Borges bruno.bor...@gmail.com wrote: Yes, me neither. That's why I asked. The preffix I'm using is wicketstuff-, but Harald mentioned org.wicketstuff. I don't want to use that, it's too verbose. *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Thu, Jun 30, 2011 at 12:06 PM, James Carman ja...@carmanconsulting.comwrote: I haven't seen that syntax before of having the group id in the artifact id, at least not with the longer group ids (reverse domain). On Thu, Jun 30, 2011 at 11:02 AM, Bruno Borges bruno.bor...@gmail.com wrote: The preffix is 'wicketstuff-', not 'org.wicketstuff.' Is this ok? *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Wed, Jun 29, 2011 at 4:01 AM, Harald Wellmann harald.wellm...@gmx.de wrote: 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-unsubscribe@wicket.**apache.org 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: Behaviors beforeRender broken
mixin IComponentConfigurationBehavior (1.4.17+ i believe) and implement visibility toggling in onconfigure(component) of your behavior. -igor On Thu, Jun 30, 2011 at 7:03 AM, Christian Huber hub...@butterbrot.org wrote: Hi all, I wanted to use a Behavior to customize the components in my application (Wicket 1.4.2) by modifying some properties in the behaviors beforeRender method. But I had to find that this method is never called, neither is afterRender. The other methods of the behavior are invoked but those are not suitable for my needs (can't modify visibilty e.g. because that yields an exception). I found an bug entry about this problem and acording to the comments this seems to be a conecptual problem and won't be fixed. So I was wondering if there is a suitable alternative to be used instead of a behavior. For example I would like a component to decide for itself if it should be visible in the current context by evaluating stuff like login status of the user or it's content. Would be great if I could get some pointers on how to do this in a sensible way with wicket. Cheers, Chris - 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: WicketStuff artifacts naming strategy
The Maven artifact id is not important. The name of the produced .jar is what matters, right ? Harald just said that there is a convention in OSGi world to work with such named .jars (com.acme.blah) On Thu, Jun 30, 2011 at 6:31 PM, James Carman jcar...@carmanconsulting.com wrote: And repetitive Sent from my Android device. Please excuse typos and brevity. On Jun 30, 2011 11:12 AM, Bruno Borges bruno.bor...@gmail.com wrote: Yes, me neither. That's why I asked. The preffix I'm using is wicketstuff-, but Harald mentioned org.wicketstuff. I don't want to use that, it's too verbose. *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Thu, Jun 30, 2011 at 12:06 PM, James Carman ja...@carmanconsulting.comwrote: I haven't seen that syntax before of having the group id in the artifact id, at least not with the longer group ids (reverse domain). On Thu, Jun 30, 2011 at 11:02 AM, Bruno Borges bruno.bor...@gmail.com wrote: The preffix is 'wicketstuff-', not 'org.wicketstuff.' Is this ok? *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Wed, Jun 29, 2011 at 4:01 AM, Harald Wellmann harald.wellm...@gmx.de wrote: 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-unsubscribe@wicket.**apache.org 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 -- 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: WicketStuff artifacts naming strategy
i think the groupid/artifactid do matter because some containers have bundle deployers that pull things from the maven repo...i think -igor On Thu, Jun 30, 2011 at 8:38 AM, Martin Grigorov mgrigo...@apache.org wrote: The Maven artifact id is not important. The name of the produced .jar is what matters, right ? Harald just said that there is a convention in OSGi world to work with such named .jars (com.acme.blah) On Thu, Jun 30, 2011 at 6:31 PM, James Carman jcar...@carmanconsulting.com wrote: And repetitive Sent from my Android device. Please excuse typos and brevity. On Jun 30, 2011 11:12 AM, Bruno Borges bruno.bor...@gmail.com wrote: Yes, me neither. That's why I asked. The preffix I'm using is wicketstuff-, but Harald mentioned org.wicketstuff. I don't want to use that, it's too verbose. *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Thu, Jun 30, 2011 at 12:06 PM, James Carman ja...@carmanconsulting.comwrote: I haven't seen that syntax before of having the group id in the artifact id, at least not with the longer group ids (reverse domain). On Thu, Jun 30, 2011 at 11:02 AM, Bruno Borges bruno.bor...@gmail.com wrote: The preffix is 'wicketstuff-', not 'org.wicketstuff.' Is this ok? *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Wed, Jun 29, 2011 at 4:01 AM, Harald Wellmann harald.wellm...@gmx.de wrote: 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-unsubscribe@wicket.**apache.org 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 -- 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: Unwanted authentication persistence
I figured out that the sign-in panel was storing the authentication data in a cookie from when we had first tried it before we turned off the remember-me option and now it's getting it back from there even though we have turned off that option. Was a simple tweak to fix it. On 6/28/2011 3:15 PM, sreed wrote: We are using Jetty which has no session persistence by default. Is it possible that Wicket is persisting sessions somehow? What else might be causing this? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Unwanted-authentication-persistence-tp3631027p3631188.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: Behaviors beforeRender broken
I tried adding a dummy implementation of that interface that logs every method call to custom subclass of link. While the links get rendered regularly the only methods that get invoked are isTemporary, bind, isEnabled and detach. All other methods are never called, am I missing something here? Am 30.06.2011 17:35, schrieb Igor Vaynberg: mixin IComponentConfigurationBehavior (1.4.17+ i believe) and implement visibility toggling in onconfigure(component) of your behavior. -igor On Thu, Jun 30, 2011 at 7:03 AM, Christian Huberhub...@butterbrot.org wrote: Hi all, I wanted to use a Behavior to customize the components in my application (Wicket 1.4.2) by modifying some properties in the behaviors beforeRender method. But I had to find that this method is never called, neither is afterRender. The other methods of the behavior are invoked but those are not suitable for my needs (can't modify visibilty e.g. because that yields an exception). I found an bug entry about this problem and acording to the comments this seems to be a conecptual problem and won't be fixed. So I was wondering if there is a suitable alternative to be used instead of a behavior. For example I would like a component to decide for itself if it should be visible in the current context by evaluating stuff like login status of the user or it's content. Would be great if I could get some pointers on how to do this in a sensible way with wicket. Cheers, Chris - 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: Behaviors beforeRender broken
Are you still talking about 1.4.2 or for 1.4.16/17 ? If the problem still exists in 1.4.17 then please create a ticket with a quickstart. On Thu, Jun 30, 2011 at 7:48 PM, Christian Huber hub...@butterbrot.org wrote: I tried adding a dummy implementation of that interface that logs every method call to custom subclass of link. While the links get rendered regularly the only methods that get invoked are isTemporary, bind, isEnabled and detach. All other methods are never called, am I missing something here? Am 30.06.2011 17:35, schrieb Igor Vaynberg: mixin IComponentConfigurationBehavior (1.4.17+ i believe) and implement visibility toggling in onconfigure(component) of your behavior. -igor On Thu, Jun 30, 2011 at 7:03 AM, Christian Huberhub...@butterbrot.org wrote: Hi all, I wanted to use a Behavior to customize the components in my application (Wicket 1.4.2) by modifying some properties in the behaviors beforeRender method. But I had to find that this method is never called, neither is afterRender. The other methods of the behavior are invoked but those are not suitable for my needs (can't modify visibilty e.g. because that yields an exception). I found an bug entry about this problem and acording to the comments this seems to be a conecptual problem and won't be fixed. So I was wondering if there is a suitable alternative to be used instead of a behavior. For example I would like a component to decide for itself if it should be visible in the current context by evaluating stuff like login status of the user or it's content. Would be great if I could get some pointers on how to do this in a sensible way with wicket. Cheers, Chris - 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 -- 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: Behaviors beforeRender broken
just a hunch, but if the component to which the behavior is attached to is not visible then none of the methods like before/after render will be called since component is not rendering. -igor On Thu, Jun 30, 2011 at 9:48 AM, Christian Huber hub...@butterbrot.org wrote: I tried adding a dummy implementation of that interface that logs every method call to custom subclass of link. While the links get rendered regularly the only methods that get invoked are isTemporary, bind, isEnabled and detach. All other methods are never called, am I missing something here? Am 30.06.2011 17:35, schrieb Igor Vaynberg: mixin IComponentConfigurationBehavior (1.4.17+ i believe) and implement visibility toggling in onconfigure(component) of your behavior. -igor On Thu, Jun 30, 2011 at 7:03 AM, Christian Huberhub...@butterbrot.org wrote: Hi all, I wanted to use a Behavior to customize the components in my application (Wicket 1.4.2) by modifying some properties in the behaviors beforeRender method. But I had to find that this method is never called, neither is afterRender. The other methods of the behavior are invoked but those are not suitable for my needs (can't modify visibilty e.g. because that yields an exception). I found an bug entry about this problem and acording to the comments this seems to be a conecptual problem and won't be fixed. So I was wondering if there is a suitable alternative to be used instead of a behavior. For example I would like a component to decide for itself if it should be visible in the current context by evaluating stuff like login status of the user or it's content. Would be great if I could get some pointers on how to do this in a sensible way with wicket. Cheers, Chris - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: WicketStuff artifacts naming strategy
I seem to recall the Maven guys recommending against periods in artifactIds. Can't find the link for the info though... maybe it was just soething they mentioned in the class. The purpose was to reduce confusion between artifactIds and groupIds. -Clint On Thu, Jun 30, 2011 at 11:14 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: i think the groupid/artifactid do matter because some containers have bundle deployers that pull things from the maven repo...i think -igor On Thu, Jun 30, 2011 at 8:38 AM, Martin Grigorov mgrigo...@apache.org wrote: The Maven artifact id is not important. The name of the produced .jar is what matters, right ? Harald just said that there is a convention in OSGi world to work with such named .jars (com.acme.blah) On Thu, Jun 30, 2011 at 6:31 PM, James Carman jcar...@carmanconsulting.com wrote: And repetitive Sent from my Android device. Please excuse typos and brevity. On Jun 30, 2011 11:12 AM, Bruno Borges bruno.bor...@gmail.com wrote: Yes, me neither. That's why I asked. The preffix I'm using is wicketstuff-, but Harald mentioned org.wicketstuff. I don't want to use that, it's too verbose. *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Thu, Jun 30, 2011 at 12:06 PM, James Carman ja...@carmanconsulting.comwrote: I haven't seen that syntax before of having the group id in the artifact id, at least not with the longer group ids (reverse domain). On Thu, Jun 30, 2011 at 11:02 AM, Bruno Borges bruno.bor...@gmail.com wrote: The preffix is 'wicketstuff-', not 'org.wicketstuff.' Is this ok? *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Wed, Jun 29, 2011 at 4:01 AM, Harald Wellmann harald.wellm...@gmx.de wrote: 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-unsubscribe@wicket.**apache.org 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 -- 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: WicketStuff artifacts naming strategy
The Pull request #42 is ready to be merged. Please review and vote. https://github.com/wicketstuff/core/pull/42 There's one modification I made that is not related to the repository. It is here: https://github.com/wicketstuff/core/pull/42/files#r55594 *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Thu, Jun 30, 2011 at 2:22 PM, Clint Checketts checke...@gmail.comwrote: I seem to recall the Maven guys recommending against periods in artifactIds. Can't find the link for the info though... maybe it was just soething they mentioned in the class. The purpose was to reduce confusion between artifactIds and groupIds. -Clint On Thu, Jun 30, 2011 at 11:14 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i think the groupid/artifactid do matter because some containers have bundle deployers that pull things from the maven repo...i think -igor On Thu, Jun 30, 2011 at 8:38 AM, Martin Grigorov mgrigo...@apache.org wrote: The Maven artifact id is not important. The name of the produced .jar is what matters, right ? Harald just said that there is a convention in OSGi world to work with such named .jars (com.acme.blah) On Thu, Jun 30, 2011 at 6:31 PM, James Carman jcar...@carmanconsulting.com wrote: And repetitive Sent from my Android device. Please excuse typos and brevity. On Jun 30, 2011 11:12 AM, Bruno Borges bruno.bor...@gmail.com wrote: Yes, me neither. That's why I asked. The preffix I'm using is wicketstuff-, but Harald mentioned org.wicketstuff. I don't want to use that, it's too verbose. *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Thu, Jun 30, 2011 at 12:06 PM, James Carman ja...@carmanconsulting.comwrote: I haven't seen that syntax before of having the group id in the artifact id, at least not with the longer group ids (reverse domain). On Thu, Jun 30, 2011 at 11:02 AM, Bruno Borges bruno.bor...@gmail.com wrote: The preffix is 'wicketstuff-', not 'org.wicketstuff.' Is this ok? *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Wed, Jun 29, 2011 at 4:01 AM, Harald Wellmann harald.wellm...@gmx.de wrote: 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-unsubscribe@wicket.**apache.org 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 -- 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: jsp check AuthenticatedWebSession.get().isSignedIn()
Hi, you can share this info in the HttpServletSession. On Tue, Jun 28, 2011 at 4:57 PM, fachhoch fachh...@gmail.com wrote: I have very few jsp pages and for these pages I want to check that user is authenticated. I tried calling AuthenticatedWebSession.get().isSignedIn() and I getting this exception java.lang.IllegalStateException: you can only locate or create sessions in the context of a request cycle at org.apache.wicket.Session.findOrCreate(Session.java:208) at org.apache.wicket.Session.get(Session.java:252) at org.apache.wicket.authentication.AuthenticatedWebSession.get(AuthenticatedWebSession.java:40) at gov.hhs.acf.web.filter.JspSecurityFilter.doFilter(JspSecurityFilter.java:29) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1187) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:265) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275) at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:149) at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1187) at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1187) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:421) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:493) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:924) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:358) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:860) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:245) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:113) at org.eclipse.jetty.server.Server.handle(Server.java:335) at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:588) at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1029) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:549) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:211) at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:418) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:476) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436) at java.lang.Thread.run(Thread.java:619) please suggest me how check if user is authenticated in case of jsp pages ? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/jsp-check-AuthenticatedWebSession-get-isSignedIn-tp3631307p3631307.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 -- Pedro Henrique Oliveira dos Santos - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: jsp check AuthenticatedWebSession.get().isSignedIn()
If you are calling a jsp file, Wicket is not being processed. And so, Application.get() won't return a valid object. In your newSession() method, add something your project understand to HttpSession as Pedro said. *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Thu, Jun 30, 2011 at 3:52 PM, Pedro Santos pedros...@gmail.com wrote: Hi, you can share this info in the HttpServletSession. On Tue, Jun 28, 2011 at 4:57 PM, fachhoch fachh...@gmail.com wrote: I have very few jsp pages and for these pages I want to check that user is authenticated. I tried calling AuthenticatedWebSession.get().isSignedIn() and I getting this exception java.lang.IllegalStateException: you can only locate or create sessions in the context of a request cycle at org.apache.wicket.Session.findOrCreate(Session.java:208) at org.apache.wicket.Session.get(Session.java:252) at org.apache.wicket.authentication.AuthenticatedWebSession.get(AuthenticatedWebSession.java:40) at gov.hhs.acf.web.filter.JspSecurityFilter.doFilter(JspSecurityFilter.java:29) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1187) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:265) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275) at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:149) at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1187) at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1187) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:421) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:493) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:924) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:358) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:860) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:245) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:113) at org.eclipse.jetty.server.Server.handle(Server.java:335) at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:588) at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1029) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:549) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:211) at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:418) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:476) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436) at java.lang.Thread.run(Thread.java:619) please suggest me how check if user is authenticated in case of jsp pages ? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/jsp-check-AuthenticatedWebSession-get-isSignedIn-tp3631307p3631307.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 -- Pedro Henrique Oliveira dos Santos - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: jsp check AuthenticatedWebSession.get().isSignedIn()
WicketSessionFilter is also an option. On Thu, Jun 30, 2011 at 9:59 PM, Bruno Borges bruno.bor...@gmail.com wrote: If you are calling a jsp file, Wicket is not being processed. And so, Application.get() won't return a valid object. In your newSession() method, add something your project understand to HttpSession as Pedro said. *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Thu, Jun 30, 2011 at 3:52 PM, Pedro Santos pedros...@gmail.com wrote: Hi, you can share this info in the HttpServletSession. On Tue, Jun 28, 2011 at 4:57 PM, fachhoch fachh...@gmail.com wrote: I have very few jsp pages and for these pages I want to check that user is authenticated. I tried calling AuthenticatedWebSession.get().isSignedIn() and I getting this exception java.lang.IllegalStateException: you can only locate or create sessions in the context of a request cycle at org.apache.wicket.Session.findOrCreate(Session.java:208) at org.apache.wicket.Session.get(Session.java:252) at org.apache.wicket.authentication.AuthenticatedWebSession.get(AuthenticatedWebSession.java:40) at gov.hhs.acf.web.filter.JspSecurityFilter.doFilter(JspSecurityFilter.java:29) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1187) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:265) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275) at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:149) at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1187) at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1187) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:421) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:493) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:924) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:358) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:860) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:245) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:113) at org.eclipse.jetty.server.Server.handle(Server.java:335) at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:588) at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1029) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:549) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:211) at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:418) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:476) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436) at java.lang.Thread.run(Thread.java:619) please suggest me how check if user is authenticated in case of jsp pages ? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/jsp-check-AuthenticatedWebSession-get-isSignedIn-tp3631307p3631307.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 -- Pedro Henrique Oliveira dos Santos - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin
Re: Behaviors beforeRender broken
I just created a quick start with 1.4.17 where I added my behavior to the single label created in the template page. This time in addition to the methods mentioned below also getStatelessHint gets called but still beforeRender etc are not called. The label is still fully rendered. As Martin requested I created a JIRA issue for this with my quickstart attached. The issue can be found here https://issues.apache.org/jira/browse/WICKET-3854 Please let me know if that is sufficient or how I can provide more information. Am 30.06.2011 19:04, schrieb Igor Vaynberg: just a hunch, but if the component to which the behavior is attached to is not visible then none of the methods like before/after render will be called since component is not rendering. -igor On Thu, Jun 30, 2011 at 9:48 AM, Christian Huberhub...@butterbrot.org wrote: I tried adding a dummy implementation of that interface that logs every method call to custom subclass of link. While the links get rendered regularly the only methods that get invoked are isTemporary, bind, isEnabled and detach. All other methods are never called, am I missing something here? Am 30.06.2011 17:35, schrieb Igor Vaynberg: mixin IComponentConfigurationBehavior (1.4.17+ i believe) and implement visibility toggling in onconfigure(component) of your behavior. -igor On Thu, Jun 30, 2011 at 7:03 AM, Christian Huberhub...@butterbrot.org wrote: Hi all, I wanted to use a Behavior to customize the components in my application (Wicket 1.4.2) by modifying some properties in the behaviors beforeRender method. But I had to find that this method is never called, neither is afterRender. The other methods of the behavior are invoked but those are not suitable for my needs (can't modify visibilty e.g. because that yields an exception). I found an bug entry about this problem and acording to the comments this seems to be a conecptual problem and won't be fixed. So I was wondering if there is a suitable alternative to be used instead of a behavior. For example I would like a component to decide for itself if it should be visible in the current context by evaluating stuff like login status of the user or it's content. Would be great if I could get some pointers on how to do this in a sensible way with wicket. Cheers, Chris - 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 - 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: WicketStuff artifacts naming strategy
Hell, it has been merged. pull request #42 merged to master. I've updated the wiki already asking for new JAR modules to follow this naming strategy. Thank you all for the support. *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Thu, Jun 30, 2011 at 3:14 PM, Bruno Borges bruno.bor...@gmail.comwrote: The Pull request #42 is ready to be merged. Please review and vote. https://github.com/wicketstuff/core/pull/42 There's one modification I made that is not related to the repository. It is here: https://github.com/wicketstuff/core/pull/42/files#r55594 *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Thu, Jun 30, 2011 at 2:22 PM, Clint Checketts checke...@gmail.comwrote: I seem to recall the Maven guys recommending against periods in artifactIds. Can't find the link for the info though... maybe it was just soething they mentioned in the class. The purpose was to reduce confusion between artifactIds and groupIds. -Clint On Thu, Jun 30, 2011 at 11:14 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i think the groupid/artifactid do matter because some containers have bundle deployers that pull things from the maven repo...i think -igor On Thu, Jun 30, 2011 at 8:38 AM, Martin Grigorov mgrigo...@apache.org wrote: The Maven artifact id is not important. The name of the produced .jar is what matters, right ? Harald just said that there is a convention in OSGi world to work with such named .jars (com.acme.blah) On Thu, Jun 30, 2011 at 6:31 PM, James Carman jcar...@carmanconsulting.com wrote: And repetitive Sent from my Android device. Please excuse typos and brevity. On Jun 30, 2011 11:12 AM, Bruno Borges bruno.bor...@gmail.com wrote: Yes, me neither. That's why I asked. The preffix I'm using is wicketstuff-, but Harald mentioned org.wicketstuff. I don't want to use that, it's too verbose. *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Thu, Jun 30, 2011 at 12:06 PM, James Carman ja...@carmanconsulting.comwrote: I haven't seen that syntax before of having the group id in the artifact id, at least not with the longer group ids (reverse domain). On Thu, Jun 30, 2011 at 11:02 AM, Bruno Borges bruno.bor...@gmail.com wrote: The preffix is 'wicketstuff-', not 'org.wicketstuff.' Is this ok? *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Wed, Jun 29, 2011 at 4:01 AM, Harald Wellmann harald.wellm...@gmx.de wrote: 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-unsubscribe@wicket.**apache.org 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 -- 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
What is the status of wicketstuff dojo?
Hi, Does anyone know what the status of wicketstuff dojo is? I have an application that was written in Wicket 1.3 which I have converted to 1.4, likewise for dojo. However there are classes missing from the 1.4 release that were being used in the 1.3 release, specifically: org.wicketstuff.dojo.markup.html.list.DojoOrderableListContainer; org.wicketstuff.dojo.markup.html.list.DojoOrderableRepeatingView; It seems that there is only 'toaster' in the org/wicketstuff/dojo/markup/html directory: https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/dojo-parent/dojo-api/src/main/java/org/wicketstuff/dojo11/markup/html Is the 1.3 source available anywhere? Is anyone maintaining dojo? thanks, Steve
Re: What is the status of wicketstuff dojo?
I found the old source. There is a LOT of stuff missing in the 1.4 release compared to the 1.3 release. 1.3: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/attic/wicketstuff-dojo/src/main/java/org/wicketstuff/dojo/markup/html/ 1.4: https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/dojo-parent/dojo-api/src/main/java/org/wicketstuff/dojo11/markup/html Is someone able to migrate that and push a release? cheers, Steve On 01/07/2011, at 11:51 AM, Steve Swinsburg wrote: Hi, Does anyone know what the status of wicketstuff dojo is? I have an application that was written in Wicket 1.3 which I have converted to 1.4, likewise for dojo. However there are classes missing from the 1.4 release that were being used in the 1.3 release, specifically: org.wicketstuff.dojo.markup.html.list.DojoOrderableListContainer; org.wicketstuff.dojo.markup.html.list.DojoOrderableRepeatingView; It seems that there is only 'toaster' in the org/wicketstuff/dojo/markup/html directory: https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/dojo-parent/dojo-api/src/main/java/org/wicketstuff/dojo11/markup/html Is the 1.3 source available anywhere? Is anyone maintaining dojo? thanks, Steve
Re: What is the status of wicketstuff dojo?
That is the 1.5 branch of wicketstuff. The 1.4 is in https://github.com/wicketstuff/core/tree/core-1.4.x/jdk-1.5-parent/dojo-parent/dojo-api/src/main/java/org/wicketstuff/dojo11/markup/html Dojo is disabled in the 1.5 branch (enabled in 1.4), probably because there was noone to maintain it. Attila 2011/7/1 Steve Swinsburg steve.swinsb...@gmail.com I found the old source. There is a LOT of stuff missing in the 1.4 release compared to the 1.3 release. 1.3: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/attic/wicketstuff-dojo/src/main/java/org/wicketstuff/dojo/markup/html/ 1.4: https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/dojo-parent/dojo-api/src/main/java/org/wicketstuff/dojo11/markup/html Is someone able to migrate that and push a release? cheers, Steve On 01/07/2011, at 11:51 AM, Steve Swinsburg wrote: Hi, Does anyone know what the status of wicketstuff dojo is? I have an application that was written in Wicket 1.3 which I have converted to 1.4, likewise for dojo. However there are classes missing from the 1.4 release that were being used in the 1.3 release, specifically: org.wicketstuff.dojo.markup.html.list.DojoOrderableListContainer; org.wicketstuff.dojo.markup.html.list.DojoOrderableRepeatingView; It seems that there is only 'toaster' in the org/wicketstuff/dojo/markup/html directory: https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/dojo-parent/dojo-api/src/main/java/org/wicketstuff/dojo11/markup/html Is the 1.3 source available anywhere? Is anyone maintaining dojo? thanks, Steve
