ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

I hate to dwell on this, but what exactly was the official reason that Apple gave as to why ICEmobile apps could not be placed into app store (and thus provide full integration with camera, GPS, and other components rather than through ICEmobile-SX).

I ask this because I recently tried ICEmobile-SX. Let's just say it's not the best experience and seemed cumbersome to use. I have to wonder why Apple rejected it and forced you to use ICEmobile-SX - when Appcelerator, phoneGap, rhodes, Adobe AIR, etc. have access to native components directly? It just seems very frustrating from a developer's POV.

My setup:

ICEfaces 1.8.3

Seam 2.2.2 Final

Liferay 6.0.6

JBoss 5.0.1GA

I know this issue has supposedly been fixed in a previous JIRA:

http://jira.icesoft.org/browse/ICE-3291

And forum topic:

http://jforum.icesoft.org/JForum/posts/list/9100.page#37835

Unfortunately, it does not work for me at all. First, the popup doesn't even show up at all. I just shows up in its "natural" position of where it is in the xhtml file. Here's a snippet of the Facelets markup:

Code:

<ice:panelPopup id="helpHeaderPanelPopup"
 	xmlns="http://www.w3.org/1999/xhtml"
 	xmlns:s="http://jboss.com/products/seam/taglib"
 	xmlns:ui="http://java.sun.com/jsf/facelets"
 	xmlns:f="http://java.sun.com/jsf/core"
 	xmlns:h="http://java.sun.com/jsf/html"
 	xmlns:ice="http://www.icesoft.com/icefaces/component"
 	visible="false" modal="false" positionOnLoadOnly="true" draggable="true"
 	clientOnly="true" effect="#{itemsPage.popupEffect}">
 	<f:facet name="header">
 		<ice:panelGroup >
 			<ice:outputText
 				value="#{messages['itemsHelpHeader']}" />
 			<ice:commandButton type="submit"
 				value="#{messages['closeWindowIcon']}" immediate="true"
 				actionListener="#{itemsPage.setDisplayHelpPopup(false)}"title="#{messages['closeWindow']}" />
 		</ice:panelGroup>
 	</f:facet>
 
 	<f:facet name="body">
 		<ice:panelGroup>
 			<s:formattedText value="Test text" />
 		</ice:panelGroup>
 	</f:facet>
 </ice:panelPopup>

The modal attribute, whether set to true or false, doesn't make a difference. The attribute that seems to make a difference is the visible attribute. I've seen in the documentation and examples that it has to be set to visible="false" in order for the effects to work (the setDisplayHelpPopup(true) sets the itemsPage.popupEffect to use the Appear effect). Interestingly, if I set the visible to something like visible="#{itemsPage.displayHelpPopup} where the visible value is determined by the bean, the popup does appear, albeit the effects do not work. So there's something wrong with the effects and how it interacts with the visible attribute.

Any ideas?

ted.goddard wrote:

When this occurs, does it loop repeatedly, or just print to the log periodically for different users?

It loops repeatedly. This was on my localhost box for just one user. I have yet to test with multiple users.

I'm using the following configuration:

ICEfaces 1.8.3

Seam 2.2.2 Final

Liferay 6.0.6

JBoss 5.1.0

I occasionally see the following clogging my logs:

Code:

at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)
 	at com.icesoft.net.messaging.MessagePipeline$PublishTask.run(MessagePipeline.java:189)
 	at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
 	at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
 	at edu.emory.mathcs.backport.java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:102)
 	at edu.emory.mathcs.backport.java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:215)
 	at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
 	at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
 	at java.lang.Thread.run(Thread.java:662)
 Caused by: java.net.SocketException: Unexpected end of file from server
 	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:769)
 	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
 	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:766)
 	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195)
 	at com.icesoft.net.messaging.http.HttpAdapter.publish(HttpAdapter.java:310)
 	... 113 more
 15:05:15,655 ERROR [MessagePipeline] 
 com.icesoft.net.messaging.MessageServiceException: java.net.SocketException: Unexpected end of file from server
 	at com.icesoft.net.messaging.http.HttpAdapter.publish(HttpAdapter.java:354)
 	at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:151)
 	at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)

The "com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:158)" will just go on forever, creating huge log files. Obviously, I can adjust my logging levels to filter this out, but what the heck is going on here? I see this happen from time to time and it makes me a bit suspicious.

Aha, I think I've got a solution. I wasn't using the push server before - and with the logging pointing to the push server, I thought I'd give it a try. And it seems to work now. Still seems quite fragile though - especially if the push server were not to work, shouldn't the default push mechanism (which is used as a fallback if the push server was not there) still work?

I looked into this some more and I am seeing where this is hanging:

com.icesoft.faces.webapp.http.servlet.SessionDispatcher.java

Code:

