ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

No worries. Thanks for looking after this. I look forward to using the anon repository soon.

Thanks again,
Ed

Hi all. Previously, I've been getting the source releases of ICEfaces so I can build locally (primarily to address any issues we may have locally). So, I had been downloading the ZIP files containing the source and moving on.

I noticed recently that there is a Subversion repository which makes the source available. So I thought I'd use that instead of the zip file. So, I exported from http://anonsvn.icefaces.org/repo/icefaces/tags/icefaces-1.8.2/, and I got all the lovely source code.

This being the first time using the anonsvn repo, I wanted to make sure I was starting at the same point. So I also downloaded ICEfaces-1.8.2-src.zip as well so I could compare the contents. I wanted to confirm the assumption that the contents of both actions (exporting from the SVN tag and unzipping the source bundle) gave me the same files. I used BeyondCompare to check the contents of the resulting directories.

To my surprise, there are a few differences. 6 to be exact. 6 out of 2535 files, but 6 nonetheless. The files that didn't match were

bridge/lib/extras/extras.js
component/src/com/icesoft/faces/component/dataexporter/DataExporter.java
component/src/com/icesoft/faces/component/ext/renderkit/TableRenderer.java
component-metadata/src/main/resources/conf/ice_cust_properties/cust-dataExporter-props.xml
docs/ReleaseNotes.xml
samples/component-showcase/common-web/WEB-INF/includes/examples/custom/dataTable-dataExporter.jspx

So, which is the real release? I guess I don't know the process for how the source is made available, so I don't know if the Source bundle should be considered the real release, or the SVN repository.

Thanks for any help,
Ed

Thanks for the feedback. I'll look at getting the later releases of JSF into my application. I thought I had tried to include the jars into my WAR file unsuccessfully in the past, but it looks like it warrants a second try. :)

Thanks again,
Ed

I didn't think so, but I thought I'd ask. I noticed as part of the release notes for 1.8.2 that a new version of JSF 1.2 has been delivered as part of ICEfaces...

The Sun JSF 1.2 runtime (Mojarra) libraries included in the "../icefaces/lib" directory have been updated to JSF1.2_13_b01.

Does this mean that applications should ensure that the app server running their application uses this version of JSF? I didn't think it did, but I thought I'd ask the question now. :)

For example, we're planning to release our application using Glassfish 2.1, which uses JSF 1.2_04 as the version it's delivered with. Should we be looking at using the version that's delivered with ICEfaces instead?

I haven't been looking at the changes between the 04 and 13 releases of JSF, so I guess I'm unaware of any changes to JSF. I can look at the changes and determine for myself. I guess I'd be interested if there is any compelling reason to do this from an ICEfaces point-of-view.

Thanks for any info,
Ed

We ended up using #1, but slightly different. Instead of using RSH, we're using the Yahoo! Browser History UI component. We've got Javascript that manipulates the URL as it appears within the browser.

Then we have some hidden fields that handle the navigation. If the address in the URL changes, we can use it to navigate to the right context in our application. This handles the Back and Next buttons in the same session. We have some managed beans that handle our breadcrumbing, so it fits nicely with that.

We're also adding in some extra code at the server to handle deep navigation to better support bookmarking.

So, maybe more a 4th option instead of an offshoot of #1. This is all a hand-rolled approach though.

Thanks,
Ed

Ah, my bad. :) We haven't played around with that, so I'll be quiet now.

Sorry for my confusion

We've been able to change the displayed image through CSS quite easily. The states of the outputConnectionStatus component are defined by a CSS style. This is why the gifs change based on the ICEfaces style that is applied to the components. So, in our CSS stylesheet, we just override them

Code:

.iceOutConStatInactv {
     /* We actually hide the inactive component, which is slightly different from the standard behaviour*/
     visibility: hidden !important;
     background-image: url(../images/connect_idle.gif);
 }
 
 .iceOutConStatActv {
     background-image: url(../images/connect_active.gif);
 }
 
 .iceOutConStatCaution {
     background-image: url(../images/connect_caution.gif);
 }
 
 .iceOutConStatDisconnect {
     background-image: url(../images/connect_disconnected.gif);
 }

