Home » Eclipse Projects » Remote Application Platform (RAP) » Upgrade from RAP 1.2.1 to 1.2.2 because of Firefox 3.6 - possible WAR deployment procedure problem
| Upgrade from RAP 1.2.1 to 1.2.2 because of Firefox 3.6 - possible WAR deployment procedure problem [message #539190] |
Wed, 09 June 2010 21:27  |
 Ryan Donnelly
Messages: 35
Registered: July 2009 |
Member |
|
|
Hi,
I am upgrading from RAP 1.2.1 to 1.2.2 because of the following:
#294981 Several widgets don't work in Firefox 3.6
https://bugs.eclipse.org/bugs/show_bug.cgi?id=294981
and I am running into a problem that causes me to question my WAR
deployment procedure:
In my application, with RAP 1.2.1 as I have it now, in Firefox 3.6.3,
for a ToolItem widget with SWT.DROP_DOWN, when I click on the
upside-down triangle for the drop-down, nothing happens. When I upgrade
my target platform to 1.2.2, and run in Eclipse, the problem is fixed -
the widget works and the dropdown shows.
However, when I build the application into a WAR and run it under
Tomcat, when I click on the widget I get the error:
java.lang.NumberFormatException: For input string: "320.79998779296875"
java.lang.NumberFormatException.forInputString(Unknown Source)
java.lang.Integer.parseInt(Unknown Source)
java.lang.Integer.parseInt(Unknown Source)
org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBoundsValue(Widg etLCAUtil.java:873)
org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBoundsX(WidgetLC AUtil.java:853)
org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBounds(WidgetLCA Util.java:327)
org.eclipse.swt.internal.widgets.toolitemkit.DropDownToolIte mLCA.readData(DropDownToolItemLCA.java:60)
org.eclipse.swt.internal.widgets.toolitemkit.ToolItemLCA.rea dData(ToolItemLCA.java:40)
org.eclipse.swt.internal.widgets.displaykit.DisplayLCA$1.doV isit(DisplayLCA.java:320)
org.eclipse.swt.internal.widgets.WidgetTreeVisitor$AllWidget TreeVisitor.visit(WidgetTreeVisitor.java:28)
org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:59)
org.eclipse.swt.internal.widgets.WidgetTreeVisitor.handleIte ms(WidgetTreeVisitor.java:91)
org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:48)
org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
org.eclipse.swt.internal.widgets.displaykit.DisplayLCA.readD ata(DisplayLCA.java:327)
org.eclipse.rwt.internal.lifecycle.ReadData.execute(ReadData .java:26)
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.continueLife Cycle(RWTLifeCycle.java:209)
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.sleep(RWTLif eCycle.java:312)
org.eclipse.swt.widgets.Display.sleep(Display.java:790)
com.lti.swtutils.DispatchLoop.readAndDispatch(DispatchLoop.j ava:37)
com.quintron.vx.gui.AppImpl.run(AppImpl.java:1546)
com.quintron.vx.rwt.WebApp.createUI(WebApp.java:178)
org.eclipse.rwt.internal.lifecycle.EntryPointManager.createU I(EntryPointManager.java:92)
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.createUI(RWT LifeCycle.java:231)
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadCont roller.run(RWTLifeCycle.java:119)
java.lang.Thread.run(Unknown Source)
Stepping through the code, I can see that running under Eclipse we have
an Integer here, causing no problem.
org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBoundsValue(Widg etLCAUtil.java:873)
whereas with the WAR/Tomcat we get the non-integer value.
I can see that there has been work in this area since 1.2.2, such as:
#306842 JS error in TableColumnLCA
https://bugs.eclipse.org/bugs/show_bug.cgi?id=306842
#289336 [ToolBar] Implement new client-side ToolBar
https://bugs.eclipse.org/bugs/show_bug.cgi?id=289336
Can you shed some light on why I get an Integer running under Eclipse
and a Long running the WAR? Can I fix this by fixing my WAR deployment
procedure or is this likely a bug that was fixed after 1.2.2 or possibly
a new bug?
If the problem is with my WAR deployment procedure, could someone on
the RAP team please clear up for me what is the WAR deployment procedure
for 1.2.2? It seems to me that the procedure in the Eclipse Help
article "WAR Deployment" is out of date, even with the help file
provided by the latest (1.3 RC3) tooling.
Specifically, the servletbridge project
org.eclipse.equinox.servletbridge.extensionbundle
is not mentioned in the article - it is not present in the bundle
included in the help article:
http://127.0.0.1:49165/help/topic/org.eclipse.rap.help/help/ html/advanced/servletbridge-anon.psf
nor is it in feature.xml from HEAD in org.eclipse.rap.demo.feature.
However, sources such as the following lead me to believe that it is
required.
http://wiki.eclipse.org/RAP/FAQ#Exported_WAR_file_does_not_w ork
#293020 War-deployment fails with equinox bridgeservlet from HEAD
https://bugs.eclipse.org/bugs/show_bug.cgi?id=293020
If it is required, is there anything I need to do other than check out
the project and include it in feature.xml before I run the webAppBuilder
script?
Is there anything else required that is not mentioned in the Help article?
Since the WAR deployment procedure involves compiling the
servletbridge, the question arises, what version of the servletbridge
projects should I have in my workspace when running the webAppBuilder
script? I have tried both the latest from HEAD (incl. the
extensionbundle project) and the CVS source as of 27/01/2010 (the day
after the 1.2.2 release).
I understand that the WAR deployment procedure is likely in flux as the
1.3 release approaches, and that you are also working towards a more
automated procedure (https://bugs.eclipse.org/bugs/show_bug.cgi?id=279743).
However, I am trying to work with the latest stable, 1.2.2, rather than
1.3 exactly because it is more stable than 1.3.
I appreciate any help you can offer.
Thanks,
Ryan Donnelly
|
|
|
| Re: Upgrade from RAP 1.2.1 to 1.2.2 because of Firefox 3.6 - possible WAR deployment procedure probl [message #539202 is a reply to message #539190] |
Wed, 09 June 2010 22:39  |
Ryan Donnelly
Messages: 35
Registered: July 2009 |
Member |
|
|
Sorry, below, I meant to say:
"Can you shed some light on why I get an integer running under Eclipse
and a non-integer running the WAR?"
Ryan Donnelly wrote:
> Hi,
> I am upgrading from RAP 1.2.1 to 1.2.2 because of the following:
>
> #294981 Several widgets don't work in Firefox 3.6
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=294981
>
> and I am running into a problem that causes me to question my WAR
> deployment procedure:
>
>
> In my application, with RAP 1.2.1 as I have it now, in Firefox
> 3.6.3, for a ToolItem widget with SWT.DROP_DOWN, when I click on the
> upside-down triangle for the drop-down, nothing happens. When I upgrade
> my target platform to 1.2.2, and run in Eclipse, the problem is fixed -
> the widget works and the dropdown shows.
>
> However, when I build the application into a WAR and run it under
> Tomcat, when I click on the widget I get the error:
>
> java.lang.NumberFormatException: For input string: "320.79998779296875"
> java.lang.NumberFormatException.forInputString(Unknown Source)
> java.lang.Integer.parseInt(Unknown Source)
> java.lang.Integer.parseInt(Unknown Source)
> org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBoundsValue(Widg etLCAUtil.java:873)
>
> org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBoundsX(WidgetLC AUtil.java:853)
>
> org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBounds(WidgetLCA Util.java:327)
>
> org.eclipse.swt.internal.widgets.toolitemkit.DropDownToolIte mLCA.readData(DropDownToolItemLCA.java:60)
>
> org.eclipse.swt.internal.widgets.toolitemkit.ToolItemLCA.rea dData(ToolItemLCA.java:40)
>
> org.eclipse.swt.internal.widgets.displaykit.DisplayLCA$1.doV isit(DisplayLCA.java:320)
>
> org.eclipse.swt.internal.widgets.WidgetTreeVisitor$AllWidget TreeVisitor.visit(WidgetTreeVisitor.java:28)
>
> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:59)
>
> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.handleIte ms(WidgetTreeVisitor.java:91)
>
> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:48)
>
> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>
> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>
> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>
> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>
> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>
> org.eclipse.swt.internal.widgets.displaykit.DisplayLCA.readD ata(DisplayLCA.java:327)
>
> org.eclipse.rwt.internal.lifecycle.ReadData.execute(ReadData .java:26)
> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.continueLife Cycle(RWTLifeCycle.java:209)
>
> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.sleep(RWTLif eCycle.java:312)
>
> org.eclipse.swt.widgets.Display.sleep(Display.java:790)
> com.lti.swtutils.DispatchLoop.readAndDispatch(DispatchLoop.j ava:37)
> com.quintron.vx.gui.AppImpl.run(AppImpl.java:1546)
> com.quintron.vx.rwt.WebApp.createUI(WebApp.java:178)
> org.eclipse.rwt.internal.lifecycle.EntryPointManager.createU I(EntryPointManager.java:92)
>
> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.createUI(RWT LifeCycle.java:231)
>
> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadCont roller.run(RWTLifeCycle.java:119)
>
> java.lang.Thread.run(Unknown Source)
>
>
>
>
> Stepping through the code, I can see that running under Eclipse we
> have an Integer here, causing no problem.
>
> org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBoundsValue(Widg etLCAUtil.java:873)
>
>
> whereas with the WAR/Tomcat we get the non-integer value.
>
>
>
> I can see that there has been work in this area since 1.2.2, such as:
>
> #306842 JS error in TableColumnLCA
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=306842
>
> #289336 [ToolBar] Implement new client-side ToolBar
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=289336
>
>
> Can you shed some light on why I get an Integer running under
> Eclipse and a Long running the WAR? Can I fix this by fixing my WAR
> deployment procedure or is this likely a bug that was fixed after 1.2.2
> or possibly a new bug?
>
>
> If the problem is with my WAR deployment procedure, could someone on
> the RAP team please clear up for me what is the WAR deployment procedure
> for 1.2.2? It seems to me that the procedure in the Eclipse Help
> article "WAR Deployment" is out of date, even with the help file
> provided by the latest (1.3 RC3) tooling.
>
> Specifically, the servletbridge project
>
> org.eclipse.equinox.servletbridge.extensionbundle
>
> is not mentioned in the article - it is not present in the bundle
> included in the help article:
>
> http://127.0.0.1:49165/help/topic/org.eclipse.rap.help/help/ html/advanced/servletbridge-anon.psf
>
>
> nor is it in feature.xml from HEAD in org.eclipse.rap.demo.feature.
>
>
> However, sources such as the following lead me to believe that it is
> required.
>
>
> http://wiki.eclipse.org/RAP/FAQ#Exported_WAR_file_does_not_w ork
>
> #293020 War-deployment fails with equinox bridgeservlet from HEAD
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=293020
>
>
> If it is required, is there anything I need to do other than check
> out the project and include it in feature.xml before I run the
> webAppBuilder script?
>
> Is there anything else required that is not mentioned in the Help
> article?
>
> Since the WAR deployment procedure involves compiling the
> servletbridge, the question arises, what version of the servletbridge
> projects should I have in my workspace when running the webAppBuilder
> script? I have tried both the latest from HEAD (incl. the
> extensionbundle project) and the CVS source as of 27/01/2010 (the day
> after the 1.2.2 release).
>
>
>
> I understand that the WAR deployment procedure is likely in flux as
> the 1.3 release approaches, and that you are also working towards a more
> automated procedure (https://bugs.eclipse.org/bugs/show_bug.cgi?id=279743).
>
> However, I am trying to work with the latest stable, 1.2.2, rather than
> 1.3 exactly because it is more stable than 1.3.
>
>
> I appreciate any help you can offer.
>
>
> Thanks,
>
> Ryan Donnelly
|
|
|
| Re: Upgrade from RAP 1.2.1 to 1.2.2 because of Firefox 3.6 - possible WAR deployment procedure probl [message #539296 is a reply to message #539202] |
Thu, 10 June 2010 09:25 |
|
Hi Ryan,
this sounds like a bug. JavaScript doesn't know integers, just numbers.
It seems that there is some rare case that cause a bounds parameter to
be transmitted as a floating point number and we don't handle this case.
It can't be related to Tomcat vs. Jetty. Maybe you have some workbench
layout stored in the settings cookie for the Tomcat server. Could you
open a bug with the stack trace?
Thanks, Ralf
Ryan Donnelly wrote:
> Sorry, below, I meant to say:
>
> "Can you shed some light on why I get an integer running under Eclipse
> and a non-integer running the WAR?"
>
>
> Ryan Donnelly wrote:
>> Hi,
>> I am upgrading from RAP 1.2.1 to 1.2.2 because of the following:
>>
>> #294981 Several widgets don't work in Firefox 3.6
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=294981
>>
>> and I am running into a problem that causes me to question my WAR
>> deployment procedure:
>>
>>
>> In my application, with RAP 1.2.1 as I have it now, in Firefox
>> 3.6.3, for a ToolItem widget with SWT.DROP_DOWN, when I click on the
>> upside-down triangle for the drop-down, nothing happens. When I
>> upgrade my target platform to 1.2.2, and run in Eclipse, the problem
>> is fixed - the widget works and the dropdown shows.
>>
>> However, when I build the application into a WAR and run it under
>> Tomcat, when I click on the widget I get the error:
>>
>> java.lang.NumberFormatException: For input string: "320.79998779296875"
>> java.lang.NumberFormatException.forInputString(Unknown Source)
>> java.lang.Integer.parseInt(Unknown Source)
>> java.lang.Integer.parseInt(Unknown Source)
>>
>> org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBoundsValue(Widg etLCAUtil.java:873)
>>
>>
>> org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBoundsX(WidgetLC AUtil.java:853)
>>
>>
>> org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBounds(WidgetLCA Util.java:327)
>>
>>
>> org.eclipse.swt.internal.widgets.toolitemkit.DropDownToolIte mLCA.readData(DropDownToolItemLCA.java:60)
>>
>>
>> org.eclipse.swt.internal.widgets.toolitemkit.ToolItemLCA.rea dData(ToolItemLCA.java:40)
>>
>>
>> org.eclipse.swt.internal.widgets.displaykit.DisplayLCA$1.doV isit(DisplayLCA.java:320)
>>
>>
>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor$AllWidget TreeVisitor.visit(WidgetTreeVisitor.java:28)
>>
>>
>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:59)
>>
>>
>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.handleIte ms(WidgetTreeVisitor.java:91)
>>
>>
>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:48)
>>
>>
>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>
>>
>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>
>>
>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>
>>
>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>
>>
>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>
>>
>> org.eclipse.swt.internal.widgets.displaykit.DisplayLCA.readD ata(DisplayLCA.java:327)
>>
>> org.eclipse.rwt.internal.lifecycle.ReadData.execute(ReadData .java:26)
>>
>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.continueLife Cycle(RWTLifeCycle.java:209)
>>
>>
>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.sleep(RWTLif eCycle.java:312)
>>
>> org.eclipse.swt.widgets.Display.sleep(Display.java:790)
>> com.lti.swtutils.DispatchLoop.readAndDispatch(DispatchLoop.j ava:37)
>> com.quintron.vx.gui.AppImpl.run(AppImpl.java:1546)
>> com.quintron.vx.rwt.WebApp.createUI(WebApp.java:178)
>>
>> org.eclipse.rwt.internal.lifecycle.EntryPointManager.createU I(EntryPointManager.java:92)
>>
>>
>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.createUI(RWT LifeCycle.java:231)
>>
>>
>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadCont roller.run(RWTLifeCycle.java:119)
>>
>> java.lang.Thread.run(Unknown Source)
>>
>>
>>
>>
>> Stepping through the code, I can see that running under Eclipse we
>> have an Integer here, causing no problem.
>>
>> org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBoundsValue(Widg etLCAUtil.java:873)
>>
>>
>> whereas with the WAR/Tomcat we get the non-integer value.
>>
>>
>>
>> I can see that there has been work in this area since 1.2.2, such as:
>>
>> #306842 JS error in TableColumnLCA
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=306842
>>
>> #289336 [ToolBar] Implement new client-side ToolBar
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=289336
>>
>>
>> Can you shed some light on why I get an Integer running under
>> Eclipse and a Long running the WAR? Can I fix this by fixing my WAR
>> deployment procedure or is this likely a bug that was fixed after
>> 1.2.2 or possibly a new bug?
>>
>>
>> If the problem is with my WAR deployment procedure, could someone
>> on the RAP team please clear up for me what is the WAR deployment
>> procedure for 1.2.2? It seems to me that the procedure in the Eclipse
>> Help article "WAR Deployment" is out of date, even with the help file
>> provided by the latest (1.3 RC3) tooling.
>>
>> Specifically, the servletbridge project
>> org.eclipse.equinox.servletbridge.extensionbundle
>>
>> is not mentioned in the article - it is not present in the bundle
>> included in the help article:
>>
>> http://127.0.0.1:49165/help/topic/org.eclipse.rap.help/help/ html/advanced/servletbridge-anon.psf
>>
>>
>> nor is it in feature.xml from HEAD in org.eclipse.rap.demo.feature.
>>
>>
>> However, sources such as the following lead me to believe that it
>> is required.
>>
>>
>> http://wiki.eclipse.org/RAP/FAQ#Exported_WAR_file_does_not_w ork
>>
>> #293020 War-deployment fails with equinox bridgeservlet from HEAD
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=293020
>>
>>
>> If it is required, is there anything I need to do other than check
>> out the project and include it in feature.xml before I run the
>> webAppBuilder script?
>>
>> Is there anything else required that is not mentioned in the Help
>> article?
>>
>> Since the WAR deployment procedure involves compiling the
>> servletbridge, the question arises, what version of the
>> servletbridge projects should I have in my workspace when running the
>> webAppBuilder script? I have tried both the latest from HEAD (incl.
>> the extensionbundle project) and the CVS source as of 27/01/2010 (the
>> day after the 1.2.2 release).
>>
>>
>>
>> I understand that the WAR deployment procedure is likely in flux
>> as the 1.3 release approaches, and that you are also working towards a
>> more automated procedure
>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=279743).
>>
>> However, I am trying to work with the latest stable, 1.2.2, rather
>> than 1.3 exactly because it is more stable than 1.3.
>>
>>
>> I appreciate any help you can offer.
>>
>>
>> Thanks,
>>
>> Ryan Donnelly
|
|
|
| Re: Upgrade from RAP 1.2.1 to 1.2.2 because of Firefox 3.6 - possible WAR deployment procedure probl [message #539318 is a reply to message #539296] |
Thu, 10 June 2010 11:59 |
Ryan Donnelly
Messages: 35
Registered: July 2009 |
Member |
|
|
Ralf,
I have opened two bugs:
#316443 Firefox 3.6: NumberFormatException on ToolItem click
https://bugs.eclipse.org/bugs/show_bug.cgi?id=316443
#316446 WAR Deployment procedure for RAP 1.2.2
https://bugs.eclipse.org/bugs/show_bug.cgi?id=316446
Can you please elaborate on your comment "it can't be related to Tomcat
vs. Jetty"? There is nothing in the servletbridge, if it had been built
as a version out of sync with 1.2.2, that could cause the code below to
return an integer under Eclipse and a floating-point number under
WAR/Tomcat?
WidgetLCAUtil:
private static int readBoundsX( final String widgetId, final int
defValue ) {
String value = readPropertyValue( widgetId, PARAM_X );
return readBoundsValue( value, defValue );
}
private static String readPropertyValue( final String widgetId,
final String propertyName )
{
HttpServletRequest request = ContextProvider.getRequest();
StringBuffer key = new StringBuffer();
key.append( widgetId );
key.append( "." );
key.append( propertyName );
return request.getParameter( key.toString() );
}
Any chance that a mismatch of the servletbridge version with the
version of Qoxdoo, which I know has been changing in recent months,
could cause this behavior?
Thanks,
Ryan
Ralf Sternberg wrote:
> Hi Ryan,
>
> this sounds like a bug. JavaScript doesn't know integers, just numbers.
> It seems that there is some rare case that cause a bounds parameter to
> be transmitted as a floating point number and we don't handle this case.
>
> It can't be related to Tomcat vs. Jetty. Maybe you have some workbench
> layout stored in the settings cookie for the Tomcat server. Could you
> open a bug with the stack trace?
>
> Thanks, Ralf
>
>
> Ryan Donnelly wrote:
>> Sorry, below, I meant to say:
>>
>> "Can you shed some light on why I get an integer running under Eclipse
>> and a non-integer running the WAR?"
>>
>>
>> Ryan Donnelly wrote:
>>> Hi,
>>> I am upgrading from RAP 1.2.1 to 1.2.2 because of the following:
>>>
>>> #294981 Several widgets don't work in Firefox 3.6
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=294981
>>>
>>> and I am running into a problem that causes me to question my WAR
>>> deployment procedure:
>>>
>>>
>>> In my application, with RAP 1.2.1 as I have it now, in Firefox
>>> 3.6.3, for a ToolItem widget with SWT.DROP_DOWN, when I click on the
>>> upside-down triangle for the drop-down, nothing happens. When I
>>> upgrade my target platform to 1.2.2, and run in Eclipse, the problem
>>> is fixed - the widget works and the dropdown shows.
>>>
>>> However, when I build the application into a WAR and run it under
>>> Tomcat, when I click on the widget I get the error:
>>>
>>> java.lang.NumberFormatException: For input string: "320.79998779296875"
>>> java.lang.NumberFormatException.forInputString(Unknown Source)
>>> java.lang.Integer.parseInt(Unknown Source)
>>> java.lang.Integer.parseInt(Unknown Source)
>>>
>>> org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBoundsValue(Widg etLCAUtil.java:873)
>>>
>>>
>>> org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBoundsX(WidgetLC AUtil.java:853)
>>>
>>>
>>> org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBounds(WidgetLCA Util.java:327)
>>>
>>>
>>> org.eclipse.swt.internal.widgets.toolitemkit.DropDownToolIte mLCA.readData(DropDownToolItemLCA.java:60)
>>>
>>>
>>> org.eclipse.swt.internal.widgets.toolitemkit.ToolItemLCA.rea dData(ToolItemLCA.java:40)
>>>
>>>
>>> org.eclipse.swt.internal.widgets.displaykit.DisplayLCA$1.doV isit(DisplayLCA.java:320)
>>>
>>>
>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor$AllWidget TreeVisitor.visit(WidgetTreeVisitor.java:28)
>>>
>>>
>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:59)
>>>
>>>
>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.handleIte ms(WidgetTreeVisitor.java:91)
>>>
>>>
>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:48)
>>>
>>>
>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>>
>>>
>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>>
>>>
>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>>
>>>
>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>>
>>>
>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>>
>>>
>>> org.eclipse.swt.internal.widgets.displaykit.DisplayLCA.readD ata(DisplayLCA.java:327)
>>>
>>> org.eclipse.rwt.internal.lifecycle.ReadData.execute(ReadData .java:26)
>>>
>>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.continueLife Cycle(RWTLifeCycle.java:209)
>>>
>>>
>>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.sleep(RWTLif eCycle.java:312)
>>>
>>> org.eclipse.swt.widgets.Display.sleep(Display.java:790)
>>> com.lti.swtutils.DispatchLoop.readAndDispatch(DispatchLoop.j ava:37)
>>> com.quintron.vx.gui.AppImpl.run(AppImpl.java:1546)
>>> com.quintron.vx.rwt.WebApp.createUI(WebApp.java:178)
>>>
>>> org.eclipse.rwt.internal.lifecycle.EntryPointManager.createU I(EntryPointManager.java:92)
>>>
>>>
>>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.createUI(RWT LifeCycle.java:231)
>>>
>>>
>>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadCont roller.run(RWTLifeCycle.java:119)
>>>
>>> java.lang.Thread.run(Unknown Source)
>>>
>>>
>>>
>>>
>>> Stepping through the code, I can see that running under Eclipse we
>>> have an Integer here, causing no problem.
>>>
>>> org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBoundsValue(Widg etLCAUtil.java:873)
>>>
>>>
>>> whereas with the WAR/Tomcat we get the non-integer value.
>>>
>>>
>>>
>>> I can see that there has been work in this area since 1.2.2, such as:
>>>
>>> #306842 JS error in TableColumnLCA
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=306842
>>>
>>> #289336 [ToolBar] Implement new client-side ToolBar
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=289336
>>>
>>>
>>> Can you shed some light on why I get an Integer running under
>>> Eclipse and a Long running the WAR? Can I fix this by fixing my WAR
>>> deployment procedure or is this likely a bug that was fixed after
>>> 1.2.2 or possibly a new bug?
>>>
>>>
>>> If the problem is with my WAR deployment procedure, could someone
>>> on the RAP team please clear up for me what is the WAR deployment
>>> procedure for 1.2.2? It seems to me that the procedure in the Eclipse
>>> Help article "WAR Deployment" is out of date, even with the help file
>>> provided by the latest (1.3 RC3) tooling.
>>>
>>> Specifically, the servletbridge project
>>> org.eclipse.equinox.servletbridge.extensionbundle
>>>
>>> is not mentioned in the article - it is not present in the bundle
>>> included in the help article:
>>>
>>> http://127.0.0.1:49165/help/topic/org.eclipse.rap.help/help/ html/advanced/servletbridge-anon.psf
>>>
>>>
>>> nor is it in feature.xml from HEAD in org.eclipse.rap.demo.feature.
>>>
>>>
>>> However, sources such as the following lead me to believe that it
>>> is required.
>>>
>>>
>>> http://wiki.eclipse.org/RAP/FAQ#Exported_WAR_file_does_not_w ork
>>>
>>> #293020 War-deployment fails with equinox bridgeservlet from HEAD
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=293020
>>>
>>>
>>> If it is required, is there anything I need to do other than check
>>> out the project and include it in feature.xml before I run the
>>> webAppBuilder script?
>>>
>>> Is there anything else required that is not mentioned in the Help
>>> article?
>>>
>>> Since the WAR deployment procedure involves compiling the
>>> servletbridge, the question arises, what version of the
>>> servletbridge projects should I have in my workspace when running the
>>> webAppBuilder script? I have tried both the latest from HEAD (incl.
>>> the extensionbundle project) and the CVS source as of 27/01/2010 (the
>>> day after the 1.2.2 release).
>>>
>>>
>>>
>>> I understand that the WAR deployment procedure is likely in flux
>>> as the 1.3 release approaches, and that you are also working towards a
>>> more automated procedure
>>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=279743).
>>>
>>> However, I am trying to work with the latest stable, 1.2.2, rather
>>> than 1.3 exactly because it is more stable than 1.3.
>>>
>>>
>>> I appreciate any help you can offer.
>>>
>>>
>>> Thanks,
>>>
>>> Ryan Donnelly
|
|
|
Goto Forum:
Current Time: Sat Jul 27 11:04:57 GMT 2024
Powered by FUDForum. Page generated in 0.02507 seconds |
] 
Search
Help
Register
Login
Home
