Hi all,
There have been a number of threads discussing this runtime option. I
think the consensus opinion was that although it is off by default, it
is better switched on.
Presumably there are some basic additional rules to follow.
For instance, AFAIK components will not be shared by multiple
I gonna give you some piece of code in a separate email. But you have to read
the documentation a little bit.
Philippe
On 5 avr. 2011, at 03:19, Kevin Hinkson wrote:
On 2011-04-04, at 9:13 PM, Mike Schrag wrote:
given that this is a service call from a cron job, there's really no reason
Hi Markus,
I never used the ERExcelListPage but when using Apache POI directly you have to
adapt the cell style to accept line breaks:
Workbook wb = ...;
Sheet sheet = ...;
Row row = ...;
Cell cell = ...;
String value = string with line breaks;
CellStyle wrappingStyle = wb.createCellStyle();
After moving my app from sessions IDs stored in URL to Cookie, I get this when
submitting a form
Any suggestion?
Amed
Error: java.lang.IllegalStateException: Default form value encoding was
changed after parsing multi-part form. Form values will be lost.
Reason: Default form value encoding
If you are using Wonder, then in your cron action method:
Runnable myTask = new MyLongRunningTask();
ERXExecutorService.executorService().execute( myLongRunningTask );
HTH, Kieran
On Apr 4, 2011, at 9:35 PM, Kevin Hinkson wrote:
On Apr 4, 2011, at 21:27,
the problem happens only with multipart encoding, but I'm now usong
AjaxFlexibleUploader so I don't need multipart. So is fixed for me
Amed
On 05/apr/2011, at 12.43, Amedeo Mantica wrote:
After moving my app from sessions IDs stored in URL to Cookie, I get this
when submitting a form
Any
EOSchemaGeneration foreignKeyConstraintStatementsForRelationship() seems to
ignore schemas. Anyone else have problems with that when using addForeignKey()
in a migration with tables with non-default schemas? I tried to fix it on my
own, but either my brain is too small or wonder is too
Hi all,
I've been looking into a synchronization issue with Wonder's ERJGroup (Wonder
from 2011/01/29 with jgroups 2.6.8)
We use to set maxCoordinators=3 (maybe it was a default somewhere), but we
experienced some unreliable synchronization between 2 apps (a back end and a
front end). By
Hi Mark,
On Apr 4, 2011, at 11:20 PM, Mark Wardle wrote:
Hi all,
There have been a number of threads discussing this runtime option. I
think the consensus opinion was that although it is off by default, it
is better switched on.
I think it is off by default to match the previous (now
Hi Chuck,
could you elaborate more on the shared formatters thing?
Don't Do Stupid Things :-) Which boils down to don't share objects that are
not thread-safe, or writable data, at the global level unless you have
appropriate protection. Global being either static members or instance
Hi Matteo,
I don't think that will cause a deadlock. It will cause some incorrectly
formatted input / output. The easiest fix is to move this from Application to
Session and adjust the bindings.
As for the lockups, you really need to get thread dumps to assess those.
jstack is an easy way
Hi Chuck,
there are 30 different formatters (all NS...) in the application and more than
500 WOComponents. if this is not a potential deadlock case, I'll leave them
there... Too lazy!
I'll try to investigate the deadlocks properly, the problem is that they're
very rare and almost impossible to
You need to have all of your application consistent in the form value encoding.
Make sure that you are not using the obsolete string constant UTF8 anywhere.
The wiki has more details.
Chuck
On Apr 5, 2011, at 3:43 AM, Amedeo Mantica wrote:
After moving my app from sessions IDs stored in
Schemas don't work if you have the following property true
com.webobjects.jdbcadaptor.PostgresqlExpression.enableIdentifierQuoting=true
I have a patch to fix this in
http://issues.objectstyle.org/jira/browse/WONDER-489
Postgresql PlugIn inconsistent application of identifier quoting to table
14 matches
Mail list logo
