Re: getPage(pageReference) == null since Wicket 6.10.0
Thank You, will try that. Dieter Am 06.11.2013 17:14, schrieb David Beer: > JBoss AS 7 and Wildfly 8 work nicely with Wicket. > > > On 6 November 2013 15:25, Ondrej Zizka wrote: > >> Try the JBoss EAP 6.1: >> http://www.jboss.org/jbossas/downloads/ >> >> I didn't have much trouble using that with Wicket 6.x. >> >> Ondra >> >> >> >> >> On 5.11.2013 18:19, Dieter Tremel wrote: >> >>> Am 12.10.2013 12:19, schrieb Dieter Tremel: >>> Sometimes I have the impression that a Glassfish and wicket are not a couple in great love. >>> >>> Seems that Glassfish and Oracle are not in great love either, since >>> commercial Glassfish is dead, and this is no good future for the open >>> source edition: >>> - 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
JBoss AS 7 and Wildfly 8 work nicely with Wicket. On 6 November 2013 15:25, Ondrej Zizka wrote: > Try the JBoss EAP 6.1: > http://www.jboss.org/jbossas/downloads/ > > I didn't have much trouble using that with Wicket 6.x. > > Ondra > > > > > On 5.11.2013 18:19, Dieter Tremel wrote: > >> Am 12.10.2013 12:19, schrieb Dieter Tremel: >> >>> Sometimes I have the impression that a Glassfish and wicket are not a >>> couple in great love. >>> >> >> Seems that Glassfish and Oracle are not in great love either, since >> commercial Glassfish is dead, and this is no good future for the open >> source edition: >> >> https://blogs.oracle.com/theaquarium/entry/java_ee_and_glassfish_server >> >> Dieter >> >> - >> 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: getPage(pageReference) == null since Wicket 6.10.0
Try the JBoss EAP 6.1: http://www.jboss.org/jbossas/downloads/ I didn't have much trouble using that with Wicket 6.x. Ondra On 5.11.2013 18:19, Dieter Tremel wrote: Am 12.10.2013 12:19, schrieb Dieter Tremel: Sometimes I have the impression that a Glassfish and wicket are not a couple in great love. Seems that Glassfish and Oracle are not in great love either, since commercial Glassfish is dead, and this is no good future for the open source edition: https://blogs.oracle.com/theaquarium/entry/java_ee_and_glassfish_server Dieter - 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: getPage(pageReference) == null since Wicket 6.10.0
Am 12.10.2013 12:19, schrieb Dieter Tremel: > Sometimes I have the impression that a Glassfish and wicket are not a > couple in great love. Seems that Glassfish and Oracle are not in great love either, since commercial Glassfish is dead, and this is no good future for the open source edition: https://blogs.oracle.com/theaquarium/entry/java_ee_and_glassfish_server Dieter - 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
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 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
Re: getPage(pageReference) == null since Wicket 6.10.0
Hi, On Mon, Oct 14, 2013 at 10:10 AM, Dieter Tremel 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? > 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 > >
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
On Sat, Oct 12, 2013 at 1:19 PM, Dieter Tremel wrote:
> Thank you Sven.
>
> I am glad that it is well known and will be fixed in 6.12, and little
> bid sad about the hours I spent of studying my code and testing. I
> should have asked more early in the mailing list, your support is always
> great.
>
> Sometimes I have the impression that a Glassfish and wicket are not a
> couple in great love.
>
My all time favorite Java EE server is WebSphere. Not sure how much IBM
paid SUN/Oracle to get certified but you can expect many problems if you
have to deploy your app on this beast.
The problem is that most of us use Tomcat/Jetty and we don't test other web
containers.
> Thank you very much
> Dieter
>
> Am 12.10.2013 10:47, schrieb Sven Meier:
> > See WICKET-5380
> >
> > Sven
> >
> > On 10/12/2013 10:20 AM, Dieter Tremel wrote:
> >> Hello wicket-community,
> >>
> >> in the last time I had to work on another project, so my wicket-work
> >> paused and I just upgraded to the new versions.
> >>
> >> So I was rather astonished that the mechanism I implemented for the
> >> return page after canceling an edit was not working any more, since
> >> getPage(pageref) returned null.
> >>
> >> After a lot of tests I know that this came from wicket 6.10.0 on, in
> >> 6.9.0 the code was working correctly. I also recognize, that the newer
> >> versions provide a new page id, if I use the URL with the old pageId
> >> manually, so in 6.10.0 the page is expired, whereas in 6.9.0 it is not.
> >> Strange for me.
> >>
> >> I use CDI and Glassfish 3.1.2 and have found the issues fixed in 6.10.0,
> >> that could be related:
> >> WICKET-5164 - PageStoreManager.SessionEntry keeps outdated sessionId
> >> when container changes sessionId
> >> WICKET-5309 - No page id appended to some stateful pages using repeaters
> >>
> >> Any idea what the problem could be and how I could fix it?
> >>
> >> Thank You
> >> Dieter
> >>
> >> My code is:
> >>
> >> Call of page:
> >> final PageReference pageReference = getPage().getPageReference();
> >> logger.log(Level.INFO, "Backpage reference of EntityCrudLink: {0}
> >> ({1})", new Object[]{pageReference, pageReference.getPageId()});
> >> setResponsePage(new
> >> EntityEditPage(EntityModelFactory.createEntityModel(editRecord),
> >> crudView, pageReference));
> >>
> >> Edit Page:
> >> The PageReference prevPageRef is set in constructor.
> >>
> >> Link cancelButton = new Link("cancelButton", new
> >> ResourceModel("CancelLabel")) {
> >>private static final long serialVersionUID = 1L;
> >>
> >>@Override
> >>public void onClick() {
> >>IModel infoModel;
> >>
> >>... define infoModel
> >>
> >>getSession().info(infoModel.getObject());
> >>setResponsePage(prevPageRef.getPage());
> >>}
> >> };
> >>
> >> -
> >> 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
> >
>
>
> --
> 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
Thank you Sven.
I am glad that it is well known and will be fixed in 6.12, and little
bid sad about the hours I spent of studying my code and testing. I
should have asked more early in the mailing list, your support is always
great.
Sometimes I have the impression that a Glassfish and wicket are not a
couple in great love.
Thank you very much
Dieter
Am 12.10.2013 10:47, schrieb Sven Meier:
> See WICKET-5380
>
> Sven
>
> On 10/12/2013 10:20 AM, Dieter Tremel wrote:
>> Hello wicket-community,
>>
>> in the last time I had to work on another project, so my wicket-work
>> paused and I just upgraded to the new versions.
>>
>> So I was rather astonished that the mechanism I implemented for the
>> return page after canceling an edit was not working any more, since
>> getPage(pageref) returned null.
>>
>> After a lot of tests I know that this came from wicket 6.10.0 on, in
>> 6.9.0 the code was working correctly. I also recognize, that the newer
>> versions provide a new page id, if I use the URL with the old pageId
>> manually, so in 6.10.0 the page is expired, whereas in 6.9.0 it is not.
>> Strange for me.
>>
>> I use CDI and Glassfish 3.1.2 and have found the issues fixed in 6.10.0,
>> that could be related:
>> WICKET-5164 - PageStoreManager.SessionEntry keeps outdated sessionId
>> when container changes sessionId
>> WICKET-5309 - No page id appended to some stateful pages using repeaters
>>
>> Any idea what the problem could be and how I could fix it?
>>
>> Thank You
>> Dieter
>>
>> My code is:
>>
>> Call of page:
>> final PageReference pageReference = getPage().getPageReference();
>> logger.log(Level.INFO, "Backpage reference of EntityCrudLink: {0}
>> ({1})", new Object[]{pageReference, pageReference.getPageId()});
>> setResponsePage(new
>> EntityEditPage(EntityModelFactory.createEntityModel(editRecord),
>> crudView, pageReference));
>>
>> Edit Page:
>> The PageReference prevPageRef is set in constructor.
>>
>> Link cancelButton = new Link("cancelButton", new
>> ResourceModel("CancelLabel")) {
>>private static final long serialVersionUID = 1L;
>>
>>@Override
>>public void onClick() {
>>IModel infoModel;
>>
>>... define infoModel
>>
>>getSession().info(infoModel.getObject());
>>setResponsePage(prevPageRef.getPage());
>>}
>> };
>>
>> -
>> 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
>
--
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
See WICKET-5380
Sven
On 10/12/2013 10:20 AM, Dieter Tremel wrote:
Hello wicket-community,
in the last time I had to work on another project, so my wicket-work
paused and I just upgraded to the new versions.
So I was rather astonished that the mechanism I implemented for the
return page after canceling an edit was not working any more, since
getPage(pageref) returned null.
After a lot of tests I know that this came from wicket 6.10.0 on, in
6.9.0 the code was working correctly. I also recognize, that the newer
versions provide a new page id, if I use the URL with the old pageId
manually, so in 6.10.0 the page is expired, whereas in 6.9.0 it is not.
Strange for me.
I use CDI and Glassfish 3.1.2 and have found the issues fixed in 6.10.0,
that could be related:
WICKET-5164 - PageStoreManager.SessionEntry keeps outdated sessionId
when container changes sessionId
WICKET-5309 - No page id appended to some stateful pages using repeaters
Any idea what the problem could be and how I could fix it?
Thank You
Dieter
My code is:
Call of page:
final PageReference pageReference = getPage().getPageReference();
logger.log(Level.INFO, "Backpage reference of EntityCrudLink: {0}
({1})", new Object[]{pageReference, pageReference.getPageId()});
setResponsePage(new
EntityEditPage(EntityModelFactory.createEntityModel(editRecord),
crudView, pageReference));
Edit Page:
The PageReference prevPageRef is set in constructor.
Link cancelButton = new Link("cancelButton", new
ResourceModel("CancelLabel")) {
private static final long serialVersionUID = 1L;
@Override
public void onClick() {
IModel infoModel;
... define infoModel
getSession().info(infoModel.getObject());
setResponsePage(prevPageRef.getPage());
}
};
-
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
