Re: AW: AW: Strange behavior of special characters
From the java apidocs: The load and store methods load and store properties in a simple line-oriented format specified below. This format uses the ISO 8859-1 character encoding. Characters that cannot be directly represented in this encoding can be written using Unicode escapes ; only a single 'u' character is allowed in an escape sequence. The native2ascii tool can be used to convert property files to and from other character encodings. http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html Use native2ascii and you are set. Uli Am Di, 8.07.2008, 09:18, schrieb Sebastian Altmann: Yes I'm reading my values from properties files which are utf-8 encoded, but what really confuses me is that you tell me they aren't allowed i utf-8. Because we're running an application with utf-8 properties-files without any problems. This strange behavior can only be found in anatoher application. Maximilian WeiÃböck wrote: Do you read this values from a property file? Property files in Java may not be utf-8 encoded. The have to be iso-8859-1 encoded. Many thanks to Sun ... Max -Ursprüngliche Nachricht- Von: Sebastian Altmann [mailto:[EMAIL PROTECTED] Gesendet: Montag, 7. Juli 2008 14:54 An: users@tapestry.apache.org Betreff: Re: AW: Strange behavior of special characters No i didn't because i am using tapestry 4.0.2 (forgot to mention this :-(() but i read similar atricles on tapestry 4. The weird thing is that my encoding basically is ok, and this strange things happen just under certain circumstances. Another thing that confuses me is that for example in löschen not just the ö isn't displayed correct but also the 3 following characters (sch). This happens to every string with special characters (mostly not the next 3 but the next 2 characters ). Maximilian WeiÃböck wrote: Did you have a look at http://wiki.apache.org/tapestry/Tapestry5Utf8Encoding Max -Ursprüngliche Nachricht- Von: Sebastian Altmann [mailto:[EMAIL PROTECTED] Gesendet: Montag, 7. Juli 2008 14:06 An: users@tapestry.apache.org Betreff: Strange behavior of special characters Hi, we provide our tapestry application in two languages (german and english) which work quite fine but with one problem. The problem is, that special characters used in german (like ö, ü, ä) are displayed wrong the first time i access a page (in this case i get l?en instead of löschen för example). If i do a refresh on the page or just navigate to another page all my special characters are displayed correct all over the application. My first suspicion was that this is some kind of browser problem, because the page's sourcecode is identic before and after refresh. But my browser encoding is UTF-8 in both cases which is ok. By the way i tried both firefox and ie and always get the same wrong behavior. Another point which confuses me is that we are developping more than one tapestry application and this just happens at one of them. Does anybody know more about this problem? -- View this message in context: http://www.nabble.com/Strange-behavior-of-special-characters-tp18315199p18315199.html Sent from the Tapestry - User mailing list archive at Nabble.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] -- View this message in context: http://www.nabble.com/Strange-behavior-of-special-characters-tp18315199p18316032.html Sent from the Tapestry - User mailing list archive at Nabble.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] -- View this message in context: http://www.nabble.com/Strange-behavior-of-special-characters-tp18315199p1829.html Sent from the Tapestry - User mailing list archive at Nabble.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]
t5: logging pages
hi, i just noticed that catalina.out contains informations from different web apps hosted in the same site, is there a way for me to specify a log file for my tapestry 5 app only? thanks. Angelo -- View this message in context: http://www.nabble.com/t5%3A-logging-pages-tp18333788p18333788.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry-upload component limit uploaded data
You can write an org.apache.tapestry5.FieldValidator and bind it to your upload component with the validate parameter. Uli Am Di, 8.07.2008, 11:02, schrieb Peter Stavrinides: Hi I wish to limit the types of files that are handled by the upload component (i.e: only excel and pdf files), but I can't seem to find this documented... I also tried it using the HTML parameter accept=application/excel, application/vnd.ms-excel, application/x-msexcel, application/ms-excel, application/pdf, but it still uploads everything. Sorry if this question is trivial, but I could use some pointers please. Thanks Peter - 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: Using the Autocompleter
Found the solution:
Use the Suggest component instead.
http://tapestry.apache.org/tapestry4.1/components/scriptaculous/suggest.html
The Autocompleter has issues anyway:
http://issues.apache.org/jira/browse/TAPESTRY-1244
Andy Pahne schrieb:
I am trying to implement a form that uses the Autocompleter component
http://tapestry.apache.org/tapestry4.1/components/dojo/autocompleter.html
I had a look at the TimeTracker demo application. It already works, but
I have one requirement that's differnet from the way the demo is
implemented:
The time trackler loads a complete list of objects from the DAO layer:
return new DefaultAutocompleteModel(getProjectDao().list(), id,
name);
In my application it is not possible to load the complete list from the
database. Instead the function in my DAO layer takes one argument:
ListLocation getManager().getLocations(String startWith);
So, how can I retrieve the user's input in the autocompleter field? For
example: the user enters Aber, I retireve all Locations from the
database that start with Aber (Aberdeen), and then build a model.
I tried
@EventListener(
events = onValueChanged,
targets = locationChoose
)
public void projectSelected(BrowserEvent event){
String selection = event.getMethodArguments().getString(0);
LOG.trace(Selected value = ' + selection + ');
getBuilder().updateComponent(locationDescription);
}
but that return an identifier. The problem is: I don't need an
identifier for my call into the DAO layer, but the raw user's input...
Another question: I want my autocompleter to start async request only
when the user entered three or more chars. Is that possible?
Andy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andy Pahne
System Architektur Software Design
net22 GmbH
Ehrenbergweg 24
32760 Detmold
http://www.net22.de
Email [EMAIL PROTECTED]
Telefon +49 (5231) 58 06 40
Mobil +49 (174) 171 68 70
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry-upload component limit uploaded data
Or you could just use the regexp validator and filter on file names. See http://tapestry.apache.org/tapestry5/tutorial1/forms.html for an example how to use it. Uli Am Di, 8.07.2008, 11:11, schrieb Ulrich Stärk: You can write an org.apache.tapestry5.FieldValidator and bind it to your upload component with the validate parameter. Uli Am Di, 8.07.2008, 11:02, schrieb Peter Stavrinides: Hi I wish to limit the types of files that are handled by the upload component (i.e: only excel and pdf files), but I can't seem to find this documented... I also tried it using the HTML parameter accept=application/excel, application/vnd.ms-excel, application/x-msexcel, application/ms-excel, application/pdf, but it still uploads everything. Sorry if this question is trivial, but I could use some pointers please. Thanks Peter - 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: [T5] Default ValidationTracker clearing needed?
hi, the Form component was changed some time ago to use the flash persistence strategy for the ValidationTracker from the code: @Persist(PersistenceConstants.FLASH) private ValidationTracker defaultTracker; g, kris Vjeran Marcinko [EMAIL PROTECTED] 07.07.2008 21:15 Bitte antworten an Tapestry users users@tapestry.apache.org An users@tapestry.apache.org Kopie Thema [T5] Default ValidationTracker clearing needed? Hi all. I posted this as a comment on some closed Jira issue, but nevertheless, I would like to see comments from everybody... ValidationTracker in its current form clears its input values before success event. I guess it is done this way assuming that no error can happen anymore when success is triggered, and one doesn't want to see those values even if staying on same page. Two frequent cases come to my mind when this simply doesn't hold water... 1. Cases when SOME validation is performed inside business methods, thrown as checked exceptions when not satisfied. This validation cannot be performed prior to calling business method. I don't believe that in those cases I should place calling the business method inside unnatural onValidate handler. I believe it should still be placed inside onSuccess, since all a priori validation has passed well. Example is typical call on UserDao from within EditPage.onSuccess() method : UserDao.save(User user) throws UsernameReservedException I still have to be able to catch this exception and somehow dispay error with all input values still shown. 2. Frequently, when using search forms, I display search results on same page where form resides. Being able to show all search form criteria values is great stuff, since user can see what criteria he just entered. Since this is normal type of request flow, input values should ont be cleared before success. MY SUGGESTION: ValidationTracker should be persisted wtih flash strategy, and values should never be cleared. If one stays on same page, regardless if there was an error (in any handler method - onValidate, onSuccess...) or not, input values would still be there. If user decides to leave the page, flash strategy will ensure that these values will not be visible he comes back to this page later. In rare cases when user wants to stay on the same page, but doesn't want to see input values, he can explicitly clear those values. Thoughts? -Vjeran - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Default ValidationTracker clearing needed?
Oh, I didn't know that since I've seen some discussions before that it was session. Nevertheless, clearing of the input values prior to success event still poses slight problem IMO. I am not fond of persisting some entity objects between requests just to be able to see those input values rendered, since this can raise some Hibernate session problems etc... -Vjeran - Original Message - From: Kristian Marinkovic [EMAIL PROTECTED] To: Tapestry users users@tapestry.apache.org Sent: Tuesday, July 08, 2008 11:16 AM Subject: Re: [T5] Default ValidationTracker clearing needed? hi, the Form component was changed some time ago to use the flash persistence strategy for the ValidationTracker from the code: @Persist(PersistenceConstants.FLASH) private ValidationTracker defaultTracker; g, kris Vjeran Marcinko [EMAIL PROTECTED] 07.07.2008 21:15 Bitte antworten an Tapestry users users@tapestry.apache.org An users@tapestry.apache.org Kopie Thema [T5] Default ValidationTracker clearing needed? Hi all. I posted this as a comment on some closed Jira issue, but nevertheless, I would like to see comments from everybody... ValidationTracker in its current form clears its input values before success event. I guess it is done this way assuming that no error can happen anymore when success is triggered, and one doesn't want to see those values even if staying on same page. Two frequent cases come to my mind when this simply doesn't hold water... 1. Cases when SOME validation is performed inside business methods, thrown as checked exceptions when not satisfied. This validation cannot be performed prior to calling business method. I don't believe that in those cases I should place calling the business method inside unnatural onValidate handler. I believe it should still be placed inside onSuccess, since all a priori validation has passed well. Example is typical call on UserDao from within EditPage.onSuccess() method : UserDao.save(User user) throws UsernameReservedException I still have to be able to catch this exception and somehow dispay error with all input values still shown. 2. Frequently, when using search forms, I display search results on same page where form resides. Being able to show all search form criteria values is great stuff, since user can see what criteria he just entered. Since this is normal type of request flow, input values should ont be cleared before success. MY SUGGESTION: ValidationTracker should be persisted wtih flash strategy, and values should never be cleared. If one stays on same page, regardless if there was an error (in any handler method - onValidate, onSuccess...) or not, input values would still be there. If user decides to leave the page, flash strategy will ensure that these values will not be visible he comes back to this page later. In rare cases when user wants to stay on the same page, but doesn't want to see input values, he can explicitly clear those values. Thoughts? -Vjeran - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.4.6/1539 - Release Date: 7.7.2008 18:35 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Default ValidationTracker clearing needed?
hi, this is how i do it... one of many possible ways :) i let tapestry populate a DTO bean that is sent during the validate event through a facade (IOC service) to my businesslayer. there the DTO is then mapped to my BOs. (as in the theory :) because i don't want to write these stupid DTO- BO mappings i have a DTO and a BO interface. the view layer knows only the DTO interface with getter and setter methods. the only thing the facade does is to perform a cast from the DTO interface to the BO interface and to call the BOs validate method. my facade returns a validationResult instance that contains the error messages that are fed into the form component preventing the success event. and sometimes i have to call save() to get a result (username/ password). in this cases i dont use the success event at all (in the login example i return a Link to the welcome page). btw. the facade will catch any exception that might occur during the business transaction. so the view (tapestry) will not know anything about it, except the error messages i set. Another thing you can do is to create a tapestry page that is desgined to display a certain exception. Take a look at the ExcpetionReporter page. IMHO the events provided by tapestry are just fine. most of the time the way the application is designed is the problem. a clean separation of view and businesslayer is crucial. have a look at Pojos in Action by Chris Richardson or Domain Driven Design by Eric Evans... they are really worth reading. g, kris Vjeran Marcinko [EMAIL PROTECTED] 08.07.2008 12:03 Bitte antworten an Tapestry users users@tapestry.apache.org An Tapestry users users@tapestry.apache.org Kopie Thema Re: [T5] Default ValidationTracker clearing needed? Oh, I didn't know that since I've seen some discussions before that it was session. Nevertheless, clearing of the input values prior to success event still poses slight problem IMO. I am not fond of persisting some entity objects between requests just to be able to see those input values rendered, since this can raise some Hibernate session problems etc... -Vjeran - Original Message - From: Kristian Marinkovic [EMAIL PROTECTED] To: Tapestry users users@tapestry.apache.org Sent: Tuesday, July 08, 2008 11:16 AM Subject: Re: [T5] Default ValidationTracker clearing needed? hi, the Form component was changed some time ago to use the flash persistence strategy for the ValidationTracker from the code: @Persist(PersistenceConstants.FLASH) private ValidationTracker defaultTracker; g, kris Vjeran Marcinko [EMAIL PROTECTED] 07.07.2008 21:15 Bitte antworten an Tapestry users users@tapestry.apache.org An users@tapestry.apache.org Kopie Thema [T5] Default ValidationTracker clearing needed? Hi all. I posted this as a comment on some closed Jira issue, but nevertheless, I would like to see comments from everybody... ValidationTracker in its current form clears its input values before success event. I guess it is done this way assuming that no error can happen anymore when success is triggered, and one doesn't want to see those values even if staying on same page. Two frequent cases come to my mind when this simply doesn't hold water... 1. Cases when SOME validation is performed inside business methods, thrown as checked exceptions when not satisfied. This validation cannot be performed prior to calling business method. I don't believe that in those cases I should place calling the business method inside unnatural onValidate handler. I believe it should still be placed inside onSuccess, since all a priori validation has passed well. Example is typical call on UserDao from within EditPage.onSuccess() method : UserDao.save(User user) throws UsernameReservedException I still have to be able to catch this exception and somehow dispay error with all input values still shown. 2. Frequently, when using search forms, I display search results on same page where form resides. Being able to show all search form criteria values is great stuff, since user can see what criteria he just entered. Since this is normal type of request flow, input values should ont be cleared before success. MY SUGGESTION: ValidationTracker should be persisted wtih flash strategy, and values should never be cleared. If one stays on same page, regardless if there was an error (in any handler method - onValidate, onSuccess...) or not, input values would still be there. If user decides to leave the page, flash strategy will ensure that these values will not be visible he comes back to this page later. In rare cases when user wants to stay on the same page, but doesn't want to see input values, he can explicitly clear those values. Thoughts? -Vjeran - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:
Re: [T5] Looped component question
Ah, sorry, it seems I was halfly asleep when I answered. I completely
misread your question. (And sure you are right about the identifier part.)
José Paumard schrieb:
Thank you for your answer Tobias, but it wont work, because a
component ID has to be a valid Java identifier.
José
Tobias Wehrum a écrit :
Hi José,
I currently have no time to test it, but did you try
t:textfield t:id=${propertyName} t:value=message:enter-search
t:mixins=autocomplete/
?
- Tobias
José Paumard schrieb:
Hello all,
I'm using a component in a loop T5 feature, that looks like this :
t:form t:id=...
t:loop source=propertyNames value=propertyName
encoder=encoder index=index
td
t:textfield t:id=propertyName
t:value=message:enter-search t:mixins=autocomplete/
/td
/t:loop
/t:form
It works very nicely, T5 creates a list of such textfields, with ids
propertyName_0, propertyName_1, etc...
What I would like to get is the propertyName associated with the
current text field in the autocomplete callback. I tried several
things with no success. I even made a personnal text field, with
just a property index in it :
t:util.textfield t:id=propertyName t:index=index
t:value=message:enter-search t:mixins=autocomplete/
But this index property is 0, whatever the textfield that generates
the call back. In fact, it seems to me that there's only one
component text field in the model, whilst there are several in the
HTML page.
So is there a way to get the propertyName in the autocomplete
callback ?
Thank you,
José
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: AW: Strange behavior of special characters
The load and store methods load and store properties in a simple line-oriented format specified below. This format uses the ISO 8859-1 character encoding. Characters that cannot be directly represented in this encoding can be written using Unicode escapes ; only a single 'u' character is allowed in an escape sequence. The native2ascii tool can be used to convert property files to and from other character encodings. from http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html Max -Ursprüngliche Nachricht- Von: Sebastian Altmann [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 8. Juli 2008 09:19 An: users@tapestry.apache.org Betreff: Re: AW: AW: Strange behavior of special characters Yes I'm reading my values from properties files which are utf-8 encoded, but what really confuses me is that you tell me they aren't allowed i utf-8. Because we're running an application with utf-8 properties-files without any problems. This strange behavior can only be found in anatoher application. Maximilian Weißböck wrote: Do you read this values from a property file? Property files in Java may not be utf-8 encoded. The have to be iso-8859-1 encoded. Many thanks to Sun ... Max -Ursprüngliche Nachricht- Von: Sebastian Altmann [mailto:[EMAIL PROTECTED] Gesendet: Montag, 7. Juli 2008 14:54 An: users@tapestry.apache.org Betreff: Re: AW: Strange behavior of special characters No i didn't because i am using tapestry 4.0.2 (forgot to mention this :-(() but i read similar atricles on tapestry 4. The weird thing is that my encoding basically is ok, and this strange things happen just under certain circumstances. Another thing that confuses me is that for example in löschen not just the ö isn't displayed correct but also the 3 following characters (sch). This happens to every string with special characters (mostly not the next 3 but the next 2 characters ). Maximilian Weißböck wrote: Did you have a look at http://wiki.apache.org/tapestry/Tapestry5Utf8Encoding Max -Ursprüngliche Nachricht- Von: Sebastian Altmann [mailto:[EMAIL PROTECTED] Gesendet: Montag, 7. Juli 2008 14:06 An: users@tapestry.apache.org Betreff: Strange behavior of special characters Hi, we provide our tapestry application in two languages (german and english) which work quite fine but with one problem. The problem is, that special characters used in german (like ö, ü, ä) are displayed wrong the first time i access a page (in this case i get l?en instead of löschen för example). If i do a refresh on the page or just navigate to another page all my special characters are displayed correct all over the application. My first suspicion was that this is some kind of browser problem, because the page's sourcecode is identic before and after refresh. But my browser encoding is UTF-8 in both cases which is ok. By the way i tried both firefox and ie and always get the same wrong behavior. Another point which confuses me is that we are developping more than one tapestry application and this just happens at one of them. Does anybody know more about this problem? -- View this message in context: http://www.nabble.com/Strange-behavior-of-special-characters-tp18315199p18315199.html Sent from the Tapestry - User mailing list archive at Nabble.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] -- View this message in context: http://www.nabble.com/Strange-behavior-of-special-characters-tp18315199p18316032.html Sent from the Tapestry - User mailing list archive at Nabble.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] -- View this message in context: http://www.nabble.com/Strange-behavior-of-special-characters-tp18315199p1829.html Sent from the Tapestry - User mailing list archive at Nabble.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: AW: AW: AW: Strange behavior of special characters
Sorry but I just don't get it... After you mentioned the first time that there are problems concerning properties files in UTF-8 I also found this and similar articles on the sam topic. I would quietly accept this, if my special characters were displayed wrong all over the application and in other applications too, but i can't understand why this should be a general Java problem even though in 99% of cases my special characters are displayed properly. Maximilian Weißböck wrote: The load and store methods load and store properties in a simple line-oriented format specified below. This format uses the ISO 8859-1 character encoding. Characters that cannot be directly represented in this encoding can be written using Unicode escapes ; only a single 'u' character is allowed in an escape sequence. The native2ascii tool can be used to convert property files to and from other character encodings. from http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html Max -Ursprüngliche Nachricht- Von: Sebastian Altmann [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 8. Juli 2008 09:19 An: users@tapestry.apache.org Betreff: Re: AW: AW: Strange behavior of special characters Yes I'm reading my values from properties files which are utf-8 encoded, but what really confuses me is that you tell me they aren't allowed i utf-8. Because we're running an application with utf-8 properties-files without any problems. This strange behavior can only be found in anatoher application. Maximilian Weißböck wrote: Do you read this values from a property file? Property files in Java may not be utf-8 encoded. The have to be iso-8859-1 encoded. Many thanks to Sun ... Max -Ursprüngliche Nachricht- Von: Sebastian Altmann [mailto:[EMAIL PROTECTED] Gesendet: Montag, 7. Juli 2008 14:54 An: users@tapestry.apache.org Betreff: Re: AW: Strange behavior of special characters No i didn't because i am using tapestry 4.0.2 (forgot to mention this :-(() but i read similar atricles on tapestry 4. The weird thing is that my encoding basically is ok, and this strange things happen just under certain circumstances. Another thing that confuses me is that for example in löschen not just the ö isn't displayed correct but also the 3 following characters (sch). This happens to every string with special characters (mostly not the next 3 but the next 2 characters ). Maximilian Weißböck wrote: Did you have a look at http://wiki.apache.org/tapestry/Tapestry5Utf8Encoding Max -Ursprüngliche Nachricht- Von: Sebastian Altmann [mailto:[EMAIL PROTECTED] Gesendet: Montag, 7. Juli 2008 14:06 An: users@tapestry.apache.org Betreff: Strange behavior of special characters Hi, we provide our tapestry application in two languages (german and english) which work quite fine but with one problem. The problem is, that special characters used in german (like ö, ü, ä) are displayed wrong the first time i access a page (in this case i get l?en instead of löschen för example). If i do a refresh on the page or just navigate to another page all my special characters are displayed correct all over the application. My first suspicion was that this is some kind of browser problem, because the page's sourcecode is identic before and after refresh. But my browser encoding is UTF-8 in both cases which is ok. By the way i tried both firefox and ie and always get the same wrong behavior. Another point which confuses me is that we are developping more than one tapestry application and this just happens at one of them. Does anybody know more about this problem? -- View this message in context: http://www.nabble.com/Strange-behavior-of-special-characters-tp18315199p18315199.html Sent from the Tapestry - User mailing list archive at Nabble.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] -- View this message in context: http://www.nabble.com/Strange-behavior-of-special-characters-tp18315199p18316032.html Sent from the Tapestry - User mailing list archive at Nabble.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] -- View this message in context: http://www.nabble.com/Strange-behavior-of-special-characters-tp18315199p1829.html Sent from the Tapestry - User mailing list archive at Nabble.com.
Re: [T5] Default ValidationTracker clearing needed?
Hi, Thanx for suggestion, but I really don't see that I have any issue with my application design. The facade that you described here is just nice *view-layer* convenience that prepares error messages in bottom layer for web pages above. I emphasize this *view-layer facade* since business/service layer is not supose to manage any error messages at all, just throw exceptions and client layer (web pages in this case) should catch it if interested and display apropriate message. As I mentioned before, for sake of atomicity and elegance of business layer, I cannot and would not separate validation portion from business method itself. In other words, in case of: userDao.save(User user) throws UsernameReservedException; // during success event , it would be wrong to separate it into: userDao.checkUsername(String username); // during validateForm event userDao.save(User user); // during success event Maybe the way to solve the issue here would be to call nbuness method during validaeFomr event, but that seems a bit strange considering purpose of the method. And still, even that way would not suit for cases where I want to stay on same page after successful form submit (as case with mentioned search result page in my last post). I don't have any issues with Tapestry event system in general, it's really great. Only clearing of ValidationTracker input fields bothers me here. And I've read Evans' DDD book. One of the greatest. Regards, Vjeran - Original Message - From: Kristian Marinkovic [EMAIL PROTECTED] To: Tapestry users users@tapestry.apache.org Sent: Tuesday, July 08, 2008 1:26 PM Subject: Re: [T5] Default ValidationTracker clearing needed? hi, this is how i do it... one of many possible ways :) i let tapestry populate a DTO bean that is sent during the validate event through a facade (IOC service) to my businesslayer. there the DTO is then mapped to my BOs. (as in the theory :) because i don't want to write these stupid DTO- BO mappings i have a DTO and a BO interface. the view layer knows only the DTO interface with getter and setter methods. the only thing the facade does is to perform a cast from the DTO interface to the BO interface and to call the BOs validate method. my facade returns a validationResult instance that contains the error messages that are fed into the form component preventing the success event. and sometimes i have to call save() to get a result (username/ password). in this cases i dont use the success event at all (in the login example i return a Link to the welcome page). btw. the facade will catch any exception that might occur during the business transaction. so the view (tapestry) will not know anything about it, except the error messages i set. Another thing you can do is to create a tapestry page that is desgined to display a certain exception. Take a look at the ExcpetionReporter page. IMHO the events provided by tapestry are just fine. most of the time the way the application is designed is the problem. a clean separation of view and businesslayer is crucial. have a look at Pojos in Action by Chris Richardson or Domain Driven Design by Eric Evans... they are really worth reading. g, kris Vjeran Marcinko [EMAIL PROTECTED] 08.07.2008 12:03 Bitte antworten an Tapestry users users@tapestry.apache.org An Tapestry users users@tapestry.apache.org Kopie Thema Re: [T5] Default ValidationTracker clearing needed? Oh, I didn't know that since I've seen some discussions before that it was session. Nevertheless, clearing of the input values prior to success event still poses slight problem IMO. I am not fond of persisting some entity objects between requests just to be able to see those input values rendered, since this can raise some Hibernate session problems etc... -Vjeran - Original Message - From: Kristian Marinkovic [EMAIL PROTECTED] To: Tapestry users users@tapestry.apache.org Sent: Tuesday, July 08, 2008 11:16 AM Subject: Re: [T5] Default ValidationTracker clearing needed? hi, the Form component was changed some time ago to use the flash persistence strategy for the ValidationTracker from the code: @Persist(PersistenceConstants.FLASH) private ValidationTracker defaultTracker; g, kris Vjeran Marcinko [EMAIL PROTECTED] 07.07.2008 21:15 Bitte antworten an Tapestry users users@tapestry.apache.org An users@tapestry.apache.org Kopie Thema [T5] Default ValidationTracker clearing needed? Hi all. I posted this as a comment on some closed Jira issue, but nevertheless, I would like to see comments from everybody... ValidationTracker in its current form clears its input values before success event. I guess it is done this way assuming that no error can happen anymore when success is triggered, and one doesn't want to see those values even if staying on same page. Two frequent cases come to my mind when this simply doesn't hold water... 1. Cases when SOME validation is performed
Re: [T5] Default ValidationTracker clearing needed?
Hi Vjeran, I completely agree with everything you just said. Cheers, Geoff On 08/07/2008, at 11:20 PM, Vjeran Marcinko wrote: Hi, Thanx for suggestion, but I really don't see that I have any issue with my application design. The facade that you described here is just nice *view-layer* convenience that prepares error messages in bottom layer for web pages above. I emphasize this *view-layer facade* since business/service layer is not supose to manage any error messages at all, just throw exceptions and client layer (web pages in this case) should catch it if interested and display apropriate message. As I mentioned before, for sake of atomicity and elegance of business layer, I cannot and would not separate validation portion from business method itself. In other words, in case of: userDao.save(User user) throws UsernameReservedException; // during success event , it would be wrong to separate it into: userDao.checkUsername(String username); // during validateForm event userDao.save(User user); // during success event Maybe the way to solve the issue here would be to call nbuness method during validaeFomr event, but that seems a bit strange considering purpose of the method. And still, even that way would not suit for cases where I want to stay on same page after successful form submit (as case with mentioned search result page in my last post). I don't have any issues with Tapestry event system in general, it's really great. Only clearing of ValidationTracker input fields bothers me here. And I've read Evans' DDD book. One of the greatest. Regards, Vjeran - Original Message - From: Kristian Marinkovic [EMAIL PROTECTED] To: Tapestry users users@tapestry.apache.org Sent: Tuesday, July 08, 2008 1:26 PM Subject: Re: [T5] Default ValidationTracker clearing needed? hi, this is how i do it... one of many possible ways :) i let tapestry populate a DTO bean that is sent during the validate event through a facade (IOC service) to my businesslayer. there the DTO is then mapped to my BOs. (as in the theory :) because i don't want to write these stupid DTO- BO mappings i have a DTO and a BO interface. the view layer knows only the DTO interface with getter and setter methods. the only thing the facade does is to perform a cast from the DTO interface to the BO interface and to call the BOs validate method. my facade returns a validationResult instance that contains the error messages that are fed into the form component preventing the success event. and sometimes i have to call save() to get a result (username/ password). in this cases i dont use the success event at all (in the login example i return a Link to the welcome page). btw. the facade will catch any exception that might occur during the business transaction. so the view (tapestry) will not know anything about it, except the error messages i set. Another thing you can do is to create a tapestry page that is desgined to display a certain exception. Take a look at the ExcpetionReporter page. IMHO the events provided by tapestry are just fine. most of the time the way the application is designed is the problem. a clean separation of view and businesslayer is crucial. have a look at Pojos in Action by Chris Richardson or Domain Driven Design by Eric Evans... they are really worth reading. g, kris Vjeran Marcinko [EMAIL PROTECTED] 08.07.2008 12:03 Bitte antworten an Tapestry users users@tapestry.apache.org An Tapestry users users@tapestry.apache.org Kopie Thema Re: [T5] Default ValidationTracker clearing needed? Oh, I didn't know that since I've seen some discussions before that it was session. Nevertheless, clearing of the input values prior to success event still poses slight problem IMO. I am not fond of persisting some entity objects between requests just to be able to see those input values rendered, since this can raise some Hibernate session problems etc... -Vjeran - Original Message - From: Kristian Marinkovic [EMAIL PROTECTED] To: Tapestry users users@tapestry.apache.org Sent: Tuesday, July 08, 2008 11:16 AM Subject: Re: [T5] Default ValidationTracker clearing needed? hi, the Form component was changed some time ago to use the flash persistence strategy for the ValidationTracker from the code: @Persist(PersistenceConstants.FLASH) private ValidationTracker defaultTracker; g, kris Vjeran Marcinko [EMAIL PROTECTED] 07.07.2008 21:15 Bitte antworten an Tapestry users users@tapestry.apache.org An users@tapestry.apache.org Kopie Thema [T5] Default ValidationTracker clearing needed? Hi all. I posted this as a comment on some closed Jira issue, but nevertheless, I would like to see comments from everybody... ValidationTracker in its current form clears its input values before success event. I guess it is done this way assuming that no error can happen anymore when success is triggered, and one
Custom Components with input
Hi, I hava a custom component which includes form. Part of my CustomComponent.html looks like this: ... input type=submit jwcid=@Submit listener=listener:onWriteRequest/ ... action is a parameter of my component and it is persistent in the page that component is put on. When listener onWriteRequest is fired action.mainAttribute.name is null. It looks like the value from the user has been erased. I am quite new to tapestry and have no idea what can be the cause. I would be very grateful for any hints. Kind Regards, Michał U -- View this message in context: http://www.nabble.com/Custom-Components-with-input-tp18340911p18340911.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom Components with input
Sorry. It should look like this: ... input type=submit jwcid=@Submit listener=listener:onWriteRequest/ ... Michał U Michał U wrote: Hi, I hava a custom component which includes form. Part of my CustomComponent.html looks like this: ... span jwcid=@Insert value=ognl:action.mainAttribute.name input type=submit jwcid=@Submit listener=listener:onWriteRequest/ ... action is a parameter of my component and it is persistent in the page that component is put on. When listener onWriteRequest is fired action.mainAttribute.name is null. It looks like the value from the user has been erased. I am quite new to tapestry and have no idea what can be the cause. I would be very grateful for any hints. Kind Regards, Michał U -- View this message in context: http://www.nabble.com/Custom-Components-with-input-tp18340911p18340915.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
can we do something for grid.refresh() with the parameter inplace=true?
hi, i'm newbie in tapestry. can we do something like grid.refresh() (example) with the parameter inplace=true? i noticed that it will run setupRender, setupDataSource, getAvailableRows.. when I click on paging 2 in the grid ( because after i click on the page2 and click back to the page1. my previously saved data which located in my page1 will refresh.)? Thank you Regards, CyBer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: AW: AW: Strange behavior of special characters
I'm very sure the property files that work are not utf-8 encoded but iso-8895-1 encoded. You can use ÄÖÜß and so on with no problem in property files (we do it), just be very sure they are iso-8895-1 encoded. If you use Eclipse, right click on the file, open Properties and look at the Text file Encoding. Max -Ursprüngliche Nachricht- Von: Sebastian Altmann [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 8. Juli 2008 15:11 An: users@tapestry.apache.org Betreff: Re: AW: AW: AW: Strange behavior of special characters Sorry but I just don't get it... After you mentioned the first time that there are problems concerning properties files in UTF-8 I also found this and similar articles on the sam topic. I would quietly accept this, if my special characters were displayed wrong all over the application and in other applications too, but i can't understand why this should be a general Java problem even though in 99% of cases my special characters are displayed properly. Maximilian Weißböck wrote: The load and store methods load and store properties in a simple line-oriented format specified below. This format uses the ISO 8859-1 character encoding. Characters that cannot be directly represented in this encoding can be written using Unicode escapes ; only a single 'u' character is allowed in an escape sequence. The native2ascii tool can be used to convert property files to and from other character encodings. from http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html Max -Ursprüngliche Nachricht- Von: Sebastian Altmann [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 8. Juli 2008 09:19 An: users@tapestry.apache.org Betreff: Re: AW: AW: Strange behavior of special characters Yes I'm reading my values from properties files which are utf-8 encoded, but what really confuses me is that you tell me they aren't allowed i utf-8. Because we're running an application with utf-8 properties-files without any problems. This strange behavior can only be found in anatoher application. Maximilian Weißböck wrote: Do you read this values from a property file? Property files in Java may not be utf-8 encoded. The have to be iso-8859-1 encoded. Many thanks to Sun ... Max -Ursprüngliche Nachricht- Von: Sebastian Altmann [mailto:[EMAIL PROTECTED] Gesendet: Montag, 7. Juli 2008 14:54 An: users@tapestry.apache.org Betreff: Re: AW: Strange behavior of special characters No i didn't because i am using tapestry 4.0.2 (forgot to mention this :-(() but i read similar atricles on tapestry 4. The weird thing is that my encoding basically is ok, and this strange things happen just under certain circumstances. Another thing that confuses me is that for example in löschen not just the ö isn't displayed correct but also the 3 following characters (sch). This happens to every string with special characters (mostly not the next 3 but the next 2 characters ). Maximilian Weißböck wrote: Did you have a look at http://wiki.apache.org/tapestry/Tapestry5Utf8Encoding Max -Ursprüngliche Nachricht- Von: Sebastian Altmann [mailto:[EMAIL PROTECTED] Gesendet: Montag, 7. Juli 2008 14:06 An: users@tapestry.apache.org Betreff: Strange behavior of special characters Hi, we provide our tapestry application in two languages (german and english) which work quite fine but with one problem. The problem is, that special characters used in german (like ö, ü, ä) are displayed wrong the first time i access a page (in this case i get l?en instead of löschen för example). If i do a refresh on the page or just navigate to another page all my special characters are displayed correct all over the application. My first suspicion was that this is some kind of browser problem, because the page's sourcecode is identic before and after refresh. But my browser encoding is UTF-8 in both cases which is ok. By the way i tried both firefox and ie and always get the same wrong behavior. Another point which confuses me is that we are developping more than one tapestry application and this just happens at one of them. Does anybody know more about this problem? -- View this message in context: http://www.nabble.com/Strange-behavior-of-special-characters-tp18315199p18315199.html Sent from the Tapestry - User mailing list archive at Nabble.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] -- View this message in context: http://www.nabble.com/Strange-behavior-of-special-characters-tp18315199p18316032.html Sent from the Tapestry - User mailing list archive at Nabble.com.
Re: how to get the nice ajax form-validations when using beaneditform.recordError()
I get nice ajax validations on fields when using the @Validate-annotation
This isn't ajax validation, it's javascript validation which means there is
no trip to the server. Look at the source for your page you'll see the
validation registered in a script block at the end.
If you want javascript validation of your form you can add javascript to
your component/page to observe the Tapestry.FORM_VALIDATE_EVENT. See
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/main/resources/org/apache/tapestry5/tapestry.js?view=markup
Josh
On Mon, Jul 7, 2008 at 3:59 PM, Britske [EMAIL PROTECTED] wrote:
I get nice ajax validations on fields when using the @Validate-annotation
etc.
I want that as well for cross-field validation, but instead I get the
'general' validation box in red above my form.
I used the following validation-code to check if the two passwords supplied
are the same, and if not record an error to the password field:
Object onValidateForm(){
if(!user.getPassword().equals(user.getPasswordAgain())){
beanEditForm.recordError(password, the two
passwords supplied were not
the same));
}
Does this have to do with the 'ajax-validations' being bounded to a
particular field and the 'general validation' being bound to the form in
general (this is how it seems to me).
Does anyone know how to get the nice ajax-validations on the above
validation as well?
Thanks.
--
View this message in context:
http://www.nabble.com/how-to-get-the-nice-ajax-form-validations-when-using-beaneditform.recordError%28%29-tp18328440p18328440.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.
[T5] Layout and $remove$
Hello all,
I'm new to Tapestry 5, and I'm having some problems:
In T4, the Shell component creates the outer layout. When I insert a
shell component in my pages, it ignores the page htmlhead etc and only
renderizes
the body, and renderizes the shell htmlhead.
On T5, with the t:layout, it renders both, the layout htmlhead and
the page htmlhead.
How can I make it render only the layout htmlhead?
And how can I make so that it don't render something, like the $remove$
tag on T4?
The tutorials I found about T5 shows examples with layout this way:
On the layout page, it goes the shell:
html
head
etc
On the page, just the body content, like:
t:layout xmlns:t=http://tapestry.apache.org/schema/tapestry_5_0_0.xsd;
${hello}
/t:layout
But if I do this way, when I open the page on a web browser it doesn't
recognize it
as a html page. I have tried adding a
meta http-equiv=Content-Type content=text/html; charset=UTF-8/
It works for a preview, but when I run tapestry it throws this exception:
Failure parsing template context:Start.tml: The markup in the document
following the root element must be well-formed.
How are you doing to preview the pages?
Thanks.
--
Fabio Kreusch
[EMAIL PROTECTED]
Re: stripping jsessionid in custom dispatcher depending on ASM.
perhaps I should have mentioned that the code for checking if the
user-instance exists or not isn't here yet, but it isn't really relevant for
the problem. Thanks.
Britske wrote:
I want to strip JsessionId from the url (for browsers who dont support
cookies) for SEO purposes.
btw: perhaps a bit long-winded as to the why's, but it may help others.
At first I implemented a servletfilter (from
http://randomcoder.com/articles/jsessionid-considered-harmful)
which basically consists of passing a subclassed httpServletResponse where
i've overwritten the encodeUrl() method to not to include the jsessionid.
This works well.
However I do not want to strip the jsesisonid when the user has logged in.
The rationale here is that I really do need a session when a user is
logged in, and since a searchengine doesn't login (at least I don't
program for it) It can't harm to make this exception.
The application recognizes that a user is logged in if a User-instance is
present in the ASM (ApplicationStateManager).
This means I have to let the notion of a requesthandler go, and go instead
with a tapestry dispatcher, since a servlet requesthandler has no way f
getting the ASM of the current user. (Is this correct?)
Not much changed to the dispather (in relationship to the code in the
requestfilter before). The Dispatcher is also correctly registered in
AppModule etc.
The problem is that although I see that jsessionid is stripped in the
custom encodeUrl-method, if appears afterwards in request (as noticed in
the address-bar). So my question is: What code inserts the
jsessionid-again, after the Response.encodeUrl()-method, and how can I
change it's behavior?
the relevant code:
//Appmodule
public static void bind(ServiceBinder binder)
{
binder.bind(AccessController.class).withId(AccessController);
binder.bind(AutoLoginController.class).withId(AutoLoginController);
binder.bind(SessionStripController.class).withId(SessionStripController);
}
public void contributeMasterDispatcher(OrderedConfigurationDispatcher
configuration,
@InjectService(AccessController) Dispatcher
accessController,
@InjectService(AutoLoginController) Dispatcher
autoLoginController,
@InjectService(SessionStripController) Dispatcher
sessionStripController) {
configuration.add(AccessController, accessController,
before:PageRender);
configuration.add(AutoLoginController, autoLoginController,
before:AccessController);
configuration.add(SessionStripController,
sessionStripController,before:AutoLoginController);
}
//sessionstripcontroller
public final class SessionStripController implements Dispatcher {
private ApplicationStateManager asm;
private RequestGlobals globals;
public SessionStripController(ApplicationStateManager asm,RequestGlobals
globals){
this.asm = asm;
this.globals = globals;
}
public boolean dispatch(Request req, Response response) throws
IOException {
// clear session if session id in URL
if (req.isRequestedSessionIdValid()
globals.getHTTPServletRequest().getCookies()==null)
{
Session session = req.getSession(false);
if (session != null) session.invalidate();
ServletResponseWrapper wrapResp = new
ServletResponseWrapper(globals.getHTTPServletResponse());
globals.storeRequestResponse(req, wrapResp);
}
return false;
}
}
//ServletResponseWrapper
public class ServletResponseWrapper extends ResponseImpl{
public ServletResponseWrapper(HttpServletResponse response) {
super(response);
// TODO Auto-generated constructor stub
}
@Override
public String encodeRedirectURL(String url) {
url = super.encodeRedirectURL(url);
return url;
}
@Override
public String encodeURL(String url) {
url = super.encodeURL(url);
url = url.substring(0,url.indexOf(;));
return url;
}
}
btw: encodeRedirectURL and encodeURL can just return url straightaway,
but the above code enabled me to see that indeed this code stripped the
added jsessionid that super.encode*Url() added. So where is the other
method that's adding jsessionid?
Cheers,
Britske
--
View this message in context:
http://www.nabble.com/stripping-jsessionid-in-custom-dispatcher-depending-on-ASM.-tp18351016p18351055.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
Re: T5: Working with BeanModel
For future reference, here is the fix. I found it by looking at the source for BeanModelSourceImpl.java: BeanModel toReturn = _beanModelSource.create( MyClass.class, false, _componentResources ); toReturn.exclude( (String[])toReturn.getPropertyNames() .toArray( new String[0] ) ); PropertyConduit pc = _propertyConduitSource.create( MyClass.class, pstlCode ); ClassPropertyAdapter cpa = _propertyAccess.getAdapter( MyClass.class ); PropertyAdapter pa = cpa.getPropertyAdapter( pstlCode ); String dataType = _dataTypeAnalyzer.identifyDataType( pa ); toReturn.add( pstlCode, pc ).dataType( dataType ); return( toReturn ); In the above example, the following were all injected: _beanModelSource _componentResources _propertyConduitSource _propertyAccess _dataTypeAnalyzer On Wed, 2008-07-02 at 03:34 -0400, Andy Huhn wrote: Hello, I have a class defined (MyClass) that has a String property pstlCode, with a getter and a setter. If I use BeanModelSource to create a BeanModel for MyClass, the BeanModel has a property pstlCode that can be used to access the pstlCode. However, if I exclude the pstlCode property, and then attempt to add it back in with myBeanModel.exclude( pstlCode ); myBeanModel.add( pstlCode ); it doesn't seem to pick up the data type of the property. Help? Thanks, Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5: dead lock in Tapestry - Hibernate
Hi, I encounter this warning quite often, it usually happens when I updated a row using mysql command line, then quit, after that I either update or append some rows using T5-hibernate, any idea why ? Thanks. Angelo [WARN] ThreadPoolAsynchronousRunner [EMAIL PROTECTED] -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks! [WARN] ThreadPoolAsynchronousRunner [EMAIL PROTECTED] -- APPARENT DEADLOCK!!! Complete Status: Managed Threads: 3 Active Threads: 3 Active Tasks: [EMAIL PROTECTED] (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0) [EMAIL PROTECTED] (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2) [EMAIL PROTECTED] (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1) Pending Tasks: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/T5%3A-dead-lock-in-Tapestry---Hibernate-tp18353145p18353145.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
