RE: T5 problem with multiple submit buttons
Is your form using a zone? If so, you may have hit this bug https://issues.apache.org/jira/browse/TAPESTRY-2324 cheers Ben > -Original Message- > From: Janko Muzykant [mailto:[EMAIL PROTECTED] > > > ups, sorry for not specifing that. i'm using latest tapestry 5.0.13. > > jm. > Massimo Lusetti wrote: > > > > On Wed, Jun 18, 2008 at 3:16 PM, Janko Muzykant > <[EMAIL PROTECTED]> wrote: > > > >> > >> hi, something is not working with handling events fired by > different > >> submit > >> buttons (or i have overlooked something...). that's my form: > > [..] > >> Could you suggest what is wrong here? > > > > Which versio are you using? > > > >
RE: T5: the scanner and JBoss
Ahh, that would be the difference. My templates are under WEB-INF\classes. > -Original Message- > From: Geoff Callender [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 2 October 2007 6:23 AM > To: Tapestry users > Subject: Re: T5: the scanner and JBoss > > Didn't work for me. My html templates are in subdirectories of WEB- > INF. Where are yours? > > On 01/10/2007, at 11:53 PM, Ben Sommerville wrote: > > > Switching to the JBoss classloader also makes auto-loading of html > > templates > > work for me. > > > > Have you tried the html auto-loading after making the classloader > > change? > > > > cheers > > Ben > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5: the scanner and JBoss
Switching to the JBoss classloader also makes auto-loading of html templates work for me. Have you tried the html auto-loading after making the classloader change? cheers Ben > -Original Message- > From: Geoff Callender [mailto:[EMAIL PROTECTED] > Sent: Monday, 1 October 2007 6:52 AM > To: Tapestry users > Subject: Re: T5: the scanner and JBoss > > Nice one, Ben. For auto-reloading class files that works > beautifully, and it avoids the class-loading problems that I found > Tapestry5DevClassLoader introduced. > > Does anyone know how to auto-reload T5 html templates in JBoss??? > > Alternatively, can someone point me to T5.0.5's template > scanning class? > > Thanks in advance, > Geoff > > On 30/09/2007, at 10:01 PM, Ben Sommerville wrote: > > > I found that using the JBoss UnifiedClassLoader instead of > the Tomcat > > class loader for web applications fixes the auto-reloading issues. > > > > To change this setting you need to edit the following file: > > JBoss 4.0.x > > /deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml > > JBoss 4.2.x > > /deploy/jbossweb.deployer/META-INF/jboss-service.xml > > > > Search for the attribute "UseJBossWebLoader" and set it to true. > > > > Note: Changing this may affect how your web-app resolves classes. > > I think the Tomcat classloader always loads classes for the webapp > > libs first, even if the class exists in a parent classloader. > > The JBoss classloader says it follows standard behaviour > and will use > > classes from the parent classloader over classes from the webapp. > > > > cheers > > Ben > > > >> -Original Message- > >> From: Geoff Callender [mailto:[EMAIL PROTECTED] > >> Sent: Sunday, 30 September 2007 12:07 AM > >> To: Tapestry users > >> Subject: Re: T5: the scanner and JBoss > >> > >> Nick, thanks for pointing out the earlier e-mail. > >> > >> Unfortunately, it doesn't deal with how to auto-reload html > >> templates. Tapestry5DevClassLoader only ensures class files > >> are reloaded. > >> > >> Any other suggestions? > >> > >> On 28/09/2007, at 9:24 PM, Nick Westgate wrote: > >> > >>> Geoff Callender wrote: > >>>> T5 isn't picking up changes to templates and component > >> classes in my > >>>> environment. T5.0.5 is a jar in an exploded WAR in an > >> exploded EAR, > >>>> which JBoss has been told to use (it's pointed to in > >>>> jboss-service.xml). When I make changes to the web app they are > >>> copied > >>>> immediately to the exploded ear but T5 just isn't > picking them up. > >>>> > >>>> I saw on Howard's blog that he'd had a problem with > >> JBoss/Tomcat... > >>>> > >>>> http://tapestryjava.blogspot.com/2007/02/fighting-with- > >>> tomcat.html > >>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=41664 > >>>> > >>>> ...but the 5.0.5 source looks like it has the necessary fix. > >>> Besides, > >>>> I'm using an ear that's already exploded so I shouldn't > >> be getting > >>>> Howard's problem. True? > >>>> > >>>> Does anyone have a theory on why it isn't working? > >>>> Alternatively can anyone point me to the scanner class so I can > >>> debug > >>>> what it isn't doing? > >>>> > >>>> Geoff > >>> > >>> > >>> The problem with Tomcat was identified in the following email as a > >>> classloader caching issue. I've not tested this though. > >>> > >>> Cheers, > >>> Nick. > >>> > >>> > >>> > >>> Original Message > >>> Subject: RE: T5 developing with WTP and TOMCAT > >>> Date: Wed, 5 Sep 2007 17:59:14 +0200 > >>> From: Brysbaert Gregory <[EMAIL PROTECTED]> > >>> Reply-To: Tapestry users > >>> To: Tapestry users > >>> > >>> Hello, > >>> > >>> About this topic, I tried some investigations on my side, > >> and I found > >>> out that the reason why classes don't auto-reload is that the > >>> WebappClassLoader of tomcat 5 (I currently use tomcat 5.0, > >> bu
RE: T5: the scanner and JBoss
I found that using the JBoss UnifiedClassLoader instead of the Tomcat
class loader for web applications fixes the auto-reloading issues.
To change this setting you need to edit the following file:
JBoss 4.0.x
/deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml
JBoss 4.2.x
/deploy/jbossweb.deployer/META-INF/jboss-service.xml
Search for the attribute "UseJBossWebLoader" and set it to true.
Note: Changing this may affect how your web-app resolves classes.
I think the Tomcat classloader always loads classes for the webapp
libs first, even if the class exists in a parent classloader.
The JBoss classloader says it follows standard behaviour and will use
classes from the parent classloader over classes from the webapp.
cheers
Ben
> -Original Message-
> From: Geoff Callender [mailto:[EMAIL PROTECTED]
> Sent: Sunday, 30 September 2007 12:07 AM
> To: Tapestry users
> Subject: Re: T5: the scanner and JBoss
>
> Nick, thanks for pointing out the earlier e-mail.
>
> Unfortunately, it doesn't deal with how to auto-reload html
> templates. Tapestry5DevClassLoader only ensures class files
> are reloaded.
>
> Any other suggestions?
>
> On 28/09/2007, at 9:24 PM, Nick Westgate wrote:
>
> > Geoff Callender wrote:
> > > T5 isn't picking up changes to templates and component
> classes in my
> > > environment. T5.0.5 is a jar in an exploded WAR in an
> exploded EAR,
> > > which JBoss has been told to use (it's pointed to in
> > > jboss-service.xml). When I make changes to the web app they are
> > copied
> > > immediately to the exploded ear but T5 just isn't picking them up.
> > >
> > > I saw on Howard's blog that he'd had a problem with
> JBoss/Tomcat...
> > >
> > > http://tapestryjava.blogspot.com/2007/02/fighting-with-
> > tomcat.html
> > > http://issues.apache.org/bugzilla/show_bug.cgi?id=41664
> > >
> > > ...but the 5.0.5 source looks like it has the necessary fix.
> > Besides,
> > > I'm using an ear that's already exploded so I shouldn't
> be getting
> > > Howard's problem. True?
> > >
> > > Does anyone have a theory on why it isn't working?
> > > Alternatively can anyone point me to the scanner class so I can
> > debug
> > > what it isn't doing?
> > >
> > > Geoff
> >
> >
> > The problem with Tomcat was identified in the following email as a
> > classloader caching issue. I've not tested this though.
> >
> > Cheers,
> > Nick.
> >
> >
> >
> > Original Message
> > Subject: RE: T5 developing with WTP and TOMCAT
> > Date: Wed, 5 Sep 2007 17:59:14 +0200
> > From: Brysbaert Gregory <[EMAIL PROTECTED]>
> > Reply-To: Tapestry users
> > To: Tapestry users
> >
> > Hello,
> >
> > About this topic, I tried some investigations on my side,
> and I found
> > out that the reason why classes don't auto-reload is that the
> > WebappClassLoader of tomcat 5 (I currently use tomcat 5.0,
> but I guess
> > it's the same on Tomcat 5.5) keeps in cache (in a Hashtable more
> > precisely) all classes it already loaded once. And this
> cache is never
> > cleared, except when the WebappClassLoader is stopped. So, when the
> > class file is modified on the disk, tapestry 5 clears its
> own cache,
> > and then asks to the parent classloader (WebAppClassLoader)
> to reload
> > the class, which then serves the previous version of the class from
> > its cache. The result is that the class is never actually updated
> > until the next restart of tomcat.
> >
> >
> > So, as a temporary solution, I tried to develop a class extending
> > WebappClassLoader that does not cache classes for packages
> containing
> > ".pages." and ".components.". The source of this class is :
> >
> >
> > public class Tapestry5DevClassLoader extends WebappClassLoader{
> >
> > private static String[] noCacheElements={".pages.","/
> > pages/",".components.","/components/"};
> >
> > public Tapestry5DevClassLoader() {
> > super();
> >
> > }
> >
> > public Tapestry5DevClassLoader(ClassLoader arg0) {
> > super(arg0);
> >
> > }
> >
> >
> >
> > @Override
> > protected InputStream findLoadedResource(String arg0) {
> > InputStream is=super.findLoadedResource(arg0);
> > if (is!=null){
> > if (isNoCacheElement(arg0))
> > return null;
> > }
> > return is;
> > }
> >
> > private boolean isNoCacheElement(String name){
> >
> > for (int i=0;i > if (name.indexOf(noCacheElements[i])>=0)
> > return true;
> > }
> >
> > return false;
> >
> > }
> >
> >
> >
> > }
> >
> >
> >
> >
> > To make it work, you have to do 2 things :
> > - Compile the class and add it to the server/classes (or
> server/lib if
> > you package it in a jar) directory of your tomc
RE: T5 on JDK 1.6 or newer
You can find that discussion here http://www.nabble.com/T5%3A-NPE-in-Base64InputStream-and-locked-waiting-Ch eckForUpdatesFilter-tf4058686.html > -Original Message- > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Saturday, 25 August 2007 3:35 AM > To: Tapestry users > Subject: Re: T5 on JDK 1.6 or newer > > An earlier posting on this list highlighted a bug in concurrency on > some version of JDK 1.6. Please check into that, the symptoms sound > similar to what you see. > > On 8/24/07, Stephan Schwab <[EMAIL PROTECTED]> wrote: > > > > We've been experiencing strange behaviour of our now > growing application > > Savila and as well with another project we are working on. > Both use Tapestry > > 5.0.5. Our development machines run with Mac OS X and we > use JDK 1.5 that > > comes with it. We deploy to Linux with Sun's JDK 1.6 and > Tomcat 6.0.10. > > > > Our application Savila ran fine on JDK 1.6 with Tapestry > 5.x until last week > > when we started to experience hangs. It seems that Tomcat > accepts the > > request, then our and Tapestry's code do something, but it > never finishes. > > When we hit the stop button in the browser and look at the > HTML we can see > > that it's all there. I'm not talking about form > submissions, but regular > > pages. > > > > This behaviour either starts after the app has been idle > for some time or in > > the middle of user actions. There is no load - just one > user active. With a > > significantly smaller application we see the same behaviour. > > > > Two days ago we switched to Sun JDK 1.5 for our large > application and since > > then there are no more hangs. > > > > There was a report here on the mailinglist about trouble > with a javassist > > and using a pre-release 3.6.0.CR1. At least on the Mac with > the pre-release > > JDK 1.6 that didn't not really solve the problem. It just > shows up later. > > > > At the moment I feel that Tapestry 5.0.5 requires JDK 1.5. > > > > Stephan > > > > -- > > View this message in context: > http://www.nabble.com/T5-on-JDK-1.6-or-newer-tf4324659.html#a12316191 > > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Howard M. Lewis Ship > Partner and Senior Architect at Feature50 > > Creator Apache Tapestry and Apache HiveMind > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5: NPE in Base64InputStream and locked/waitingCheckForUpdatesFilter
I finally had a chance to test this & I'm confident it is fixed. Under 6u1 I was consistently getting a deadlock, under 6u2 I cannot reproduce it. cheers Ben > -Original Message----- > From: Ben Sommerville [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 11 July 2007 4:24 PM > To: 'Tapestry users' > Subject: RE: T5: NPE in Base64InputStream and > locked/waitingCheckForUpdatesFilter > > One work around that I found is to create the read/write lock in > ConcurrentBarrier in "fair" mode instead of the default mode. > (fair mode changes the algorithm used to decide which thread > gets the lock next) > > That worked for me but subjectively things seemed a little slower > (no actual measurement so take that for what it is worth) > > If it is fixed in 6u2 then I'd be tempted just to document the > problem with 6u1 :) > > cheers > Ben > > PS: I'll try to actually confirm that is it fixed in the next > few days... may not get to it till the weekend tho > > > > -Original Message- > > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, 11 July 2007 4:14 PM > > To: Tapestry users > > Subject: Re: T5: NPE in Base64InputStream and > > locked/waitingCheckForUpdatesFilter > > > > Great find! People may need to deploy on JDK 1.5 to see if > that's the > > underlying cause. > > > > I wonder if we could create a work around by setting a wait time to > > acquire the read lock? In a loop? > > > > On 7/10/07, Ben Sommerville <[EMAIL PROTECTED]> wrote: > > > If you are running under jdk 6u1 and tapestry 5.0.5 (or > > greater) then > > > there is > > > a jvm bug that can cause a deadlock. > > > > > > The bug report is at > > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6571733. > > > It is supposed to be fixed in jdk 6u2 (which was release > > recently) but I > > > haven't had a chance to test it yet. > > > > > > cheers > > > Ben > > > > > > > -Original Message- > > > > From: Martin Grotzke [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, 11 July 2007 9:06 AM > > > > To: Tapestry users > > > > Subject: Re: T5: NPE in Base64InputStream and > > > > locked/waitingCheckForUpdatesFilter > > > > > > > > The NPE seems to be caused by a missing t:formdata > > request parameter. > > > > > > > > I just "reproduced" this (weird) situation by removing > > the hidden form > > > > field "t:formdata" with firebug, so that I could > produce the NPE. > > > > > > > > Although, following request went through well, and the number > > > > of request > > > > processing threads did not increase. > > > > > > > > So there seems to be no (direct) interrelationship > between the NPE > > > > and the locked threads. > > > > > > > > Cheers, > > > > Martin > > > > > > > > > > > > > > > > On Tue, 2007-07-10 at 23:43 +0200, Martin Grotzke wrote: > > > > > Hi, > > > > > > > > > > we had an issue with our deployed application that did > > not respond > > > > > anymore. This happened two or three times in the last 4 > > days, but > > > > > I was not able to reproduce it until now. > > > > > > > > > > The analysis of the logs showed, that there was a NPE in > > > > > Base64InputStream, and afterwards the application did > > not respond > > > > > anymore. > > > > > > > > > > When I triggered a thread dump, all 200 tomcat threads were > > > > in status > > > > > WAITING, like this one: > > > > > > > > > > "http-9090-1" daemon prio=10 tid=0x2aaaf7e1fc00 > > > > nid=0x3f05 waiting on condition > > > > [0x4459e000..0x4459fbc0] > > > > >java.lang.Thread.State: WAITING (parking) > > > > > at sun.misc.Unsafe.park(Native Method) > > > > > - parking to wait for <0x2aaab8228360> (a > > > > java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) > > > > > at > > > > > java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) > > > > >
RE: T5: NPE in Base64InputStream and locked/waitingCheckForUpdatesFilter
One work around that I found is to create the read/write lock in ConcurrentBarrier in "fair" mode instead of the default mode. (fair mode changes the algorithm used to decide which thread gets the lock next) That worked for me but subjectively things seemed a little slower (no actual measurement so take that for what it is worth) If it is fixed in 6u2 then I'd be tempted just to document the problem with 6u1 :) cheers Ben PS: I'll try to actually confirm that is it fixed in the next few days... may not get to it till the weekend tho > -Original Message- > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 11 July 2007 4:14 PM > To: Tapestry users > Subject: Re: T5: NPE in Base64InputStream and > locked/waitingCheckForUpdatesFilter > > Great find! People may need to deploy on JDK 1.5 to see if that's the > underlying cause. > > I wonder if we could create a work around by setting a wait time to > acquire the read lock? In a loop? > > On 7/10/07, Ben Sommerville <[EMAIL PROTECTED]> wrote: > > If you are running under jdk 6u1 and tapestry 5.0.5 (or > greater) then > > there is > > a jvm bug that can cause a deadlock. > > > > The bug report is at > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6571733. > > It is supposed to be fixed in jdk 6u2 (which was release > recently) but I > > haven't had a chance to test it yet. > > > > cheers > > Ben > > > > > -Original Message- > > > From: Martin Grotzke [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, 11 July 2007 9:06 AM > > > To: Tapestry users > > > Subject: Re: T5: NPE in Base64InputStream and > > > locked/waitingCheckForUpdatesFilter > > > > > > The NPE seems to be caused by a missing t:formdata > request parameter. > > > > > > I just "reproduced" this (weird) situation by removing > the hidden form > > > field "t:formdata" with firebug, so that I could produce the NPE. > > > > > > Although, following request went through well, and the number > > > of request > > > processing threads did not increase. > > > > > > So there seems to be no (direct) interrelationship between the NPE > > > and the locked threads. > > > > > > Cheers, > > > Martin > > > > > > > > > > > > On Tue, 2007-07-10 at 23:43 +0200, Martin Grotzke wrote: > > > > Hi, > > > > > > > > we had an issue with our deployed application that did > not respond > > > > anymore. This happened two or three times in the last 4 > days, but > > > > I was not able to reproduce it until now. > > > > > > > > The analysis of the logs showed, that there was a NPE in > > > > Base64InputStream, and afterwards the application did > not respond > > > > anymore. > > > > > > > > When I triggered a thread dump, all 200 tomcat threads were > > > in status > > > > WAITING, like this one: > > > > > > > > "http-9090-1" daemon prio=10 tid=0x2aaaf7e1fc00 > > > nid=0x3f05 waiting on condition > > > [0x4459e000..0x4459fbc0] > > > >java.lang.Thread.State: WAITING (parking) > > > > at sun.misc.Unsafe.park(Native Method) > > > > - parking to wait for <0x2aaab8228360> (a > > > java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) > > > > at > > > java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) > > > > at > > > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndC > > > heckInterrupt(AbstractQueuedSynchronizer.java:712) > > > > at > > > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquir > > > eShared(AbstractQueuedSynchronizer.java:842) > > > > at > > > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireS > > > hared(AbstractQueuedSynchronizer.java:1162) > > > > at > > > java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.loc > > k(ReentrantReadWriteLock.java:594) > > > > at > > > org.apache.tapestry.ioc.internal.util.ConcurrentBarrier.withRe > > > ad(ConcurrentBarrier.java:70) > > > > at > > > org.apache.tapestry.internal.services.CheckForUpdatesFilter.se > > > rvice(CheckForUpdatesFilter.java:110) > > > > at > > &
RE: T5: NPE in Base64InputStream and locked/waitingCheckForUpdatesFilter
If you are running under jdk 6u1 and tapestry 5.0.5 (or greater) then there is a jvm bug that can cause a deadlock. The bug report is at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6571733. It is supposed to be fixed in jdk 6u2 (which was release recently) but I haven't had a chance to test it yet. cheers Ben > -Original Message- > From: Martin Grotzke [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 11 July 2007 9:06 AM > To: Tapestry users > Subject: Re: T5: NPE in Base64InputStream and > locked/waitingCheckForUpdatesFilter > > The NPE seems to be caused by a missing t:formdata request parameter. > > I just "reproduced" this (weird) situation by removing the hidden form > field "t:formdata" with firebug, so that I could produce the NPE. > > Although, following request went through well, and the number > of request > processing threads did not increase. > > So there seems to be no (direct) interrelationship between the NPE > and the locked threads. > > Cheers, > Martin > > > > On Tue, 2007-07-10 at 23:43 +0200, Martin Grotzke wrote: > > Hi, > > > > we had an issue with our deployed application that did not respond > > anymore. This happened two or three times in the last 4 days, but > > I was not able to reproduce it until now. > > > > The analysis of the logs showed, that there was a NPE in > > Base64InputStream, and afterwards the application did not respond > > anymore. > > > > When I triggered a thread dump, all 200 tomcat threads were > in status > > WAITING, like this one: > > > > "http-9090-1" daemon prio=10 tid=0x2aaaf7e1fc00 > nid=0x3f05 waiting on condition > [0x4459e000..0x4459fbc0] > >java.lang.Thread.State: WAITING (parking) > > at sun.misc.Unsafe.park(Native Method) > > - parking to wait for <0x2aaab8228360> (a > java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) > > at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) > > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndC > heckInterrupt(AbstractQueuedSynchronizer.java:712) > > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquir > eShared(AbstractQueuedSynchronizer.java:842) > > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireS > hared(AbstractQueuedSynchronizer.java:1162) > > at > java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.loc k(ReentrantReadWriteLock.java:594) > > at > org.apache.tapestry.ioc.internal.util.ConcurrentBarrier.withRe > ad(ConcurrentBarrier.java:70) > > at > org.apache.tapestry.internal.services.CheckForUpdatesFilter.se > rvice(CheckForUpdatesFilter.java:110) > > at > $RequestHandler_1139c29ae4a.service($RequestHandler_1139c29ae4a.java) > > at > $RequestHandler_1139c29ae41.service($RequestHandler_1139c29ae41.java) > > at > org.apache.tapestry.services.TapestryModule$11.service(Tapestr yModule.java:1044) > > at > $HttpServletRequestHandler_1139c29ae40.service($HttpServletReq uestHandler_1139c29ae40.java) > > at > org.apache.tapestry.TapestryFilter.doFilter(TapestryFilter.java:135) > > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilt > er(ApplicationFilterChain.java:235) > > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli > cationFilterChain.java:206) > > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardW > rapperValve.java:230) > > at > org.apache.catalina.core.StandardContextValve.invoke(StandardC > ontextValve.java:175) > > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHost > Valve.java:128) > > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReport > Valve.java:104) > > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEn > gineValve.java:109) > > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdap > ter.java:261) > > at > org.apache.coyote.http11.Http11Processor.process(Http11Process > or.java:844) > > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandle r.process(Http11Protocol.java:581) > > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint. java:447) > > at java.lang.Thread.run(Thread.java:619) > > > > I'm not sure if the NPE that happened before is the reason > for this, as I don't > > see the relationship between both issues (apart from the > correlation of events/time). > > > > Hopefully someone closer to the code can have a look at > this and tell what's the > > problem here? Then I'd like to submit a bug report / help > fixing(?)... > > > > More output of the logs you find at the end of this email. > > > > Thanx a lot in advance, > > cheers, > > Martin > > > > > > > > [INFO ] 2007-07-09 11:56:35,513 TP-Processor1 > org.comp.proj.search.presentation.pages.Search.onActivate:
RE: T5.0.4: Bug in ComponentClassResolver?
That is deliberate, not a bug. >From "New And of Note" at http://tapestry.apache.org/tapestry5/tapestry-core/index.html The mapping from class names to page names (or component types) has been tweaked to remove some redunancy; For example, class org.example.myapp.pages.edit.EditUser will now have the name "edit/User" rather than "edit/EditUser". This results in shorter, clearer, more natural URLs cheers, Ben > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, 21 June 2007 4:59 PM > To: users@tapestry.apache.org > Subject: T5.0.4: Bug in ComponentClassResolver? > > I noticed same strange behaviour in the site/class mapping of > the ComponentClassResolver. If the Classname contains text > wich is identical to directories where the class is in than > the text is not contained in the key of the map entry. > > For example: > /mysite/admin/AdminLogin becomes /mysite/admin/Login (Admin > missing). So if you want to access the page by typing the URL > in the browser you have to use "/mysite/admin/Login" instead > of the correct "/mysite/admin/AdminLogin". > > Jens > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5: File input component
Hmm... I just test this again & was able to build with no problems. I am using maven 2.0.5 and I updated both pom.xml and parent-pom.xml to change 5.0.4-SNAPSHOT to 5.0.5-SNAPSHOT. What version of maven are you using? Are you able to build the Tapestry core project? regards, Ben > -Original Message- > From: Joshua Jackson [mailto:[EMAIL PROTECTED] > Sent: Friday, 1 June 2007 6:17 PM > To: Tapestry users > Subject: Re: T5: File input component > > I had a problem building it: > > [INFO] > -- > -- > [ERROR] BUILD ERROR > [INFO] > -- > -- > [INFO] Failed to resolve artifact. > > GroupId: org.apache.maven.plugins > ArtifactId: maven-plugins > Version: 2-SNAPSHOT > > Reason: Unable to download the artifact from any repository > > org.apache.maven.plugins:maven-plugins:pom:2-SNAPSHOT > > from the specified remote repositories: > tapestry-snapshots > (http://people.apache.org/~hlship/tapestry-snapshot-reposit > ory), > central (http://repo1.maven.org/maven2), > codehaus.snapshots (http://snapshots.repository.codehaus.org), > howardlewisship.com (http://howardlewisship.com/repository) > > I think this is maven problem. Do I need to change my pom.xml? > > On 6/1/07, Ben Sommerville <[EMAIL PROTECTED]> wrote: > > That download should still work... the only thing that you > should need > > to change is the tapestry versions in the pom files > (replace all 5.0.4 > > references with 5.0.5) > > > > If you run into problems drop me an email & I will try to help. > > > -- > YM!: thejavafreak > Blog: http://www.nagasakti.or.id/roller/joshua/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5: when is @Persist necessary and when not...
If you initialise the objects in either of those methods then you shouldn't need default values anymore. i.e no assignment in constructor or field init Otherwise if you are @Persisting those variables in the page (not the compound object) then you values should be retained. If you are doing all that & it isn't working I think I'd need to see the code again to be able help any further cheers, Ben > -Original Message- > From: Martin Dietze [mailto:[EMAIL PROTECTED] On Behalf Of > Martin Dietze > Sent: Friday, 1 June 2007 5:33 PM > To: 'Tapestry users' > Subject: Re: T5: when is @Persist necessary and when not... > > On Thu, May 31, 2007, Ben Sommerville wrote: > > > For a form I'd say the best place to create those compound objects > > is in the onPrepare method. This will be invoked before > any processing/ > > rendering occurs. (see the Form component subsection of > > > http://tapestry.apache.org/tapestry5/tapestry-core/guide/valid > ation.html) > > > > Another option is the pageAttached method (invoked when page > > is attached to the request) which is documented at > > > http://tapestry.apache.org/tapestry5/tapestry-core/guide/lifec > ycle.html > > Hmm, having tried both these options this leads to the objects > being replaced by defaults before the resultpage after a submit > is created, thus my submit results (the variables are annotated > with "@Persist") get lost. Or am I misunderstanding something > completely? > > Cheers, > > Martin > > -- > --- / http://herbert.the-little-red-haired-girl.org / > - > =+= > Wie verhindert man, dass einem die Geige gestohlen wird? > Man legt sie in einen Bratschenkasten... > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5: File input component
That download should still work... the only thing that you should need to change is the tapestry versions in the pom files (replace all 5.0.4 references with 5.0.5) If you run into problems drop me an email & I will try to help. cheers Ben > -Original Message- > From: Jason Lea [mailto:[EMAIL PROTECTED] > Sent: Friday, 1 June 2007 5:28 PM > To: Tapestry users > Subject: Re: T5: File input component > > In this thread a file upload component is mentioned: > http://www.nabble.com/T5-Upload-component--tf3373673.html#a9849252 > > and the download from here: > https://issues.apache.org/jira/browse/TAPESTRY-1354 > > > Joshua Jackson wrote: > > Dear all, > > > > Does anybody know where is the component or what is the name for the > > component for file input in T5? I've been searching through > under the > > package org.apache.tapestry.corelib.components but could > not find it? > > Have I missed on something? > > > > Currently I'm using version 5.0.4. Perhaps it is already > available in > > the snapshot version? > > > > Thanks in advance :) > > > > > > -- > Jason Lea > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5: when is @Persist necessary and when not...
The default value that the _person member gets reset to will be the Person _instance_ that you assigned in the constructor. So when the form is submitted that instance will have its members set based on the form values. When the page is rendered the same instance will be used as the default value & you will see your submitted values. Basically default values only work properly when they are immutable. e.g. strings, For a form I'd say the best place to create those compound objects is in the onPrepare method. This will be invoked before any processing/ rendering occurs. (see the Form component subsection of http://tapestry.apache.org/tapestry5/tapestry-core/guide/validation.html) Another option is the pageAttached method (invoked when page is attached to the request) which is documented at http://tapestry.apache.org/tapestry5/tapestry-core/guide/lifecycle.html cheers, Ben > > This is strange. If the _person member variable gets reset to > the default at the end of each request I would expect not to > see the values from it on my page after submit in the render > request. > > What I want to achieve is very much the same scenario found in > the documentation section "Form Input and Validation", only I > have several compound objects like `Person'. Since the form > accesses members of these objects they need to be created in > the page class. Since the constructor is obviously not the > right place for this, which one would you suggest? > > Cheers, > > Martin > > -- > --- / http://herbert.the-little-red-haired-girl.org / > - > =+= > Was ist ein Cluster? > Wenn vier Bratscher unisono spielen. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Trigger different behavior by clicking the different button in Tapestry5.0.4
Hi Allen,
You can use
public void onSelectedFromUpdate(){...}
public void onSelectedFromBack(){...}
A couple of things to note:
- all the standard form events (prepare, submit, validate, etc) will also
be invoked.
I believe that selected events will be invoked between prepare and
validate
- onSelected methods must return void, so you can't do navigation from
them.
If you want to navigate based on the submit button you need to set a
flag/enum in the
onSelected method & return a page based on that from
onSuccess/onSubmit/etc
cheers
Ben
> -Original Message-
> From: Allen Guo [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 29 May 2007 12:33 PM
> To: Tapestry users
> Subject: Trigger different behavior by clicking the different
> button in Tapestry5.0.4
>
> Hi All,
>
> There are two submit button on html template below.
>
>
>
>
>
> I would like to trigger a defferent method in Page class when clicking
> each button. So the page class looks like
> .
> public void onUpdate(){}
> public void onBack(){.}
>
> You know, if the action is just ActionLink or PageLink, I
> know how I can
> do it.
> But for button type is 'submit', what should I do?
>
> Thanks in advanced
> Allen Guo
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5: PrintWriter weirdness
Doh!
I missed that.
StreamResponse is much better.
i.e.
return new TextStreamResponse("text/plain",val);
thanks
Ben
> -Original Message-
> From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 23 May 2007 4:20 PM
> To: Tapestry users
> Subject: Re: T5: PrintWriter weirdness
>
> You can also return a StreamResponse, which is probably
> easier to implement
> that ActionResponseGenerator.
>
> On 5/22/07, Ben Sommerville <[EMAIL PROTECTED]> wrote:
> >
> > Bill,
> >
> > When you return void from an actionLink method the default response
> > of tapestry is to render the page.
> >
> > To just return the editor value you need to return an
> > ActionResponseGenerator
> > that outputs your desired response.
> >
> > e.g.
> >
> > ActionResponseGenerator onInPlaceEditorSubmit() throws
> IOException {
> > final String val = _request.getParameter("value");
> > System.out.println("text is:" + val);
> > return new ActionResponseGenerator() {
> > public void sendClientResponse(Response response) throws
> > IOException {
> > // Note we are using Response parameter,
> not the injected
> > response
> > PrintWriter writer =
> > response.getPrintWriter("text/plain");
> > writer.print(val);
> > }
> > };
> > }
> >
> > Now when you submit your changed value the web page will be updated.
> >
> > May I highly recommend Firebug to help with this sort of
> thing, being able
> > to see the requests & responses makes debugging much easier.
> >
> >
> >
> > Also, if you are not actually submitting a form you don't
> need the form
> > element in your page.
> > You can change your template to
> >
> > xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>
> >
> > Click me to edit this nice long text.
> >
> >
> > new Ajax.InPlaceEditor('editme2', '${actionURL}',
> > {rows:15,cols:40});
> >
> >
> >
> >
> >
> > and add the following to the page class to include the
> required javascript
> >
> > @Inject
> > private PageRenderSupport pageRender;
> > @Inject
> > @Path("${tapestry.scriptaculous}/prototype.js")
> > private Asset prototype;
> > @Inject
> > @Path("${tapestry.scriptaculous}/scriptaculous.js")
> > private Asset scriptaculous;
> >
> > public void beginRender() {
> > pageRender.addScriptLink(prototype, scriptaculous);
> > }
> >
> > cheers
> > Ben
> >
> > > -Original Message-
> > > From: Bill Holloway [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, 23 May 2007 10:38 AM
> > > To: Tapestry users
> > > Subject: Re: T5: PrintWriter weirdness
> > >
> > > Actually, the exception goes away on the client side only
> (No stack
> > > trace dumped to the web page) if I use writer.close().
> writer.flush()
> > > dumps the trace to both the console and the web page.
> > >
> > > Bill
> > >
> > > On 5/22/07, Bill Holloway <[EMAIL PROTECTED]> wrote:
> > > > I'm using an in-place-editor under script.aculo.us to
> edit some text
> > > > printed to the browser. In my page class I have
> > > >
> > > > public String getActionURL ()
> > > > {
> > > > Link inPlaceLink = _resources.createActionLink
> > > > ("inPlaceEditorSubmit", false, (Object[]) null);
> > > > return inPlaceLink.toURI();
> > > > }
> > > >
> > > > void onInPlaceEditorSubmit () throws IOException
> > > > {
> > > > String val = _request.getParameter ("value");
> > > > System.out.println ("text is:" + val);
> > > > PrintWriter writer =
> > > _response.getPrintWriter ("text/plain");
> > > > writer.print (val);
> > > > writer.flush();
> > > > }
> > > >
> > > > My page template is
> > > >
> > > > > > xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>
> > > &
RE: T5: PrintWriter weirdness
Bill,
When you return void from an actionLink method the default response
of tapestry is to render the page.
To just return the editor value you need to return an
ActionResponseGenerator
that outputs your desired response.
e.g.
ActionResponseGenerator onInPlaceEditorSubmit() throws IOException {
final String val = _request.getParameter("value");
System.out.println("text is:" + val);
return new ActionResponseGenerator() {
public void sendClientResponse(Response response) throws
IOException {
// Note we are using Response parameter, not the injected
response
PrintWriter writer =
response.getPrintWriter("text/plain");
writer.print(val);
}
};
}
Now when you submit your changed value the web page will be updated.
May I highly recommend Firebug to help with this sort of thing, being able
to see the requests & responses makes debugging much easier.
Also, if you are not actually submitting a form you don't need the form
element in your page.
You can change your template to
http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>
Click me to edit this nice long text.
new Ajax.InPlaceEditor('editme2', '${actionURL}',
{rows:15,cols:40});
and add the following to the page class to include the required javascript
@Inject
private PageRenderSupport pageRender;
@Inject
@Path("${tapestry.scriptaculous}/prototype.js")
private Asset prototype;
@Inject
@Path("${tapestry.scriptaculous}/scriptaculous.js")
private Asset scriptaculous;
public void beginRender() {
pageRender.addScriptLink(prototype, scriptaculous);
}
cheers
Ben
> -Original Message-
> From: Bill Holloway [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 23 May 2007 10:38 AM
> To: Tapestry users
> Subject: Re: T5: PrintWriter weirdness
>
> Actually, the exception goes away on the client side only (No stack
> trace dumped to the web page) if I use writer.close(). writer.flush()
> dumps the trace to both the console and the web page.
>
> Bill
>
> On 5/22/07, Bill Holloway <[EMAIL PROTECTED]> wrote:
> > I'm using an in-place-editor under script.aculo.us to edit some text
> > printed to the browser. In my page class I have
> >
> > public String getActionURL ()
> > {
> > Link inPlaceLink = _resources.createActionLink
> > ("inPlaceEditorSubmit", false, (Object[]) null);
> > return inPlaceLink.toURI();
> > }
> >
> > void onInPlaceEditorSubmit () throws IOException
> > {
> > String val = _request.getParameter ("value");
> > System.out.println ("text is:" + val);
> > PrintWriter writer =
> _response.getPrintWriter ("text/plain");
> > writer.print (val);
> > writer.flush();
> > }
> >
> > My page template is
> >
> > xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>
> >
> >
> >
> >
> >
> > Click me to edit this nice long text.
> >
> >
> > new Ajax.InPlaceEditor('editme2',
> '${actionURL}', {rows:15,cols:40});
> >
> >
> >
> >
> >
> >
> >
> > This all works just fine except that there is an
> > "IllegalStateException" thrown when I submit the changed field. It
> > complains about that the printwriter (I guess) is "Committed". A
> > partial stack trace starting at the top is shown below. I
> notice that
> > if I omit the call to writer.flush(), there is no exception, but the
> > text on the web page does not reflect the changed value --
> it reverts
> > to the initial value before the change -- doubtlessly
> because without
> > the flush, the stream never gets back to the client-side response
> > handler.
> >
> > #
> org.mortbay.jetty.servlet.ServletHttpResponse.resetBuffer(Serv
> letHttpResponse.java:212)
> > #
> org.mortbay.jetty.servlet.ServletHttpResponse.sendRedirect(Ser
> vletHttpResponse.java:458)
> > #
> org.apache.tapestry.internal.services.ResponseImpl.sendRedirec
> t(ResponseImpl.java:63)
> > #
> org.apache.tapestry.internal.services.LinkActionResponseGenera
> tor.sendClientResponse(LinkActionResponseGenerator.java:39)
> > #
> org.apache.tapestry.internal.services.ComponentActionDispatche
> r.dispatch(ComponentActionDispatcher.java:122)
> >
> > Thoughts?
> >
> > Bill
> > --
> > "The future is here. It's just not evenly distributed yet."
> >
> > -- Traditional
> >
>
>
> --
> "The future is here. It's just not evenly distributed yet."
>
> -- Traditional
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5: New Validators and server side validation
Bill,
This
> pageRenderSupport.addScript(
> "Tapestry.Field.email('%s', %s);",
> field.getClientId(),
> quote(buildMessage(formatter, field)));
does not construct a function validating emails. What it is doing is
inserting
a function call to register a particular field for validation.
On the page sent to the client you would get something like
<!--
Tapestry.registerForm('MyFormId');
Tapestry.Field.email('MyFieldId','My message ')l
-->
That is the source of your error message, the Tapestry.Field.email
function
does not exist but you are trying to call it.
What you need to do is define the email validation function yourself in a
javascript file. I would add it to a different namespace so that it is
clear
it is not a standard Tapestry function.
e.g. in myproject-valdation.js
var MyProject = {};
MyProject.Field = {
email: function(field, message) {
Tapestry.addValidator(field, false, function(value, event) {
if( X ) {
event.recordError(message)
}
});
}
}
where is the javascript to test if "value" is a valid email address.
Add a script include to your border/page (to load your validation
function)
and change the render method to use MyProject.Field.email and you are good
to go
cheers.
--
Ben Sommerville
> -Original Message-
> From: Bill Holloway [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 16 May 2007 4:33 PM
> To: Tapestry users
> Subject: Re: T5: New Validators and server side validation
>
> In implementing an e-mail validator myself, one thing I notice in all
> this is a Javascript error that reads
>
> Error: Tapestry.Field.email is not a function...
>
> I did some digging and found in org/apache/tapestry/tapestry.js the
> building up of the Tapestry object has in it a section involving
> "Collection of field based functions related to validation." In that
> part of the object prototyping (I guess), each of the built-in
> validation types (required, minlength, maxlength, min, and max) has a
> function assigned that, essentially, duplicates the functionality of
> the Java-based validators. All that prototyping must be for the
> client-side functionality.
>
> So I'm wondering why my AppModule-provided EmailValidator class'
> render() method isn't contributing the script. Its code is
>
> pageRenderSupport.addScript(
> "Tapestry.Field.email('%s', %s);",
> field.getClientId(),
> quote(buildMessage(formatter, field)));
>
> Since I implementing something for render(), I would think that at
> least some kind of function for Tapestry.Field.email would show up
> (even if it has the wrong number of fields, etc), knocking out the
> "...is not a function" error.
>
> Bill
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5 Class Not Found Error
I believe that tapestry uses javassist 3.4ga. It is likely that the tapestry ClassFactoryClassPool class is trying to use a javaassist method that isn't in 3.2 cheers Ben > -Original Message- > From: Tim Sawyer [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 18 April 2007 7:40 AM > To: Tapestry users > Subject: T5 Class Not Found Error > > Hi, > > I'm trying to set up a project including tapestry 5.0.3 and > spring 2.0 and I > think I've got my libraries in a twist somewhere. > > I'm getting this error in my tomcat 6.0 logs and a 404 in the > browser trying > to access my app: > > Caused by: java.lang.NoSuchMethodError: > org.apache.tapestry.ioc.internal.services.ClassFactoryClassPoo > l.toClass(Ljavassist/CtClass;Ljava/lang/ClassLoader;Ljava/secu > rity/ProtectionDomain;)Ljava/lang/Class; > at > org.apache.tapestry.ioc.internal.services.CtClassSource.create > Class(CtClassSource.java:88) > ... 40 more > > > Can anyone point me in the right direction? It's probably a > libraries thing, > where I have the wrong version or two versions of a library > present. I > definitely only have tapestry 5.0.3 and javassist 3.2 in > there though . > > ta, > > Tim. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5 Upload component?
It will be there waiting, no urgency :) My email was more for any other T5 users who have an urgent need (and a willingess to trial new code). There seemed to be at least a couple of people expressing interest previously. BTW - the component is implemented as a separate library/project. cheers Ben PS: And may I also say that the new DOM based markup writer is very cool. I was struggling for a while how to add an enctype attribute to the enclosing form without needing to patch the core code (my head was still stuck in t4 mode). Then the penny dropped & I realised I could just follow the parent elements up & add the attribute from within the upload component. Nifty!! > -Original Message- > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Friday, 6 April 2007 4:55 AM > To: Tapestry users > Subject: Re: T5 Upload component? > > I'll take a peek when I get a chance. > > My intention is for there to be a small tapestry-upload > project for the Upload component. The (majority of) > applications that don't use upload will not be burdened with > the many extra dependencies Upload will bring. > > On 4/4/07, Ben Sommerville <[EMAIL PROTECTED]> wrote: > > FYI - I just submitted an implementation of a file upload > component to > > JIRA. > > It can be downloaded from > > https://issues.apache.org/jira/browse/TAPESTRY-1354 > > > > You'll have to build it yourself, but it should "just work" using > > maven. > > > > If anyone tries it out, please let me know if you have any > problems or > > other feedback. > > > > regards, > > Ben > > > > > > > -Original Message- > > > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > > > Sent: Friday, 16 March 2007 12:09 PM > > > To: Tapestry users > > > Subject: Re: T5 Upload component? > > > > > > There's a pipeline of RequestFilters associated with the > > > RequestHandler service. > > > > > > On 3/14/07, Pablo Ruggia <[EMAIL PROTECTED]> wrote: > > > > Sorry, i forgot to wrote that the forms blows because it > > > doesn't get the > > > > parameter values, because it's not prepared to recieve a > > > multipart request. > > > > To "prepare" the multipar request so it seems like a > > > regular one, in tap4 > > > > has MultipartDecoderFilter. I just want to know what is the > > > best way to > > > > reproduce this behaviour in tap5. > > > > > > > > On 3/14/07, Pablo Ruggia <[EMAIL PROTECTED]> wrote: > > > > > > > > > > I have a problem building the upload component. > > > > > Form doesn't have support for setting the enctype, so i > > > have to pass > > > > > enctype='multipart/form-data' as an informal parameter. > > > > > Then the forms just blows up whenever i submit it. > > > > > In Tap4, there was a filter that creates a fake request > > > with the values. > > > > > How should I implement this logic in tap5 ? > > > > > > > > > > > > > > > On 3/12/07, D&J Gredler < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > I'm going to need it soon as well, but haven't looked > > > into it at all. Go > > > > > > for > > > > > > it! > > > > > > > > > > > > > > > > > > On 3/12/07, Pablo Ruggia <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > Does anyone implemented this Upload component ? > > > > > > > I need it, so if nobody has gone there yet, i'll give > > > it a try. > > > > > > > > > > > > > > On 3/9/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > Yep, not yet implemented. > > > > > > > > > > > > > > > > On 3/9/07, Hugo Palma < [EMAIL PROTECTED]> wrote: > > > > > > > > > I can't see any upload component here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://tapestry.apache.org/tapestry5/tapestry-core/component-p > > > arameters.html > > > > > > > > > so i guess that means it's still not implemented. > > > > > > > > > > > > > > > > > > Peter Beshai wrote: > > > > > > > > > > How do we use input type="file" in T5? Is this > > > functionality > > > > > > > > implemented > > > > > > > > > > yet? > > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Howard M. Lewis Ship > TWD Consulting, Inc. > Independent J2EE / Open-Source Java Consultant Creator and > PMC Chair, Apache Tapestry Creator, Apache HiveMind > > Professional Tapestry training, mentoring, support and > project work. http://howardlewisship.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5 Upload component?
FYI - I just submitted an implementation of a file upload component to JIRA. It can be downloaded from https://issues.apache.org/jira/browse/TAPESTRY-1354 You'll have to build it yourself, but it should "just work" using maven. If anyone tries it out, please let me know if you have any problems or other feedback. regards, Ben > -Original Message- > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Friday, 16 March 2007 12:09 PM > To: Tapestry users > Subject: Re: T5 Upload component? > > There's a pipeline of RequestFilters associated with the > RequestHandler service. > > On 3/14/07, Pablo Ruggia <[EMAIL PROTECTED]> wrote: > > Sorry, i forgot to wrote that the forms blows because it > doesn't get the > > parameter values, because it's not prepared to recieve a > multipart request. > > To "prepare" the multipar request so it seems like a > regular one, in tap4 > > has MultipartDecoderFilter. I just want to know what is the > best way to > > reproduce this behaviour in tap5. > > > > On 3/14/07, Pablo Ruggia <[EMAIL PROTECTED]> wrote: > > > > > > I have a problem building the upload component. > > > Form doesn't have support for setting the enctype, so i > have to pass > > > enctype='multipart/form-data' as an informal parameter. > > > Then the forms just blows up whenever i submit it. > > > In Tap4, there was a filter that creates a fake request > with the values. > > > How should I implement this logic in tap5 ? > > > > > > > > > On 3/12/07, D&J Gredler < [EMAIL PROTECTED]> wrote: > > > > > > > > I'm going to need it soon as well, but haven't looked > into it at all. Go > > > > for > > > > it! > > > > > > > > > > > > On 3/12/07, Pablo Ruggia <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Does anyone implemented this Upload component ? > > > > > I need it, so if nobody has gone there yet, i'll give > it a try. > > > > > > > > > > On 3/9/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Yep, not yet implemented. > > > > > > > > > > > > On 3/9/07, Hugo Palma < [EMAIL PROTECTED]> wrote: > > > > > > > I can't see any upload component here > > > > > > > > > > > > > > > > > > > > > > > http://tapestry.apache.org/tapestry5/tapestry-core/component-p > arameters.html > > > > > > > so i guess that means it's still not implemented. > > > > > > > > > > > > > > Peter Beshai wrote: > > > > > > > > How do we use input type="file" in T5? Is this > functionality > > > > > > implemented > > > > > > > > yet? > > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5 JBoss Exception Redeploy Exception
I also had this error when I was playing yesterday. In my case it turned out that I had two copies of tapestry-core on the classpath (one in a web app lib and the other in the ear that contained the web app). Removing the extra copy (in the web app) fixed this problem for me. -Original Message- From: Todd Orr [mailto:[EMAIL PROTECTED] Sent: Sunday, 4 March 2007 8:18 AM To: Tapestry users Subject: Re: T5 JBoss Exception Redeploy Exception Also note that my app is otherwise unremarkable. I'm not integrating anything exotic. I have been only creating some components and familiarizing myself with T5. On 3/3/07, Todd Orr <[EMAIL PROTECTED]> wrote: > Also, I am using the mvn true > setting. As well as the name="UseJBossWebLoader">true config setting. > > On 3/3/07, Todd Orr <[EMAIL PROTECTED]> wrote: > > What I exactly did: > > > > 1. code > > 2. mvn jboss:undeploy clean package jboss:deploy (no current > > deployment, I just do this so I only have to press up arrow > > subsequently) > > 3. attempt to resolve url > > 4. observe runtime error > > 5. make code changes > > 6. mvn jboss:undeploy clean package jboss:deploy 7. attempt to > > resolve url 8. observe tomcat error page 9. observe printstack > > listed below in stdout > > > > On 3/3/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > Ugly, and certainly a class loader problem. So you had a running > > > application, and you created and deployed a new .war on top of the > > > old one. > > > > > > On 3/2/07, Todd Orr <[EMAIL PROTECTED]> wrote: > > > > My problem happens after an exception occurs. Firstly, my > > > > tapestry example deploys fine. If any exception occurs I make > > > > the appropriate changes and then redeploy to jboss. Then I get > > > > the following error when trying to resolve a page. > > > > > > > > stack trace: > > > > > > > > 20:15:29,077 ERROR [ExceptionReport] Render queue error in > > > > BeginRender[org.apache.tapestry.corelib.pages.ExceptionReport:loop]: > > > > No object of type org.apache.tapestry.services.Heartbeat is > > > > available from the Environment. Available types are > > > > org.apache.tapestry.MarkupWriter, > > > > org.apache.tapestry.ValidationDecorator, > > > > org.apache.tapestry.dom.Document, > > > > org.apache.tapestry.services.Heartbeat, > > > > org.apache.tapestry.services.PageRenderSupport. > > > > java.lang.RuntimeException: No object of type > > > > org.apache.tapestry.services.Heartbeat is available from the > > > > Environment. Available types are > > > > org.apache.tapestry.MarkupWriter, > > > > org.apache.tapestry.ValidationDecorator, > > > > org.apache.tapestry.dom.Document, > > > > org.apache.tapestry.services.Heartbeat, > > > > org.apache.tapestry.services.PageRenderSupport. > > > > at org.apache.tapestry.internal.services.EnvironmentImpl.peekRequired(Environme ntImpl.java:73) > > > > at $Environment_110852b4624.peekRequired($Environment_110852b4624.java) > > > > at $Environment_110852b45c9.peekRequired($Environment_110852b45c9.java) > > > > at org.apache.tapestry.corelib.components.Loop._$environment_read_heartbeat(Loo p.java) > > > > at org.apache.tapestry.corelib.components.Loop.startHeartbeat(Loop.java:302) > > > > at org.apache.tapestry.corelib.components.Loop.begin(Loop.java:297) > > > > at org.apache.tapestry.corelib.components.Loop.beginRender(Loop.java) > > > > at org.apache.tapestry.internal.structure.ComponentPageElementImpl$10$1.run(Com ponentPageElementImpl.java:334) > > > > at org.apache.tapestry.internal.structure.ComponentPageElementImpl.invoke(Compo nentPageElementImpl.java:931) > > > > at org.apache.tapestry.internal.structure.ComponentPageElementImpl.access$100(C omponentPageElementImpl.java:68) > > > > at org.apache.tapestry.internal.structure.ComponentPageElementImpl$10.render(Co mponentPageElementImpl.java:338) > > > > at org.apache.tapestry.internal.services.RenderQueueImpl.run(RenderQueueImpl.ja va:57) > > > > at org.apache.tapestry.internal.services.PageMarkupRendererImpl.renderPageMarku p(PageMarkupRendererImpl.java:40) > > > > at $PageMarkupRenderer_110852b4621.renderPageMarkup($PageMarkupRenderer_110852b 4621.java) > > > > at org.apache.tapestry.internal.services.PageResponseRendererImpl.renderPageRes ponse(PageResponseRendererImpl.java:45) > > > > at $PageResponseRenderer_110852b45e1.renderPageResponse($PageResponseRenderer_1 10852b45e1.java) > > > > at org.apache.tapestry.internal.services.DefaultRequestExceptionHandler.handleR equestException(DefaultRequestExceptionHandler.java:56) > > > > at $RequestExceptionHandler_110852b45b8.handleRequestException($RequestExceptio nHandler_110852b45b8.java) > > > > at org.apache.tapestry.services.TapestryModule$6.service(TapestryModule.java:52 3) > > > > at $RequestHandler_110852b45f4.service($RequestHandler_110852b45f4.java) > > > >
RE: Dynamic Radiogroup
Ok, attachments don't work. Code follows inline.
++
package tapestry.components;
import org.apache.tapestry.form.RadioGroup;
import org.apache.tapestry.form.AbstractFormComponent;
import org.apache.tapestry.IMarkupWriter;
import org.apache.tapestry.IRequestCycle;
import org.apache.tapestry.Tapestry;
import org.apache.tapestry.annotations.Parameter;
import org.apache.tapestry.annotations.ComponentClass;
import org.apache.hivemind.ApplicationRuntimeException;
/**
* TODO: Doc this.
*
* @author Ben Sommerville
*/
@ComponentClass(allowBody = false, reservedParameters = "checked,type,name")
public abstract class FormRadio extends AbstractFormComponent {
@Parameter(name="id", defaultValue="id")
public abstract String getIdParameter();
@Parameter
public abstract String getDisplayName();
@Parameter
public abstract boolean isDisabled();
@Parameter
public abstract Object getValue();
/**
* Renders the form element, or responds when the form containing the
element
* is submitted (by checking [EMAIL PROTECTED]
org.apache.tapestry.form.Form#isRewinding()}.
*
*
**/
protected void renderFormComponent(IMarkupWriter writer, IRequestCycle
cycle)
{
RadioGroup group = RadioGroup.get(cycle);
if (group == null)
throw new ApplicationRuntimeException(
Tapestry.getMessage("Radio.must-be-contained-by-group"),
this,
null,
null);
// The group determines rewinding from the form.
//
//boolean rewinding = group.isRewinding();
int option = group.getNextOptionId();
//
//if (rewinding)
//{
//// If not disabled and this is the selected button within the
radio group,
//// then update set the selection from the group to the value
for this
//// radio button. This will update the selected parameter of
the RadioGroup.
//
//if (!isDisabled() && !group.isDisabled() &&
group.isSelected(option))
//group.updateSelection(getValue());
//return;
//}
//
writer.beginEmpty("input");
writer.attribute("type", "radio");
writer.attribute("name", group.getName());
renderIdAttribute(writer, cycle);
// As the group if the value for this Radio matches the selection
// for the group as a whole; if so this is the default radio and is
checked.
if (group.isSelection(getValue()))
writer.attribute("checked", "checked");
if (isDisabled() || group.isDisabled())
writer.attribute("disabled", "disabled");
// The value for the Radio matches the option number (provided by
the RadioGroup).
// When the form is submitted, the RadioGroup will know which option
was,
// in fact, selected by the user.
writer.attribute("value", option);
renderInformalParameters(writer, cycle);
}
protected void rewindFormComponent(IMarkupWriter writer, IRequestCycle
cycle) {
RadioGroup group = RadioGroup.get(cycle);
if (group == null)
throw new ApplicationRuntimeException(
Tapestry.getMessage("Radio.must-be-contained-by-group"),
this,
null,
null);
// The group determines rewinding from the form.
int option = group.getNextOptionId();
// If not disabled and this is the selected button within the radio
group,
// then update set the selection from the group to the value for
this
// radio button. This will update the selected parameter of the
RadioGroup.
if (!isDisabled() && !group.isDisabled() &&
group.isSelected(option))
group.updateSelection(getValue());
}
}
-Original Message-
From: Ben Sommerville [mailto:[EMAIL PROTECTED]
Sent: Thursday, 26 October 2006 9:33 PM
To: 'Tapestry users'
Subject: RE: Dynamic Radiogroup
I ran into this problem too. FieldLabel does not work with Radio because it
is not an IFormComponent.
The order of FieldLabel & the component it refers to doesn't matter. Except
that if you put the FieldLabel after the component you have to set
prerender=false.
I worked around this by creating a radio component that is a form component.
The
attached file has the class. Now the disclaimer- this is code from 6 or 7
months ago on a project that didn't finish & was developerd early in my
tapestry learning cycle - treat with appropriate caution :)
cheers,
Ben
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dynamic Radiogroup
I ran into this problem too. FieldLabel does not work with Radio because it is not an IFormComponent. The order of FieldLabel & the component it refers to doesn't matter. Except that if you put the FieldLabel after the component you have to set prerender=false. I worked around this by creating a radio component that is a form component. The attached file has the class. Now the disclaimer- this is code from 6 or 7 months ago on a project that didn't finish & was developerd early in my tapestry learning cycle - treat with appropriate caution :) cheers, Ben -Original Message- From: Todd Orr [mailto:[EMAIL PROTECTED] Sent: Thursday, 26 October 2006 1:44 AM To: Tapestry users Subject: Re: Dynamic Radiogroup Reversing the radio and the label still causes this exception. On 10/25/06, James Carman <[EMAIL PROTECTED]> wrote: > I don't think it matters where you define it within the HTML. Quite > often, the field label will come before the field it labels. I've > never had to resort to a .page/.jwc file in this case. > > On 10/24/06, Patrick Moore <[EMAIL PROTECTED]> wrote: > > > > your FieldLabel's field parameter is wrong, it should look like this: > > > > > > > > but if I remember correctly this will not work anyhow because sug is > > defined in the html after the FieldLabel. You will need to specify > > sug in your java or .jwc. > > > > -Pat > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: @EventListener and dojo topics
Jesse, That's what I suspected, thanks for the confirmation. I'm not sure what problem topics are solving in general, but in my specific case a dojo component I want to use (TreeV3) sends its events (or at least some of them) via topics. I wanted to hook those events to a server call. I'll investigate a bit more & see what I can come up with thanks Ben -Original Message- From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] Sent: Monday, 11 September 2006 12:41 AM To: Tapestry users; [EMAIL PROTECTED] Subject: Re: @EventListener and dojo topics Not currently. Topics also normally are associated with sending objects when things happen, so I'm not sure a good solution would be had to make this generic enough...Ie the objects could be anything..Dom nodes, arbitrary json structures, etc... Maybe if I knew more about the problem topics are solving I can be more useful with ideas. On 9/10/06, Ben Sommerville <[EMAIL PROTECTED]> wrote: > > Hi, > > Can an @EventListener be used to subscribe to an event publised via a > dojo topic? > (dojo topics are described at > > http://dojotoolkit.org/docs/dojo_event_system.html#using-topics-for-tr > uly-an > onymous-communication). > > > cheers, > -- > Ben Sommerville > > > -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is it possible to connect a dojo SortableTable to Tapestry 4.1.1 ?
Gary,
If you change
@EventListener(events="onSelect", elements="addressTable")
to
@EventListener(events="onSelect", targets="addressTable")
then Tapestry will render the event script using dojo.widget.ByID
(elements hooks to html elements, targets hooks to components/widgets)
Hope that helps
regards,
Ben
-Original Message-
From: Gerald Schöffel [mailto:[EMAIL PROTECTED]
Sent: Monday, 11 September 2006 2:10 PM
To: Tapestry users
Subject: Re: Is it possible to connect a dojo SortableTable to Tapestry
4.1.1 ?
Ok, me again ... could not give up on this ...
So I cleaned up my code and learned how to use the @Script-tag ...cool thing
:-)
When connecting manually, the following code will work:
dojo.event.connect(dojo.widget.byId("tableWidget"), "onSelect", window,
"addressDisplay_selectAlert") ;
This will display an alert whenever I click on a row.
Tapestry will render the following when using @EventListener:
dojo.event.connect(dojo.byId("addressTable"), "onSelect", tapestry,
"event327750702");
When using this syntax to connect the event by hand like
dojo.event.connect(dojo.byId("addressTable"), "onSelect", window,
"addressDisplay_selectAlert");
it will NOT work.
Hmmm ... is there a way to get this working with @EventListener ?
The second possibility would be to do the 'eventhandling' (onSelect is a
function-call, no event at all) with js and send another 'real' event to
Tapestry. But as the first possibility ... I do not know, how to to so :(
Any help on this is really desired :)
Thank you !
Bye,
Gary
> Hi Jesse !
>
> Thank you for your quick reply !
>
> But I already use
>
> in my
> shell component. So the widget is created and functional (clicking on
> a header sorts the table and so on).
>
> The only 'issue' I have is binding the call to onSelect to an event
> with @EventListener. There is just no request happening when clicking
> and selecting table-rows (using firebug to do the 'debugging').
>
> Other events are working fine ... but this one is driving me nuts ...
>
> For today I will give up on this :(
>
> Tomorrow I will try to bind an event to a js-funtion with
> dojo.event.connect manually to narrow this down.
>
> In the meantime: if anyone has an idea ... please let me know. :-)
>
> Bye
> Gary
>
>> The table won't be parsed into a dojo widget by default. (Tapestry
>> turns this off..)
>>
>> You can probably add a single line of js to parse it out though:
>>
>> dojo.widget.createWidget(dojo.byId("addressTable"));
>>
>> On 9/10/06, Gerald Schöffel <[EMAIL PROTECTED]> wrote:
>>>
>>> Hi there !
>>>
>>> I am trying to connect a dojo SortableTable via the @EventListener
>>> annotation to Tapestry (4.1.1, latest build from svn).
>>>
>>> In my component html file I have something like this:
>>>
>>>>> widgetId="tableWidget" headClass="fixedHeader"
>>> tbodyClass="scrollContent"
>>>enableMultipleSelect="false" enableAlternateRows="true"
>>> rowAlternateClass="alternateRow" cellpadding="0" cellspacing="0"
>>> border="0">
>>>
>>>...
>>>
>>>
>>>
>>> Inside my component I have the following annotation:
>>>
>>> @EventListener(events="onSelect", elements="addressTable")
>>>
>>> So now I am trying to get an event to Tapestry when a row is clicked
>>> (firing 'onSelect' inside the SortableTable-Widget) - or even better
>>> - when a row is double clicked, passing a parameter (getValue) to
>>> the listener
>>>
>>> I think I have tested every combination of html-code/eventlistener
>>> etc. (like doing >> id=", changing elements="addressTable" to targets="addressTable"
>>> etc.).
>>>
>>> I trying to do so the whole evening - without effort :(
>>>
>>> So is it possible to connect a plain dojo-widget to Tapestry this
>>> way ? Or am I totally wrong ?
>>>
>>> Would by great to get some response :)
>>>
>>> Thank you in advance !
>>>
>>> Bye,
>>> Gary
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
@EventListener and dojo topics
Hi, Can an @EventListener be used to subscribe to an event publised via a dojo topic? (dojo topics are described at http://dojotoolkit.org/docs/dojo_event_system.html#using-topics-for-truly-an onymous-communication). cheers, -- Ben Sommerville
@EventListener, FieldLabel & IRequestCycle.getResponseBuilder.updateComponent
Hi,
I had a problem with @EventListener tonight but I'm not sure if this is a
bug or ignorance on my part.
(I am working with the latest 4.1 version from svn)
First let me explain what I am trying to do
I have a form with several PropertySelection input fields on it. What I
want to do is change the selectable options based on what has already been
selected.
e.g. Say the form has two select fields A & B
A has options 1,2,3.
If the value of A is 1, then B should have options 11, 12, 13
If the value of A is 2, then B should have options 21, 22, 23
If the value of A is 3, then B should have options 31, 32, 33
Now in the page template the fields are defined as follows
Role
B
To update the options displayed by B I defined the following method
@EventListener(targets="A", events="onchange", submitForm ="form")
public void selectA(IRequestCycle cycle) {
bModel = New model for b based on value of A
cycle.getResponseBuilder().updateComponent("b");
}
What I was expecting to happen was that when the value of A was changed then
B would be rerendered with the new options based on A's value.
What actually happened was that as soon as I changed the value of A then B
was rendered with no options at all.
After a bit of debugging I eventually worked out that what was happening
was:
- A's value was changed & the event listener was invoked
- The model for B was updated correctly
- The FieldLabel that refered to B was rendered with a NullWriter
- this field label prerendered B (to get its id) with the NullWriter
- B was rendered with a real writer but didn't output anything because it
had been prerendered
- The page was updated an empty B element (cause the NullWriter discards
everything).
To work around this I gave the FieldLabel (for B) an explicit id and added
an updateComponent call for the this id. When I did this the page behaved
as I was expecting.
Now my question: Is this behaviour correct?
Or have I approached the problem incorrectly?
It seems a bit unintuitive, I would prefer B to render properly when I asked
it to be updated, rather than having to update both it and the label.
However I'm not sure how to get my desired behaviour. Maybe the
DojoAjaxResponseBuilder could check the form prerender map after each
component render and clear out any prerender's with null results
...or maybe wiser heads can come up with a much more elegant solution :)
Also, while I was working with this form I kept getting the following error
in the console
"[MarkupWriterSource] No markup filter could be found for content type
'text/xml;charset=UTF-8'; a default filter has been used."
Any ideas what might be causing this?
thanks
--
Ben Sommerville
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: PermGen space - Caching is ON
I don't know any easy answers to this sort of problem, but I can suggest several avenues of investigation. If you are running on solaris or linux then Sun has several tools available that you can use to diagnose what is using the Perm Gen memory. Have a look at http://java.sun.com/j2se/1.5/pdf/jdk50_ts_guide.pdf In particular http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jmap.html with the -permstat option might be able to tell you which classloader is the culprit. The perm gen space is also used when generating class files from JSPs. For servers with large numbers of JSP pages and/or frequent redeployments I've seen quite a large use of the perm gen space. It may also be worth increase the max space to see if that helps. Generally 128M is enough but I have seen a couple of situations where it needed to be larger. If you double the perm gen & hit out of memory at about half the frequency then you've got a leakage problem. Worth trying it just to confirm the problem. Another area to investigate is the use of ThreadLocal variables by your app or any libraries you use. Its very easy to setup up a circular reference to your (application) class loader when using ThreadLocals. Then when the app is redeployed the classloader & all its classes do not go away. If you find that the out of memory shows up more frequently when you redeploy apps more then this may be the cause. For some more detailed discussion/explanations of ThreadLocal & class loaders the following are worth a read (or just google ThreadLocal classloader). http://www.szegedi.org/articles/memleak.html http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?page Id=2669 http://blog.arendsen.net/index.php/2005/02/22/threadlocals-and-memory-leaks- revisited/ Note: there are quite a few open source libraries that have had this problem at one time or another, so its worth investigating even if your code doesnt use ThreadLocals A final option may be to use a different JDK impl. E.g. I'm pretty sure that Jrockit (from bea) doesnt have a perm gen space & hence wont get the same problem (or at least might manifest it in a different way that is easier to diagnose). That's a pretty radical step tho, especially if your app is in production & has undergone a lot of testing in its current environment. Hope some of that helps. For what its worth, you have my sympathies. I've tried to find similar problems myself & its a long, hard road :( Regards, Ben Sommerville -Original Message- From: Henri Dupre [mailto:[EMAIL PROTECTED] Sent: Monday, 24 July 2006 2:12 PM To: Tapestry users Subject: Re: PermGen space - Caching is ON The tomcat folks state that there is no solution to this issue (in the tomcat FAQ)... I somehow hope that more recent versions of the JDK can solve this problem... I tried the new funky +CMS... java options but they don't seem to help the redeployment. Btw, I've seen this happening on JBoss too with a simple J2EE application. Henri. On 7/23/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > No ideas at all, but if anyone thinks they get closer to finding > something let me know. I am definitely willing/able to work with > someone to solve problems like this, I just can't do it in the dark. > > On 7/23/06, Harvey, David <[EMAIL PROTECTED]> wrote: > > > > Thanks for your comments, discussion. However, this occurs when > > caching is turned on, i.e. > > -Dorg.apache.tapestry.disable-caching=false. > > > > I sure hope there's a fix, I don't know if MaxPermSize can be made > > any larger in production and it sounds from your discussion that > > making it larger will just delay the OOM condition anyway. > > > > Anybody else have any ideas? > > > > -Original Message- > > From: James Carman [mailto:[EMAIL PROTECTED] > > Sent: Sunday, July 23, 2006 6:03 AM > > To: Tapestry users > > Subject: Re: PermGen space > > > > Actually, Tapestry (and HiveMind as well) uses Javassist to generate > > classes at runtime, but all the rest is still true with Javassist as > > it > is > > with CGLIB (hibernate uses CGLIB). As Martin said, enabling caching > should > > fix the problem. Tapestry will only generate (and cache) the > > classes > for > > each page/component one time with caching enabled. In a production > > environment, you really shouldn't run into this, since you would > > have caching enabled and you wouldn't be hot redeploying your application. > > > > James > > > > > Hi all, > > > This problem is very common with Tapestry applications. This is > > > due to the fact that Tapestry uses cglib to generate classes at runtime. > > > Java uses