synchronized (sessionBoundServers) {
                 if (!sessionBoundServers.containsKey(id)) {
                     PseudoServlet pservlet = this.newServer(session, monitor, new Authorization() {
                         public boolean isUserInRole(String role) {
                             return inRole(id, role);
                         }
                     });
                     //add to the session so that our WeakHashMap does not ignore the
                     //reference
                     session.setAttribute(id + ":sessionboundserver", new KeepAliveHolder(pservlet));
                     sessionBoundServers.put(id, new WeakReference(pservlet));
                 }
             }

The code is synchronizing on the sessionBoundServers object. Looks like in the subsequent entry, a different thread is calling the same code albeit the sessionBoundServers object is still synchronized, causing the code to hang. I can't really figure out the purpose of the sessionBoundServers object.

Another thing is that the code seems never to get to:

Code:

 session.setAttribute(id + ":sessionboundserver", new KeepAliveHolder(pservlet));

Meaning the this.newServer constructor call seems to do something that will cause it to never return and thus subsequently release the monitor? Eventually, I drilled down to com.icesoft.net.messaging.http.HttpAdapter.java and the public void publish(final Message message, final String targetName) method.

Code:

_reader = new InputStreamReader(_connection.getInputStream());

It seems to be hanging here. So it's somehow related to the push server... I would like to just switch to synchronous mode, but I'm doing file uploads in a special way that prevents me from switching to synchronous mode.

Could someone from ICEfaces explain this and perhaps suggest a solution? Thanks!

I'm having issues with my ICEfaces/Seam portlet. Here's my setup:

ICEfaces 1.8.2

JBoss Seam 2.2.2 GA

JBoss 5.0.1 GA

Liferay 6.0.6 GA

I only encounter this problem when I place the portlet in the initially loaded home page. Previously, my home page only had the standard Liferay portlets. But now, I want to add an ICEfaces/Seam portlet to the home page.

Here's a scenario that replicates my issue:

I start up my app server.

Upon full startup, I login as a Liferay administrator.

I then try to add my ICEfaces/Seam portlet (Add.. More).

However, when I do so, Liferay just gets "stuck" with that animated circle. I don't see any exceptions on my Firebug console or on my app server log file. I only see the following in my log file:

Code:

