[Trinidad] Feedback for Trinidad-2144: NumberConverter format hint changes
Hi everyone, I have some suggestions for changing the numberConverter's format hint which I would like to hear your feedback on. https://issues.apache.org/jira/browse/TRINIDAD-2144 Currently the numberConverter provides a hint using the converter's pattern like this: Sample pattern: ##.##. In particular, it follows JDK DecimalFormat's convention when the pattern is locale-independent, .ie . as decimal separator and , as grouping-separator. This has the following issues which could confuse users - It does not check if the trinidad-config parameters decimal-separator, number-grouping-separator are set. http://myfaces.apache.org/trinidad/devguide/configuration.html#trinidad-config.xml - It does not substitute the locale-specific character Therefore, I suggest the following. 1. Introduce two new trinidad-config parameters for currency-decimal-separator, currency-number-grouping-separator This is because some locales have different conventions for decimal separator when inside a currency. If not set, default to decimal/grouping-separator values. 2. If no parameters set in trinidad-config, substitute the locale-specific decimal/grouping separators. 3. Use a sample number instead of presenting the pattern, e.g. Sample pattern: 12,34 instead of Sample pattern: ##.##. Does anyone have feedback on suggestions #1, 2, 3? Thank you, Yee-Wah
Any Arabic speakers who can comment on [Trinidad-1958] Client tr:numberConverter with type=currency incorrectly handles arabic locale for positive values
Hi everyone, If you are familiar with Arabic, could you help confirm an issue raised in: https://issues.apache.org/jira/browse/TRINIDAD-1958 Specifically, is the following comment in the bug correct? That is, if I want to represent the value -9 in currency, this is correct: ar_SA: 9 ?? - where ?? are the currency symbols for the respective languages. Thanks, Yee-Wah
Re: tr:chooseDate date format different then DateFormat.getDateTimeInstance(DateFormat.SHORT
JeroenM wrote: I found out that adding tr:convertDateTime pattern=dd-MM-/ to the calendar solved my problem. Unfortunate this doesn't apply regional settings Hi Jeroen, Do you have formatting-locale set in trinidad-config.xml? http://myfaces.apache.org/trinidad/devguide/configuration.html Yee-Wah
Re: [Trinidad] tr:convertDateTime, pattern and client validation
Hi Lucas,
I was able to reproduce this. The problem is in the client datetime
converter, which assumes that years occupy 4 digits.
function _subparse (..)
case 'y': // year
var year = _accumulateNumber(parseContext, 4);
So, it parses a string like 981122 and gets year=9811, then runs out
of digits for the month and day. This hasn't been a more common problem
because there is usually a separator ('/' in en_us), so when the parse
encounters the separator char, it doesn't try to consume more
characters. In the en_us case, after it parses out year=98, it will fix
it to 1998 in _fix2DYear.
I'm not familiar with the history of shortish in the converter, it may
be why the client code assumes 4 characters for years. Tag doc states:
The default dateStyle is |shortish|. Shortish is identical to
|short| but forces the year to be a full four digits. |dateStyle|
defaults to |shortish| if it was not set.
If anyone knows if there is a limitation on date time converter
regarding 2 digit years, please chime in. Otherwise, this sounds like a
bug (workaround: use 4 digit years or separator char).
Yee-Wah
Lucas Satabin wrote:
Hello everybody,
I am trying to convert an input into a date using Trinidad.
tr:inputDate rendered=#{col.date}
value=#{co.value}
disabled=#{!col.edit}
required=false
tr:convertDateTime pattern=#{col.pattern} /
/tr:inputDate
It works fine for almost each pattern. I am however facing some
problems when the pattern becomes yyMMdd
In this case, as long as the client validation is allowed. I do not
have this problem anymore if I disable the client validation with
client-validationDISABLED/client-validation
With the client validation enabled, the value is never committed as
far as the validation fails. It prints : valid example: 981122
Obviously this example value does not work either. Is this problem
known? I searched for this but did not find anything.
Thanks in advance
Lucas
--
Ingénieur diplômé ENSEEIHT (Informatique) Lucas Satabin
Entwickler
FlexSecure GmbH
Industriestr. 12
D-64297 Darmstadt
Tel.: +49 (0) 6151 501 23-15
Fax.: +49 (0) 6151 501 23-19
E-mail: sata...@flexsecure.de mailto:sata...@flexsecure.de
Internet: www.flexsecure.de http://www.flexsecure.de
Geschäftsführer:
Erwin Stallenberger, Markus Ruppert
Amtsgericht Darmstadt HRB 8036
Umsatzsteuernummer: DE 214745269
Re: [Trinidad] tr:convertDateTime, pattern and client validation
Hi Lucas,
Yes, I suggest you file a JIRA with your use case.
Yee-Wah
Lucas Satabin wrote:
Hi Zee-wah
Thanks for the answer. It is also what I thought. I can not however not
change the pattern because it is a part of a file name I receive that I
must test. Should I open a ticket for this bug? As a workaround I
disabled the client validation and I do not have any problem anymore,
but I do not have the client message anymore :(
Lucas
Zee-wah Lee a écrit :
Hi Lucas,
I was able to reproduce this. The problem is in the client datetime
converter, which assumes that years occupy 4 digits.
function _subparse (..)
case 'y': // year
var year = _accumulateNumber(parseContext, 4);
So, it parses a string like 981122 and gets year=9811, then runs
out of digits for the month and day. This hasn't been a more common
problem because there is usually a separator ('/' in en_us), so when
the parse encounters the separator char, it doesn't try to consume
more characters. In the en_us case, after it parses out year=98, it
will fix it to 1998 in _fix2DYear.
I'm not familiar with the history of shortish in the converter, it
may be why the client code assumes 4 characters for years. Tag doc
states:
The default dateStyle is |shortish|. Shortish is identical to
|short| but forces the year to be a full four digits. |dateStyle|
defaults to |shortish| if it was not set.
If anyone knows if there is a limitation on date time converter
regarding 2 digit years, please chime in. Otherwise, this sounds like
a bug (workaround: use 4 digit years or separator char).
Yee-Wah
Lucas Satabin wrote:
Hello everybody,
I am trying to convert an input into a date using Trinidad.
tr:inputDate rendered=#{col.date}
value=#{co.value}
disabled=#{!col.edit}
required=false
tr:convertDateTime pattern=#{col.pattern} /
/tr:inputDate
It works fine for almost each pattern. I am however facing some
problems when the pattern becomes yyMMdd
In this case, as long as the client validation is allowed. I do not
have this problem anymore if I disable the client validation with
client-validationDISABLED/client-validation
With the client validation enabled, the value is never committed as
far as the validation fails. It prints : valid example: 981122
Obviously this example value does not work either. Is this problem
known? I searched for this but did not find anything.
Thanks in advance
Lucas
--
Ingénieur diplômé ENSEEIHT (Informatique) Lucas Satabin
Entwickler
FlexSecure GmbH
Industriestr. 12
D-64297 Darmstadt
Tel.: +49 (0) 6151 501 23-15
Fax.: +49 (0) 6151 501 23-19
E-mail:sata...@flexsecure.de mailto:sata...@flexsecure.de
Internet:www.flexsecure.de http://www.flexsecure.de
Geschäftsführer:
Erwin Stallenberger, Markus Ruppert
Amtsgericht Darmstadt HRB 8036
Umsatzsteuernummer: DE 214745269
Re: [rinidad] Bug in inputDate!?
Hi Daniel, I can repro with the inputDate live demos, using IE 8. I'm not sure about the tr:messages case. Can you reproduce this with the live demo, and what are the steps? Thanks, Yee-Wah Daniel Niklas wrote: Hi Matthias, Matthias Wessendorf-4 wrote: Did you find any similar issue in the jira ? I think that topic at least somehow rings my bell. Maybe Yee-Wah knows more ? You're right! There are several issues in jira: - http://issues.apache.org/jira/browse/TRINIDAD-1171 - cannot reproduce?! - http://issues.apache.org/jira/browse/TRINIDAD-1061 - created 01/May/08 - http://issues.apache.org/jira/browse/TRINIDAD-952 - causes this bug?! What next?
[Trinidad] DateTimeConverter and SimpleDateFormat changes in JDK 6 lead to issue with daylight savings
Hi everyone, The Trinidad DateTimeConverter has a problem when using JDK 6, because of changes in SimpleDateFormat. I have written a test case to replicate the converter's behavior. Test case: DateFormat df = DateFormat.getDateTimeInstance (DateFormat.SHORT, DateFormat.LONG); Date d = new Date(); // getFormattingTimeZone copied from trinidad-impl\DateTimeConverter.java, it clones the converter's timezone and gives it a // customID (GMT +/- offset)./ This affects the display name, e.g. instead of 'PST' it will display 'GMT-08:00' TimeZone tz = getFormattingTimeZone (df.getTimeZone()); df.setTimeZone (tz); System.out.println (The date is + d + , DateFormat.format() returns + df.format (d)); On JDK 1.5 this prints: The date is Wed Jul 08 10:55:25 PDT 2009, DateFormat.format() returns 7/8/09 10:55:25 AM GMT-07:00 On JDK 6: The date is Wed Jul 08 10:56:39 PDT 2009, DateFormat.format() returns 7/8/09 10:56:39 AM GMT-08:00 Notice that the offset in the second case is 8h. This is incorrect, the date (Jul 8 09) is in Pacific Daylight time (GMT-7), and if posted back, it would change the underlying data by +1h. I can understand why getFormattingTimeZone was originally used: timezone is thus always displayed in GMT +/- x, which helps when calculating offsets on the client side. I would like to discuss the possible fixes for the JDK 6 case (details to follow in second email), any input is welcome. I've filed a JIRA tracking this: https://issues.apache.org/jira/browse/TRINIDAD-1512 Thanks, Yee-Wah
Re: [Trinidad] DateTimeConverter and SimpleDateFormat changes in JDK 6 lead to issue with daylight savings: code snippets
Here is the code relevant to the discussion:
1) DateTimeConverter.java#getFormattingTimeZone(TimeZone tZone)
This effectively creates a custom timezone.
TimeZone zone = (TimeZone) tZone.clone();
// set the id as GMT Sign Hours : Minutes
StringBuilder zoneId = new StringBuilder(9);
int rawOffset = zone.getRawOffset();
.. code to calculate and append GMT +/- hours:mins
zone.setID(zoneId.toString());
return zone;
2) JDK 1.5: SimpleDateFormat#subFormat()
The 1.5 format code would look up a zone info file using the date's
offset and daylight savings.
case 17: // 'z' - ZONE_OFFSET
int zoneIndex =
formatData.getZoneIndex(calendar.getTimeZone().getID());
if (zoneIndex == -1) {
value = calendar.get(Calendar.ZONE_OFFSET) +
calendar.get(Calendar.DST_OFFSET);
buffer.append(ZoneInfoFile.toCustomID(value));
-Uses this code path
}
3) JDK 6: SimpleDateFormat#subFormat()
The 1.6 code now checks the DateFormatSymbols.locale and
isZoneStringsSet(). By default, the locale would be null and
zoneStringsSet = false unless user overrides either.
It then calls TimeZone.getDisplayName() instead of checking the
zoneInfoFile.
case 17: // 'z' - ZONE_OFFSET
if (formatData.locale == null || formatData.isZoneStringsSet) {
..
// same as 1.5, looks up zone info file
String[][] zoneStrings = formatData.getZoneStringsWrapper();
buffer.append(zoneStrings[zoneIndex][index]);
} else {
TimeZone tz = calendar.getTimeZone();
boolean daylight = (calendar.get(Calendar.DST_OFFSET) != 0);
int tzstyle = (count 4 ? TimeZone.SHORT : TimeZone.LONG);
buffer.append(tz.getDisplayName(daylight, tzstyle,
formatData.locale)); Uses this code path
}...
4) JDK 1.5/6: TimeZone.getDisplayName()
This method is the same in both JDKs, but only called in JDK 6 case. If
the ID is customized (GMT +/-x), it simply returns that.
String id = getID();
String[] names = getDisplayNames(id, locale);
if (names == null) {
if (id.startsWith(GMT)) {
char sign = id.charAt(3);
if (sign == '+' || sign == '-') {
return id;
Therefore, the display name for the Converter's timezone in JDK 6 is
fixed as its ID (GMT+/-rawOffset).
Notes:
1) Although this used to work in JDK 1.5, I'm not convinced this is a
JDK issue. Since we are creating a custom timezone in
getFormattingTimeZone(), and the JDK documentation states: No daylight
saving time transition schedule can be specified with a custom time zone
ID.
http://java.sun.com/javase/6/docs/api/java/util/TimeZone.html#setID%28java.lang.String
Arguably, the DateTimeConverter should get the formattingTimeZone() with
the value to be formatted included, so it instead does:
StringBuilder zoneId = new StringBuilder(9);
int offset = zone.getOffset((Date) value);
2) On the other hand, I don't understand the check in #subformat() for
formatData.locale or formatData.isZoneStringsSet.
It seems like a change for the default behavior in SimpleDateFormat
since most users will not plug-in their own DateFormatSymbols, and the
defaults for those fields is false.
Yee-Wah
Yee-wah Lee wrote:
Hi everyone,
The Trinidad DateTimeConverter has a problem when using JDK 6, because
of changes in SimpleDateFormat. I have written a test case to
replicate the converter's behavior.
Test case:
DateFormat df = DateFormat.getDateTimeInstance (DateFormat.SHORT,
DateFormat.LONG);
Date d = new Date();
// getFormattingTimeZone copied from
trinidad-impl\DateTimeConverter.java, it clones the converter's
timezone and gives it a
// customID (GMT +/- offset)./ This affects the display name,
e.g. instead of 'PST' it will display 'GMT-08:00'
TimeZone tz = getFormattingTimeZone (df.getTimeZone());
df.setTimeZone (tz);
System.out.println (The date is + d + , DateFormat.format()
returns + df.format (d));
On JDK 1.5 this prints:
The date is Wed Jul 08 10:55:25 PDT 2009, DateFormat.format() returns
7/8/09 10:55:25 AM GMT-07:00
On JDK 6:
The date is Wed Jul 08 10:56:39 PDT 2009, DateFormat.format() returns
7/8/09 10:56:39 AM GMT-08:00
Notice that the offset in the second case is 8h. This is incorrect,
the date (Jul 8 09) is in Pacific Daylight time (GMT-7), and if
posted back, it would change the underlying data by +1h.
I can understand why getFormattingTimeZone was originally used:
timezone is thus always displayed in GMT +/- x, which helps when
calculating offsets on the client side. I would like to discuss the
possible fixes for the JDK 6 case (details to follow in second email),
any input is welcome.
I've filed a JIRA tracking this:
https://issues.apache.org/jira/browse/TRINIDAD-1512
Thanks,
Yee-Wah
Re: Fwd: [Trinidad] Timezones - date picker popup shows a day before
Hi Denis, Please go ahead and file a JIRA. I was able to reproduce the problem so I briefly looked into it. If I'm not wrong, the problem should reproduce for dates that aren't picked using the dialog, i.e. dates that are predefaulted in the input, or hand-entered. When the user picks dates that are in the dialog, those dates have a millisecond value generated according to the application's timezone. But when the user hand-enters dates, the dates are created from strings according to the client's timezone leading to a discrepancy. So, in the example, 1/28/09 - Javascript date 1/28/09 01:00 UTC + 1. When sent back to the server, the server takes the millisecond value and recreates according to the application timezone - 1/27/09 20:00 UTC - 5. So, the 27th is highlighted. The methods I looked at: _ldp on the client, CalendarUtils#_adjustTimeZone and ChooseDateRenderer#encodeAll on the server. Thanks, Yee-Wah Denis Krukovsky wrote: Hi Yee-Wah, Thanks for the patch provided. I tested new 1.0.11 snapshot from Jan 28 and unfortunately that bug is still there. Would you suggest to submit a bug into JIRA? If anybody knows what's the reason please let me know. Steps to reproduce: - run a server with timezone set to US Eastern Time (GMT-5). - Create a page with Trinidad input date and date picker popup. - Query the page from a browser on a machine with timezone set to Central European Time (GMT+1). - Enter some date into input date field. - Click on datepicker icon. - Observe that date selected in datepicker is 1 day before the date entered into inputdate field. Thanks! -- Forwarded message -- From: Denis Krukovsky dkrukov...@gmail.com Date: Wed, Jan 14, 2009 at 6:22 PM Subject: Re: [Trinidad] Timezones - date picker popup shows a day before To: MyFaces Discussion users@myfaces.apache.org Hi, we tested with server running on current date (winter) with timezone I provided earlier, and the user also has worked with days from winter. So it can be like: server has 7 AM Jan 14, a client has 13:00 Jan 14. And in a browser we have say Jan 14 in a date input field, and date picker popup shows Jan 13 selected. The JIRA issue provided seems to be about wrong day RETURNED from the datepicker popup which we have not observed so far. Thanks for your advice on this. On Wed, Jan 14, 2009 at 6:09 PM, Yee-wah Lee yee-wah@oracle.com wrote: Hi Denis, Can you give further detail on your example? What date is the server running in, and what date does the user pick on the client? A possibly related JIRA: https://issues.apache.org/jira/browse/TRINIDAD-1349 Thanks, Yee-Wah Denis Krukovsky wrote: Hi, we're having problems with Trinidad date picker popup. Our server has timezone set as US Eastern time GMT-5. The server is queried from a workstation with timezone set to Central European time GMT+1. Date field is OK, but when its date picker pops up, the date selected there is input date field value - 1 day. This behavior gets fixed when we edit trinidad-config.xml and include time-zoneEtc/GMT-5/time-zone (server timezone) there. Unfortunately trinidad-config modification is not an option because servers and timezones will change. I tried to supply inputDate component with custom converter which returns server timezone from getTimeZone() and getFormattingTimeZone(...) which doesn't help. I also noted that in both cases - (1) no modification to trinidad-config and the bug is there, and (2) trinidad-config modified and bug gets fixed - the Trinidad date picker popup is being requested with equal request string containing something like /app/__ADFv__.jsf?_afPfm=-79d68df7_t=cdvalue=123189120loc=en-USenc=UTF-8, i. e. the value parameter is same for both cases but datepicker gets rendered differently. This behavior is there with Trinidad 1.0.7 and 1.0.10 . So is it a bug and does somebody knows a way to get it fixed? Thanks! Denis. -- Denis Krukovsky http://blogoforum.com/
Re: [Trinidad] Timezones - date picker popup shows a day before
Hi Denis, Can you give further detail on your example? What date is the server running in, and what date does the user pick on the client? A possibly related JIRA: https://issues.apache.org/jira/browse/TRINIDAD-1349 Thanks, Yee-Wah Denis Krukovsky wrote: Hi, we're having problems with Trinidad date picker popup. Our server has timezone set as US Eastern time GMT-5. The server is queried from a workstation with timezone set to Central European time GMT+1. Date field is OK, but when its date picker pops up, the date selected there is input date field value - 1 day. This behavior gets fixed when we edit trinidad-config.xml and include time-zoneEtc/GMT-5/time-zone (server timezone) there. Unfortunately trinidad-config modification is not an option because servers and timezones will change. I tried to supply inputDate component with custom converter which returns server timezone from getTimeZone() and getFormattingTimeZone(...) which doesn't help. I also noted that in both cases - (1) no modification to trinidad-config and the bug is there, and (2) trinidad-config modified and bug gets fixed - the Trinidad date picker popup is being requested with equal request string containing something like /app/__ADFv__.jsf?_afPfm=-79d68df7_t=cdvalue=123189120loc=en-USenc=UTF-8, i. e. the value parameter is same for both cases but datepicker gets rendered differently. This behavior is there with Trinidad 1.0.7 and 1.0.10 . So is it a bug and does somebody knows a way to get it fixed? Thanks! Denis.
Re: [Trinidad] Problem upgrading to version 1.0.5 of trinidad.
Hi,
Since TRINIDAD-797 was closed, I created TRINIDAD-1150 to track this issue:
https://issues.apache.org/jira/browse/TRINIDAD-1150
And attached both patches (1.1 and 1.2 trunk) for completeness, though
only the 1.2 trunk needs to be applied at this time.
Thanks,
Yee-Wah
Scott O'Bryan wrote:
Yeah, it should have been ported Yee. Sorry about the oversite.
Scott
Yee-wah Lee wrote:
Hi Rogerio,
The patch is attached to issue 797
(trin11_797_deferredRenderers.patch
https://issues.apache.org/jira/secure/attachment/12375620/trin11_797_deferredRenderers.patch)
https://issues.apache.org/jira/browse/TRINIDAD-797
It looks like the fix was not ported to the 1.2.x branch. I will
create one and ask for it to be applied.
Thanks,
Yee-Wah
Rogerio Baldini wrote:
Hi ,
Have you solved this problem ?
I am trying to upgrade from Trinidad 1.2.1 to 1.2.8 and receiving this
error:
SEVERE: Exception sending context initialized event to listener
instance of
class com.sun.faces.config.ConfigureListener
java.lang.ExceptionInInitializerError
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelfWithKey(Scriptlet.java:163)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelf(Scriptlet.java:92)
...
Caused by: java.lang.NullPointerException
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:168)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.init(NamedLocaleInfoScriptlet.java:62)
...
And I hava my own render kit.
public class PlcRenderKit extends CoreRenderKit {
public PlcRenderKit() {
super();
}
private void _addTrinidadRenderKit() {
FacesContext facesContext=null;
RenderKit trinidad = getTrinidadRenderKit(facesContext);
if (trinidad!=null) {
attachAggregatedRenderKit(trinidad);
}
}
private RenderKit getTrinidadRenderKit(FacesContext facesContext) {
RenderKitFactory rkf =
(RenderKitFactory)FactoryFinder.getFactory(FactoryFinder.RENDER_KIT_FACTORY);
return rkf.getRenderKit(facesContext,
CoreRenderKit.BASE_RENDER_KIT_ID);
}
@Override
public Renderer findRenderer(String family, String rendererType) {
Renderer renderer = super.findRenderer(family, rendererType);
if (renderer==null) {
RenderKit rk =
getTrinidadRenderKit(FacesContext.getCurrentInstance());
renderer = rk.getRenderer(family, rendererType);
}
return renderer;
}
}
Thanks a lot.
Rogerio Baldini
Yee-wah Lee wrote:
After some testing, the problem was due to the RenderingContext
being null. Scriptlet initialization was happening during a static
block of the SimpleInputColorRenderer, not during the render phase,
which explains why the RenderingContext is null.
This doesn't appear to be a problem for Trinidad because the
Trinidad renderkit implements deferred loading of renderers. In
Ian's case, he is extending a renderer and adding it to the Faces
renderkit.
I will submit an addition to the patch to allow for extended
renderers not being in the Trinidad renderkit.
Thanks,
Yee-Wah
Yee-wah Lee wrote:
I'll take a look at this. The line at which the code is failing
indicates the LocaleContext is null, or the FormattingLocale is
null. Not sure which is the problem here.
If anyone else has seen this problem, please reply with details on
your environment.
Thanks,
Yee-Wah
Matthias Wessendorf wrote:
that file NamedLocaleInfoScriptlet was add when fixing 797.
stay tuned.
-M
On Jan 18, 2008 4:37 AM, Ian Carr
[EMAIL PROTECTED] wrote:
I have tried to upgrade two applications to the Trinidad 1.0.5
release from 1.0.4. One worked fine the second results in an
exception during application startup. Both applications start
fine with 1.0.4.
I have checked the configurations and can't see anything
obviously in error. Does anybody have an idea of what I need to do?
I have looked at the release notes (which still say they are for
1.0.3) and didn't see anything there.
Both applications are using the sun reference implementation of
JSF (1.1_02) and the runtime environment is Tomcat 5.5.
Exception trace below:
===
SEVERE: Exception sending context initialized event to listener
instance of class com.sun.faces.config.ConfigureListener
java.lang.ExceptionInInitializerError
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelfWithKey(Scriptlet.java:163)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelf(Scriptlet.java:92)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleInputColorRenderer.clinit(SimpleInputColorRenderer.java:622
Re: [Trinidad] Problem upgrading to version 1.0.5 of trinidad.
Hi Rogerio,
The patch is attached to issue 797 (trin11_797_deferredRenderers.patch
https://issues.apache.org/jira/secure/attachment/12375620/trin11_797_deferredRenderers.patch)
https://issues.apache.org/jira/browse/TRINIDAD-797
It looks like the fix was not ported to the 1.2.x branch. I will create
one and ask for it to be applied.
Thanks,
Yee-Wah
Rogerio Baldini wrote:
Hi ,
Have you solved this problem ?
I am trying to upgrade from Trinidad 1.2.1 to 1.2.8 and receiving this
error:
SEVERE: Exception sending context initialized event to listener instance of
class com.sun.faces.config.ConfigureListener
java.lang.ExceptionInInitializerError
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelfWithKey(Scriptlet.java:163)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelf(Scriptlet.java:92)
...
Caused by: java.lang.NullPointerException
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:168)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.init(NamedLocaleInfoScriptlet.java:62)
...
And I hava my own render kit.
public class PlcRenderKit extends CoreRenderKit {
public PlcRenderKit() {
super();
}
private void _addTrinidadRenderKit() {
FacesContext facesContext=null;
RenderKit trinidad = getTrinidadRenderKit(facesContext);
if (trinidad!=null) {
attachAggregatedRenderKit(trinidad);
}
}
private RenderKit getTrinidadRenderKit(FacesContext facesContext) {
RenderKitFactory rkf =
(RenderKitFactory)FactoryFinder.getFactory(FactoryFinder.RENDER_KIT_FACTORY);
return rkf.getRenderKit(facesContext, CoreRenderKit.BASE_RENDER_KIT_ID);
}
@Override
public Renderer findRenderer(String family, String rendererType) {
Renderer renderer = super.findRenderer(family, rendererType);
if (renderer==null) {
RenderKit rk =
getTrinidadRenderKit(FacesContext.getCurrentInstance());
renderer = rk.getRenderer(family, rendererType);
}
return renderer;
}
}
Thanks a lot.
Rogerio Baldini
Yee-wah Lee wrote:
After some testing, the problem was due to the RenderingContext being
null. Scriptlet initialization was happening during a static block of
the SimpleInputColorRenderer, not during the render phase, which
explains why the RenderingContext is null.
This doesn't appear to be a problem for Trinidad because the Trinidad
renderkit implements deferred loading of renderers. In Ian's case, he is
extending a renderer and adding it to the Faces renderkit.
I will submit an addition to the patch to allow for extended renderers
not being in the Trinidad renderkit.
Thanks,
Yee-Wah
Yee-wah Lee wrote:
I'll take a look at this. The line at which the code is failing
indicates the LocaleContext is null, or the FormattingLocale is null.
Not sure which is the problem here.
If anyone else has seen this problem, please reply with details on
your environment.
Thanks,
Yee-Wah
Matthias Wessendorf wrote:
that file NamedLocaleInfoScriptlet was add when fixing 797.
stay tuned.
-M
On Jan 18, 2008 4:37 AM, Ian Carr [EMAIL PROTECTED]
wrote:
I have tried to upgrade two applications to the Trinidad 1.0.5
release from 1.0.4. One worked fine the second results in an
exception during application startup. Both applications start fine
with 1.0.4.
I have checked the configurations and can't see anything obviously
in error. Does anybody have an idea of what I need to do?
I have looked at the release notes (which still say they are for
1.0.3) and didn't see anything there.
Both applications are using the sun reference implementation of JSF
(1.1_02) and the runtime environment is Tomcat 5.5.
Exception trace below:
===
SEVERE: Exception sending context initialized event to listener
instance of class com.sun.faces.config.ConfigureListener
java.lang.ExceptionInInitializerError
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelfWithKey(Scriptlet.java:163)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelf(Scriptlet.java:92)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleInputColorRenderer.clinit(SimpleInputColorRenderer.java:622)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.InputColorRenderer.findTypeConstants(InputColorRenderer.java:45)
at
fsl.trinidad.extensions.kit.FSLInputColorRenderer.findTypeConstants(FSLInputColorRenderer.java:18
Re: [TRINIDAD] PPR not blocking user input in IE7
Hi Rafa, Please go ahead and file a JIRA. I suspect this may have been introduced by my checkin on https://issues.apache.org/jira/browse/TRINIDAD-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanelTRINIDAD-952, which was IE-specific. https://issues.apache.org/jira/browse/TRINIDAD-952 Additionally, if you can confirm if it is a regression (it worked before 1.0.7) and add that info to the bug, that would be great. Here is also another JIRA filed on Trinidad handling multiple PPRs in general, for reference. https://issues.apache.org/jira/browse/TRINIDAD-1053 Thanks, Yee-Wah Rafa Pérez wrote: Hi all, I have a selectOneChoice with autoSubmit=true in my jsp. When it changes, a PPR event is send to the server, who performs a search and fill another selectOneChoice. In IE7, if I click on a commandButton just before the PPR cycle is completed, the submit event takes place and an ArrayIndexOutOfBounds exception is thrown. In Firefox 2, it works ok. Is it possible to make IE works as expected? Thanks in advance, - - Rafa
Re: [Trinidad] skinning all input components
Hi Markus, Did you check the aliases to see if any of them could help? http://myfaces.apache.org/trinidad/devguide/skinning.html#Alias_skinning_keys http://myfaces.apache.org/trinidad/skin-selectors.html Thanks, Yee-Wah Döring Markus wrote: Hi all, I’m currently skinning some input components to have some nice style. I’ve completed it for the tr:inputText, but I don’t want to copy-past the style to every input component (like selectOneChoice, selectManyChoice, ect. ect.) Is there an easy way (global skin selector) to skin the all of the input components at once (like af:input:content or something like this) Thanks for help Markus Döring TCC Products GmbH
Re: Problem with maximum on date
Hi Veena, Can you reproduce the problem on the demos? On this page, there is an inputDate which sets the maximum to today: Search for *A inputDate with a validator that sets a maximum date * http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx In this example, the maxDate is just set to new Date(). Although this may have problems as we discussed on TRINIDAD-61, when I test the popup, it shows the 11th (this date) as being available to select, and dates starting from the 12th are greyed out/disabled. What do you see for your example? Thanks, Yee-Wah Matthias Wessendorf wrote: Hi, On Tue, Mar 11, 2008 at 7:09 PM, veena pandit [EMAIL PROTECTED] wrote: How and where am I looking for TRINIDAD-790 https://issues.apache.org/jira/browse/TRINIDAD-790 -Matthias On 3/11/08, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, On Tue, Mar 11, 2008 at 5:29 PM, veena pandit [EMAIL PROTECTED] wrote: When the maximum date is set to March 30th without maxing out the other time parameters; the calendar shows a max date of March 29th; Any suggestions? I haven't had a chance to look closely to TRINIDAD-790, but that issue sounds like yours. -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Trinidad] Problem upgrading to version 1.0.5 of trinidad.
After some testing, the problem was due to the RenderingContext being null. Scriptlet initialization was happening during a static block of the SimpleInputColorRenderer, not during the render phase, which explains why the RenderingContext is null. This doesn't appear to be a problem for Trinidad because the Trinidad renderkit implements deferred loading of renderers. In Ian's case, he is extending a renderer and adding it to the Faces renderkit. I will submit an addition to the patch to allow for extended renderers not being in the Trinidad renderkit. Thanks, Yee-Wah Yee-wah Lee wrote: I'll take a look at this. The line at which the code is failing indicates the LocaleContext is null, or the FormattingLocale is null. Not sure which is the problem here. If anyone else has seen this problem, please reply with details on your environment. Thanks, Yee-Wah Matthias Wessendorf wrote: that file NamedLocaleInfoScriptlet was add when fixing 797. stay tuned. -M On Jan 18, 2008 4:37 AM, Ian Carr [EMAIL PROTECTED] wrote: I have tried to upgrade two applications to the Trinidad 1.0.5 release from 1.0.4. One worked fine the second results in an exception during application startup. Both applications start fine with 1.0.4. I have checked the configurations and can't see anything obviously in error. Does anybody have an idea of what I need to do? I have looked at the release notes (which still say they are for 1.0.3) and didn't see anything there. Both applications are using the sun reference implementation of JSF (1.1_02) and the runtime environment is Tomcat 5.5. Exception trace below: === SEVERE: Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener java.lang.ExceptionInInitializerError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelfWithKey(Scriptlet.java:163) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelf(Scriptlet.java:92) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleInputColorRenderer.clinit(SimpleInputColorRenderer.java:622) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.InputColorRenderer.findTypeConstants(InputColorRenderer.java:45) at fsl.trinidad.extensions.kit.FSLInputColorRenderer.findTypeConstants(FSLInputColorRenderer.java:18) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlRenderer.init(XhtmlRenderer.java:53) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.LabelAndMessageRenderer.init(LabelAndMessageRenderer.java:49) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.InputLabelAndMessageRenderer.init(InputLabelAndMessageRenderer.java:41) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.InputColorRenderer.init(InputColorRenderer.java:33) at fsl.trinidad.extensions.kit.FSLInputColorRenderer.init(FSLInputColorRenderer.java:9) at fsl.trinidad.extensions.kit.FSLRenderKit.init(FSLRenderKit.java:17) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at java.lang.Class.newInstance0(Class.java:350) at java.lang.Class.newInstance(Class.java:303) at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:935) at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:426) at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:348) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3763) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4211) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke
Re: [Trinidad] Problem upgrading to version 1.0.5 of trinidad.
I'll take a look at this. The line at which the code is failing indicates the LocaleContext is null, or the FormattingLocale is null. Not sure which is the problem here. If anyone else has seen this problem, please reply with details on your environment. Thanks, Yee-Wah Matthias Wessendorf wrote: that file NamedLocaleInfoScriptlet was add when fixing 797. stay tuned. -M On Jan 18, 2008 4:37 AM, Ian Carr [EMAIL PROTECTED] wrote: I have tried to upgrade two applications to the Trinidad 1.0.5 release from 1.0.4. One worked fine the second results in an exception during application startup. Both applications start fine with 1.0.4. I have checked the configurations and can't see anything obviously in error. Does anybody have an idea of what I need to do? I have looked at the release notes (which still say they are for 1.0.3) and didn't see anything there. Both applications are using the sun reference implementation of JSF (1.1_02) and the runtime environment is Tomcat 5.5. Exception trace below: === SEVERE: Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener java.lang.ExceptionInInitializerError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelfWithKey(Scriptlet.java:163) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelf(Scriptlet.java:92) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleInputColorRenderer.clinit(SimpleInputColorRenderer.java:622) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.InputColorRenderer.findTypeConstants(InputColorRenderer.java:45) at fsl.trinidad.extensions.kit.FSLInputColorRenderer.findTypeConstants(FSLInputColorRenderer.java:18) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlRenderer.init(XhtmlRenderer.java:53) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.LabelAndMessageRenderer.init(LabelAndMessageRenderer.java:49) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.InputLabelAndMessageRenderer.init(InputLabelAndMessageRenderer.java:41) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.InputColorRenderer.init(InputColorRenderer.java:33) at fsl.trinidad.extensions.kit.FSLInputColorRenderer.init(FSLInputColorRenderer.java:9) at fsl.trinidad.extensions.kit.FSLRenderKit.init(FSLRenderKit.java:17) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at java.lang.Class.newInstance0(Class.java:350) at java.lang.Class.newInstance(Class.java:303) at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:935) at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:426) at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:348) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3763) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4211) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) Caused by: java.lang.NullPointerException at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:168) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.init(NamedLocaleInfoScriptlet.java:62) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47)
