Re: Issue upgrading to Wicket6 from wicket 1.5.9
Hi,
Try to get thread dump of the Maven process. It may tell you what is
hanging.
In Unix like systems you can use:
kill -3 mavenProcessId
On any system you can use JDK's jps and jstack to get the dump as well.
On Fri, Oct 11, 2013 at 10:20 PM, Rob Alesi rob.al...@appdirect.com wrote:
Hey,
I am trying to upgrade from wicket 6, and when I build using Maven, the
compile hangs. I dont get any error messages and there is no output or
anything.
my setup
- JDK 1.7
- maven 3
maven setup
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version3.1/version
inheritedtrue/inherited
configuration
source1.7/source
target1.7/target
optimizetrue/optimize
debugtrue/debug
/configuration
dependencies
dependency
groupIdorg.codehaus.plexus/groupId
artifactIdplexus-compiler-javac/artifactId
version1.9.2/version
/dependency
/dependencies
/plugin
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
org.apache.wicket.version6.10.0/org.apache.wicket.version
powermock.version1.5.1/powermock.version
org.codehaus.jackson.version1.9.11/org.codehaus.jackson.version
org.apache.cxf.version2.5.8/org.apache.cxf.version
org.springframework.security.version3.1.3.RELEASE/org.springframework.security.version
org.springframework.version3.1.2.RELEASE/org.springframework.version
org.hibernate.version4.1.9.Final/org.hibernate.version
org.apache.httpcomponents.version4.2.5/org.apache.httpcomponents.version
/properties
dependency
groupIdorg.wicketstuff/groupId
artifactIdwicketstuff-annotation/artifactId
version${org.apache.wicket.version}/version
/dependency
dependency
groupIdorg.wicketstuff/groupId
artifactIdwicketstuff-tinymce/artifactId
version${org.apache.wicket.version}/version
/dependency
dependency
groupIdorg.apache.wicket/groupId
artifactIdwicket-datetime/artifactId
version${org.apache.wicket.version}/version
/dependency
dependency
groupIdorg.apache.wicket/groupId
artifactIdwicket-extensions/artifactId
version${org.apache.wicket.version}/version
/dependency
dependency
groupIdorg.apache.wicket/groupId
artifactIdwicket-auth-roles/artifactId
version${org.apache.wicket.version}/version
/dependency
dependency
groupIdorg.apache.wicket/groupId
artifactIdwicket-spring/artifactId
version${org.apache.wicket.version}/version
/dependency
dependency
groupIdorg.apache.wicket/groupId
artifactIdwicket/artifactId
version${org.apache.wicket.version}/version
typepom/type
/dependency
The compile just hangs. Any help would be appreciated, if you need more
info please let me know.
thanks,
Rob
--
This communication and any attachments may contain Confidential Information
of AppDirect, Inc. All unauthorized use, disclosure or distribution is
prohibited. If you are not the intended recipient, please notify AppDirect,
Inc. immediately and destroy all copies of this communication. Thank you.
Re: getPage(pageReference) == null since Wicket 6.10.0
Am 12.10.2013 21:58, schrieb Martin Grigorov: The problem is that most of us use Tomcat/Jetty and we don't test other web containers. Hi, I always saw the decision between full Java EE and Spring Framework, and Spring always made the impression to be a solution for all problems and you have to solve all problems with spring forever. So I didn't want to open this door. Some features of the big application servers where comfortable (CDI, transaction management, container based security) and I watched Adam Bien and started to shout Hallelujah after his videos ;-) Despite that I see the problems of a commitment to a single applications server and would like a small modular solution using Tomcat. My applications are business applications implementing a workflow based on CRUD operations with JPA on open source relational databases. Can you please give me some hints for a minimum stack of doing that with Tomcat without reinventing the wheel: - with or without Spring? - What are key libs (Guice, http://jotm.ow2.org/, ...) - How do you it implement, what are your suggestions? - What is important not to forget? Dieter -- Tremel Computerhttp://www.tremel-computer.de Dieter Tremel mailto:tre...@tremel-computer.de Rebenring 16 Tel +49 871 9357080 84032 Altdorf Fax +49 871 9357081 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: getPage(pageReference) == null since Wicket 6.10.0
Hi, On Mon, Oct 14, 2013 at 10:10 AM, Dieter Tremel tre...@tremel-computer.dewrote: Am 12.10.2013 21:58, schrieb Martin Grigorov: The problem is that most of us use Tomcat/Jetty and we don't test other web containers. Hi, I always saw the decision between full Java EE and Spring Framework, and Spring always made the impression to be a solution for all problems and you have to solve all problems with spring forever. So I didn't want to open this door. Some features of the big application servers where comfortable (CDI, transaction management, container based security) and I watched Adam Bien and started to shout Hallelujah after his videos ;-) Despite that I see the problems of a commitment to a single applications server and would like a small modular solution using Tomcat. My applications are business applications implementing a workflow based on CRUD operations with JPA on open source relational databases. Can you please give me some hints for a minimum stack of doing that with Tomcat without reinventing the wheel: - with or without Spring? - What are key libs (Guice, http://jotm.ow2.org/, ...) - How do you it implement, what are your suggestions? - What is important not to forget? I personally prefer Spring for middleware. You can take a look at https://github.com/jWeekend/LegUp/tree/master/wicket-spring-jpa for a simple app. It uses Spring for DI, Hibernate as JPA and transactions provider. I haven't used CDI professionally so I cannot comment on it. My only experience is with Wicket CDI module and so far I haven't seen a feature which is not supported already by Spring. I have seen problems with different CDI implementations though. I think you should use whatever you feel most comfortable with, i.e. whatever you know the best and causes you the least troubles in your daily work. Dieter -- Tremel Computerhttp://www.tremel-computer.de Dieter Tremel mailto:tre...@tremel-computer.de Rebenring 16 Tel +49 871 9357080 84032 Altdorf Fax +49 871 9357081 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Solution to DatePicket with IE 9 not showing up
Hi, I had a problem in Wicket6 with a datepicker that did not show up in IE9 and saw that more had that issue but I could not find any solution in the mail archives. Debugging the issue I saw that the problem was that Yahoo.Dom.get() in IE grabbed the value from the wicket:id attribute instead of the id attribute. In my case the generated id (beforedate7) did not match the wicket id (beforedate) so the Yahoo.Dom.get() implementation could not find the DOM object. To solve this I made sure that the generated id matched my wicket:id by setting the markupId on the DateTextField to the same value as the wicket:id value. Other solutions I could see is to make sure that the wicket:id attributes does not show up. In your web application use getMarkupSettings().setStripWicketTags(true). You can also make sure to not use the development mode when you deploy your application (that also removes the wicket:id attributes). /Marcus Marcus Ludvigsson mobile: 004670 78 10 259 | mar...@lubbit.se | http://www.lubbit.se
Re: getPage(pageReference) == null since Wicket 6.10.0
Our current stack for big applications (10-20k concurrent users) is: - wicket 6 (we upgrade with every release, across all projects almost simultaneously, couple of million lines of code, about 3000 pages, 3000 panels, etc) - spring for wiring hibernate, cxf and classpath scans, and some DI - CDI for conversation support (in one application) - Hibernate - tomcat Our future architecture to which we are planning to migrate to entails: - wicket - JEE7 (JPA, EJB, CDI, JMS, JBatch, JAXRS, JAXWS, etc.) - JBoss (wildfly) Basically we got convinced that we implement everything ourselves in our current software stack and that we probably could scrap a lot of code and configuration deploying to an actual JEE server. While spring can be nice, we never fully adopted it and it is more in our way than a helpful service. Martijn On Mon, Oct 14, 2013 at 9:10 AM, Dieter Tremel tre...@tremel-computer.de wrote: Am 12.10.2013 21:58, schrieb Martin Grigorov: The problem is that most of us use Tomcat/Jetty and we don't test other web containers. Hi, I always saw the decision between full Java EE and Spring Framework, and Spring always made the impression to be a solution for all problems and you have to solve all problems with spring forever. So I didn't want to open this door. Some features of the big application servers where comfortable (CDI, transaction management, container based security) and I watched Adam Bien and started to shout Hallelujah after his videos ;-) Despite that I see the problems of a commitment to a single applications server and would like a small modular solution using Tomcat. My applications are business applications implementing a workflow based on CRUD operations with JPA on open source relational databases. Can you please give me some hints for a minimum stack of doing that with Tomcat without reinventing the wheel: - with or without Spring? - What are key libs (Guice, http://jotm.ow2.org/, ...) - How do you it implement, what are your suggestions? - What is important not to forget? Dieter -- Tremel Computerhttp://www.tremel-computer.de Dieter Tremel mailto:tre...@tremel-computer.de Rebenring 16 Tel +49 871 9357080 84032 Altdorf Fax +49 871 9357081 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
unwanted DefaultPageManagerProvider
Hi
we seem to face a little problem here with wicket 6.11:
Application.class:708
setPageManagerProvider(new DefaultPageManagerProvider(this));
sets the default provider here. Lateron [during init()] we replace this
one by using the snippet from HttpSessionDataStore's javadocs:
setPageManagerProvider(new DefaultPageManagerProvider() {
protected IDataStore newDataStore() {
return new HttpSessionDataStore(
pageManagerContext, new PageNumberEvictionStrategy(20));
}
}
for clustering.
Now the problem is, if anyone (in between) is able to call
getPageManagerProvider().get() on the application, this would (and does)
create a dangeling pageSavingThread by wrapping the unwanted
defaultProvider into an AsynchronousDataStore.
... bad thing.
We seem to have this situation, where an Initializer is calling the
above code.
Now for the question: what is the suggested way to register a
PageManagerProvider BEFORE anyone asks for it?
cu uwe
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: unwanted DefaultPageManagerProvider
On 14.10.2013 21:10, uwe schaefer wrote: Now for the question: what is the suggested way to register a PageManagerProvider BEFORE anyone asks for it? PS: rather than an initializer being the culprit, could it also be a racecondition with clustering and public void sessionUnbound(final String sessionId) being called before init() returns? cu uwe - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