2012-04-07 12:52:33,419 DEBUG [com.icesoft.faces.webapp.http.servlet.MainServlet] (http-0.0.0.0-8443-1) Servicing Request-URI: [/myapp/mypage.seam]
 2012-04-07 12:52:33,433 INFO  [com.icesoft.faces.webapp.http.servlet.MainServlet] (http-0.0.0.0-8443-1) Blocking Request Handler: "auto-detect"
 2012-04-07 12:52:33,451 DEBUG [com.icesoft.faces.webapp.http.servlet.EnvironmentAdaptingServlet] (http-0.0.0.0-8443-1) GlassFish ARP available: false
 2012-04-07 12:52:33,452 DEBUG [com.icesoft.faces.webapp.http.servlet.EnvironmentAdaptingServlet] (http-0.0.0.0-8443-1) Jetty ARP available: false
 2012-04-07 12:52:33,452 INFO  [com.icesoft.faces.webapp.http.servlet.EnvironmentAdaptingServlet] (http-0.0.0.0-8443-1) Adapting to Thread Blocking environment
 2012-04-07 12:52:33,459 DEBUG [com.icesoft.net.messaging.MessageServiceClient] (http-0.0.0.0-8443-1) Message Service Client - Thread Pool: 15
 2012-04-07 12:52:33,489 DEBUG [com.icesoft.util.ThreadFactory] (http-0.0.0.0-8443-1) New thread: Core Thread [1]
 2012-04-07 12:52:33,502 DEBUG [com.icesoft.net.messaging.DefaultMessageService] (http-0.0.0.0-8443-1) Setting up now...
 2012-04-07 12:52:33,503 DEBUG [com.icesoft.net.messaging.DefaultMessageService] (http-0.0.0.0-8443-1) Setting up now... (interval: [0], maxRetries: [0])
 2012-04-07 12:52:33,504 DEBUG [com.icesoft.net.messaging.DefaultMessageService] (http-0.0.0.0-8443-1) Current State: SET UP
 2012-04-07 12:52:33,505 DEBUG [com.icesoft.net.messaging.DefaultMessageService] (http-0.0.0.0-8443-1) Executing Set Up task...
 2012-04-07 12:52:33,505 DEBUG [com.icesoft.faces.webapp.http.servlet.CoreMessageService] (http-0.0.0.0-8443-1) Setting up Message Service Client...
 2012-04-07 12:52:33,508 DEBUG [com.icesoft.net.messaging.http.HttpAdapter] (http-0.0.0.0-8443-1) Request-URI: [http://127.0.1.1:8080/push-server/block/message]
 2012-04-07 12:52:33,510 DEBUG [com.icesoft.net.messaging.http.HttpAdapter] (http-0.0.0.0-8443-1) [Core MSC] Outgoing message:
 
 source_servletContextPath: /myapp
 message_type: Presence
 destination_servletContextPath: push-server
 source_nodeAddress: 127.0.1.1
 
 Hello
 
 2012-04-07 12:52:33,551 INFO  [STDOUT] (http-0.0.0.0-8080-3) 12:52:33,550 INFO  [PortalImpl:3829] Current URL /push-server/block/message generates exception: null
 2012-04-07 12:52:33,552 INFO  [STDOUT] (http-0.0.0.0-8080-3) 12:52:33,551 INFO  [PortalImpl:3841] 
 2012-04-07 12:52:33,793 DEBUG [com.icesoft.faces.util.event.servlet.ContextEventRepeater] (http-0.0.0.0-8080-3) Session Created event: E080D1E7AA45EE3BB6296D978E8725BB
 2012-04-07 12:52:33,793 DEBUG [com.icesoft.faces.webapp.http.servlet.MainServlet] (http-0.0.0.0-8080-3) Servicing Request-URI: [/myapp/mypage.seam]

However, there's an interesting scenario that indicates this may be a startup issue. I would do the following.

I start up my app server.

Upon full startup, I login as a Liferay administrator.

I browse to another page (not the home page) that already has an ICEfaces/Seam portlet

I then try to add my ICEfaces/Seam portlet (Add.. More).

Strangely, this succeeds! The portlet is added to the home page and I can see the Hello message (see below for the portlet details - but it's an extremely simple portlet). However, if I restart app server, the home page doesn't even load on startup. Again, this indicates some strange startup issue - something is blocking or waiting for something to be loaded before the ICEfaces/Seam portlet can load.

Does anyone have any ideas why this is so? This is crucial for me because I need to put the portlet on the home page. Thanks!

Portlet xhtml:

<!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:s="http://jboss.com/products/seam/taglib"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ice="http://www.icesoft.com/icefaces/component">

<ice:portlet id="myPortlet">
<ice:outputText value="Hello" />
</ice:portlet>
</ui:composition>

Hi Ted, thanks for the info about the Safari wrapper. I didn't realize that was something that was available. However, isn't there still a benefit of getting an app onto the app store - it's a nice distribution mechanism, something that's easily searchable by end users, etc.? - unless there's some feature to have my Safari wrapper app available on the App Store?

Also, if I use the Safari wrapper, would that also mean I wouldn't be able to run my app in the background? Sorry with these ignorant iPhone questions... I'm just not very familiar with it...

Could someone answer the last question I had - i.e. can an ICEmobile app still be distributed via the Apple App Store? If not, then how would you propose that we get an app into the Apple App Store while still using ICEmobile? Thanks!

Ted, don't mean to impose too much, but that may be what I would be looking for - is there an example of this in the source code or in the demo?

It's more of a qualitative feel... I can't pin any quantitative numbers on it, but when I tried the ICEmobile demo app, it just felt... slow, especially going from screen to screen.

Also, I'm starting to learn about HTML5, ICEmobile, phoneGap, etc... So pardon my ignorance here. But does this mean I could build an ICEmobile app that contains a hybrid of JSF code and possibly some HTML5/JS code (the latter used for pages where I am really concerned about performance or rendering speed for certain pages)? Or would that not be advised? Do you have some examples for the JS/HTML5 integration? Thanks!

Thanks for the response, Ted. I do see one problem though. What if we do want to put our app in the Apple App Store? Does the SX uploader essentially mean that we cannot wrap an ICEmobile app as an iPhone app? I would think this would be a major concern because the App Store is a major distribution point... Not having an app in the Apple App Store would be a major loss.

Thanks for the news Ted. For those of us (like me) who are not totally familiar with the Apple development ecosphere and are not entirely familiar with mobile phone dev, what does this mean? Does this mean we cannot package an ICEmobile app in the iPhone store? If there is no script access to the native APIs, does this mean any true limitations from a developers' and users' point of view?

Also, how would this differ from a cross dev platform like rhomobile, phoneGap, and others? I understand a few of the differences, but would still like an elaboration of why ICEmobile would be better than rhomobile, phoneGap, appcelerator, and others. I guess I'm expanding the scope of my question right now. Is there a value statement as to why one would want to use ICEmobile versus these other platforms?

I tried out ICEmobile on my Android phone. It seems to function as expected but I was disappointed with its performance. This is probably due to its limitations in its architecture (server side logic) - with this being a negative (along with all the other positives with having all the business logic on the server side).

What would you recommend a developer to do to increase the performance of an ICEmobile app, given these limitations? Are there any plans on the way to perhaps do some processing on the client side wherever possible? Are there any tweaks to the architecture planned?

For Chrome (Webkit - which I assume Safari) browsers, you will also need to add the following CSS style:

-webkit-text-size-adjust: none;

You just need to add it to the style attribute of an ascendant element. I choose to do something like the following:

<ice:panelTab id="itemStatsByVolumePanelTab" styleClass="panelTabClass">

.panelTabClassOn,.panelTabClassOff,.panelTabClassOver {
-webkit-text-size-adjust: none;
}

But I believe you can add it at a lower level.