We have these gif files in our deployed WAR file (rather than using the default gifs that are in the icefaces jar.

Hope this helps

When we were doing anything that was initiated by a thread other than the HTTP request processor, we use some utility functions at the start and end of the calls to ensure the thread-local variables in the JSF/ICEfaces libraries were set up...

Code:

    /**
      * Method that takes the FacesContext objects associated with the <code>PersistentFacesState</code>
      * object and makes them available to the active thread.
      *
      * @param state the ICEfaces object containing the context to be used
      */
     public static void assignStateToCurrent(PersistentFacesState state) {
         FacesContext facesContext = state.getFacesContext();
         if (facesContext instanceof BridgeFacesContext) {
             ((BridgeFacesContext) facesContext).setCurrentInstance();
         }
         state.setCurrentInstance();
     }
 
     /**
      * Method that releases the <code>PersistentFacesState</code> from the current Thread.
      * This helps ensure references aren't held longer than they should be which can
      * affect garbage collection.
      *
      * @param state the ICEfaces object containing the state to be released
      */
     public static void releaseState(PersistentFacesState state) {
         state.release();
     }

So, if we had some Java code that was started by a server thread that wasn't the http request processor, we'd have something like

PersistentFacesState state = // assigned to the thread/runner
IceFacesUtil.assignStateToCurrent(state);
try {
//Do something that uses the FacesContext
} finally {
IceFacesUtil.releaseState(state);
}

They way your code looks, this is not necessary in ICEfaces 1.8 (they've done something equivalent in the PersistentFacesState.executeAndRender method), but it might still be required in version 1.7.2

We use EL expressions to find managed beans in our code, and found that we needed to ensure the thread-local variables were set up before any of our code worked in a thread that was spawned off by the server.

Hope this helps,
Ed

I don't think I would use PersistentFacesState.getInstance(), as the correct PersistentFaceState object may not be returned (if one at all). Perhaps you're getting NullPointerException which is why the rendering isn't happening.

When you spawn off the background thread from the request that has a PersistentFacesState, give it the correct PersistentFacesState it should use in order to render.

If the background thread cannot be given a specific instance of PersistentFacesState, then it will need to go through the active views for the Session and find the first appropriate View whose PersistentFacesState can be used for rendering.

Hope this helps,
Ed

I don't think this is easily done. The server application contains a hierarchy of UIComponents that then get rendered (typically) to an HTML page. Even the HTML page won't have any positional information for the elements defined within it. This is all controlled by the browser and how it renders the elements.

You can learn when things happen within components, etc. But the positional details about the UIComponents (as they are rendered in the client) aren't available by default in the UIComponent tree. The AJAX bridge isn't used to provide that information back to the server (it would be a significant amount of information to return to the server).

I guess back to the reason, which is to display a popup related to the position of a graphicImage component. Perhaps using a panelPopup isn't the way to go. I know the ice:selectInputDate does something quite similar (click on a button, it displays a calendar that behaves a lot like a popup). Itmight be useful to look at the generated HTML to see how it is structured, and perhaps you can define some renderers to achieve this yourself?

Hope this helps,
Ed

Hi. Sorry for the delay.

When I change the check to include the viewRoot as well, the thread does complete without an exception (ie, it works the way I expect it... the navigate takes place).

Thanks for the feedback. I will try out your suggestion regarding the releaseState method.

Thanks for the help,
Ed

I didn't provide enough information. I apologize.

We have a method that gets called at the end of the process (which can be long running).

Code:

         public void cacheUpdateCompleted() {
             LOG.entering(this.getClass().getName(), "cacheUpdateCompleted");
 
             IceFacesUtil.assignStateToCurrent(state);
             try {
                 User user = User.getBean();
                 if (user != null) {
                     user.getCacheManager().removeCacheUpdateListener(this);
                     try {
                         // load user permissions
                         user.loadPermissions();
                     } catch (ManagerException ex) {
                         Messages.addError(ex, "ManagerException while loading user permissions",
                                 "logonFailedMessage", ex.getMessage());
                     }
                 }
             } finally {
                 IceFacesUtil.releaseState(state);
             }
 
             state.navigateTo(Navigator.HOME);
             doRender();
             LOG.exiting(this.getClass().getName(), "cacheUpdateCompleted");
         }

We use a utility class so assign the state to the current thread in order to gain access to the Managed Beans (in the code example, User is a session-scoped managed bean. So, the User.getBean() method looks like

Code:

    public static User<?> getBean() {
         return ManagedBeans.getBean(BEAN_BINDING, User.class);
     }

where the ManagedBeans.getBean is simply executing an expression to retrieve the Managed bean.]

The utility functions (which was modified to support 1.8.0) look like

Code:

    /**
      * Method that takes the FacesContext objects associated with the <code>PersistentFacesState</code>
      * object and makes them available to the active thread.
      *
      * @param state the ICEfaces object containing the context to be used
      */
     public static void assignStateToCurrent(PersistentFacesState state) {
         FacesContext facesContext = state.getFacesContext();
         if (facesContext instanceof BridgeFacesContext) {
             ((BridgeFacesContext) facesContext).setCurrentInstance();
         }
         state.setCurrentInstance();
     }
 
     /**
      * Method that releases the <code>PersistentFacesState</code> from the current Thread.
      * This helps ensure references aren't held longer than they should be which can
      * affect garbage collection.
      *
      * @param state the ICEfaces object containing the state to be released
      */
     public static void releaseState(PersistentFacesState state) {
         state.release();
     }

If we don't perform this, we can't update the managed beans that are used elsewhere in the application.

If this isn't the best way of doing things, I'd be more than happy to consider alternatives.

Thanks,
Ed

I haven't tried to dynamically derive Javascript embedded in a script tag. I have included existing libraries, and have had to use the JavascriptContext class to ensure that DOM updates retain the Javascript links.

I think what you're describing is that the UIViewRoot doesn't know about derived javascript (as it's not contained within a UIComponent). So when the application determines that DOM has changed and is sending changes back to the browser, it's not retaining the XHTML that was originally there? I think?

I can't see where in the JavascriptContext class you can add dynamically-generated javascript methods. If you can define this as a file, you can add it to the context.

Otherwise, can this be defined within the UIComponent JS events themselves?

Hope this helps,
Ed

Thanks for that. I agree that my workaround seemed to work for this particular problem, but it was just a workaround for now. :) I'm glad there's a sufficient fix in the PersistentFacesState.

My thread had a reference to the PersistentFacesState, and while the state's internal View reference was disposing the BridgeFacesContext, it was never clearing the reference? Perhaps that's why I always had a reference to the FacesContext?

Thanks again,
Ed

I have been able to work around this. Before I start the new thread, I store the view id of the ViewRoot for the active facesContext. Then, when the thread is finished and it's about to attempt the navigation, I call the following method:

Code:

    public static void checkViewRoot(PersistentFacesState state, String viewId) {
         FacesContext ctx = state.getFacesContext();
         if (ctx.getViewRoot() == null) {
             UIViewRoot viewRoot = ctx.getApplication().getViewHandler().createView(ctx, viewId);
             if (viewRoot != null) {
                 ctx.setViewRoot(viewRoot);
             }
         }
     }

The ensure that a viewRoot with the correct viewId is available for the navigateTo method. I just don't know if this is the best way of achieving this.

Thanks for any feedback,
Ed