voyent
Messages posted by: zzzz8  XML
Profile for zzzz8 -> Messages posted by zzzz8 [270] Go to Page: 1, 2, 3  ...  16, 17, 18 Next 
Author Message
I can actually reproduce this consistently. My site is running on ICEfaces 1.8.x, Liferay 6.0.6GA, Seam 2.2GA, and JBoss 5.0.1GA. I recently updated my code to use the latest ICEfaces 1.8.x trunk code which includes changes for Google Maps v3.

You can replicate this by going to http://pricebam.com. You can only see this if you do not currently have a cookie at the site (e.g. first login or you can delete the pricebam.com cookie if you've already gone to the site). Then go to Items in the navigation bar. Once the Items page opens, then click on the last page button in the paginator at the bottom of the page. Depending on the browser you use, you will then see the following:

Internet Explorer 10: No page is ever opened
Firefox: Just spins trying to load the page
Chrome: I get the following popup message:
Google has disabled use of the Maps API for this application. The provided key is not a valid Google API Key, or it is not authorized for the Google Maps Javascript API v3 on this site. If you are the owner of this application, you can learn about obtaining a valid key here: https://developers.google.com/maps/documentation/javascript/tutorial#api_key. 

Safari: Same as Chrome

What's going on here? I know the API key is OK because if you refresh the site then go to the store page or any other page (e.g. store chains) that contains a map, the map is retrieved properly. I also see on the Google API console that the key is working correctly and I see requests using the key. I know the referer is set correctly on Google API console as well. Does anyone in ICESoft have an idea what may be going on?
OK, I hadn't updated my code with the latest stuff form the 1.8.x trunk for a few months. Once I did that, I didn't see any unusual errors and everything was right in the world again - IE 10 was working fine.

I took a quick look at the SVN history for the 1.8.x trunk and couldn't definitively identify what caused the original IE 10 issue. I noticed a few recent checkins dealt with some IE logging functionality. I noticed yesterday that IE was complaining about some issues loading some debugging functions for IE although they were only warnings. However, I now have to wonder if the warnings were somehow more detrimental than I thought.

Anyway, I consider this issue solved for now.
Before I start, I need to note that I cannot move my code to ICEfaces 3, so please do not suggest that as a solution.

I just noticed now that Internet Explorer 10 has many, many issues with ICEfaces 1.8.3 which I did not see with Internet Explorer 9. I cannot seem to find a definitive pattern, but it seems like there's an issue with HTML input and select elements especially and how they react (specifically do not react) to click events.

I'm hoping an ICEfaces employee can help me in this matter. I don't expect ICEfaces to provide the entire solution since 1.8.3 is now deprecated, but any hints would be highly appreciated!
Thanks Ken. I had actually started down the road of modifying gmap.js directly by comparing it with gmap.js in ICEfaces 3.2 when I actually discovered that the compatibility code from extras.js (and I only read your latest reply after I did that).

Anyway, I've attached the changes I made in the two files to allow ICEfaces 1.8 to work with Google Maps v3. The first change in GMap.java (from revision 21005) allows ICEfaces 1.8 to connect to Google Maps v3 using http or https using the proper Google Maps v3 URL. However, one has to determine whether the current HTTP request is secure or not secure. It's a little different from the GMap.java code in ICEfaces 3.2 because the ExternalContext class in Java EE 5 does not have the isSecure method defined. Accordingly, I have to retrieve the request (ServletRequest for "normal" requests and PortletRequest for portlet requests), then call the isSecure method to determine the security of the current HTTP request.

Second, I just took lines 2724 through 3108, inclusive, of compat/core/src/main/javascript/extras/extras.js (from ICEfaces 3.2 - revision 32958) and replaced the entire content of bridge/lib/extras/gmap.js (ICEfaces 1.8). It worked fine out of the box...

Hope this helps.

Anyway, I have attached the files to this post.
Unfortunately, I cannot move my code from 1.8.x to 3.2 for various reasons. ICEfaces 3.2 uses the most recent Google Maps API (v3). 1.8.x uses Google Maps API (v2). Google will discontinue support of the v2 API on May 19, 2013:

https://developers.google.com/maps/documentation/javascript/v2/

I understand that ICEfaces will not update 1.8.x's gMap component to use Google Maps v3 API. That is understandable.

However, my current situation dictates that I continue to use 1.8.x. I will thus spend some time modifying the 1.8.x ice:gMap component to use Google Maps API v3 instead of v2. I will also contribute the code back once I have this done - if I ever get this to work.

I looked over the code and it looks like I only need to update the code in the gmap.js Javascript file. I would just change the v2 function calls to use the v3 functions instead - and I'm sure there's a little extra stuff I need to do. I plan to use the gmap.js code from ICEfaces 3.2 as a guide for my changes.

I would just appreciate any additional advice. Does anyone on the ICEfaces team or anyone on the forum have any hints or tips to do this? Thanks!
I just saw the news release and a few articles (and Oracle's website) on Oracle ADF Mobile. It's quite an interesting solution. Unfortunately, its main drawbacks are that it seems to only work with Oracle WebLogic and Fusion, making it unavailable for people like me who don't have the money to purchase an Oracle WebLogic license.

However, Oracle states that apps developed using ADF Mobile should be able to pass muster in the Apple app store - which is one of the big negatives with ICEmobile.

Could anyone on the ICEmobile team comment on the differences and similarities between ICEmobile and Oracle ADF Mobile?
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!
     
    Profile for zzzz8 -> Messages posted by zzzz8 [270] Go to Page: 1, 2, 3  ...  16, 17, 18 Next 
    Go to:   
    Powered by JForum 2.1.7ice © JForum Team