ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Thanks for the helpful reply to my posting! I did manage to get through the problem that I was having which was the exception

com.liferay.portal.security.auth.PrincipalException: PermissionChecker not initialized

was being thrown when I added the inputFile component in my Liferay portlet.

The problem (restated):

I wanted to use the ICEfaces inputFile component (in a portlet) to upload a file into Liferay's Document Library.

Prior to adding the inputFile component, my portlet was successfully displaying the contents of the document library. When I added the inputFile component and a stubbed actionListenser, I immediately started seeing the PrincipalException mentioned earlier.

There were a few things that made this problem difficult to understand:

The PrincipalException wasn't being thrown in the actionListener, but instead it was being thrown when getting the contents of the document library. This would normally have implied a Liferay problem except that this code works fine when inputFile isn't used.

The inputFile component seemed to work fine in the component showcase (not a portlet).

The inputFile component didn't work 100% correctly in the ICEfaces portlet sample code.

This lead me to believe that the problem was with ICEfaces and in particular with using inputFile in a portlet context.

The Solution:

Sadly, I was completely wrong. The problem had nothing to do with ICEfaces but instead was caused by my missuse of the Liferay API.

I was using

DLFileEntryServiceUtil.getFileEntries(folderId)

to get the entries in a Liferay Document Library folder for display. As mentioned before, this call worked fine prior to adding the inputFile component. However, I now know that I should have been using the Local version of this utility

DLFileEntryLocalServiceUtil.getFileEntries(folderId)

This call works with (or without) inputFile.

Similarly, I'm now using

DLFolderLocalServiceUtil instead of DLFolderServiceUtil

I found a hint to this solution in an old posting in one of the Liferay forums that I failed to cross-post to.

I want to use the ICEfaces inputFile component in a portlet as a way to add files to Liferay's Document library. I'm using ICEface 1.8.2, Liferay 5.2.3 running on GlassFish 2.1.1.

(1) Here's what I'm seeing in my development environment.

In my code, I have the inputFile component calling an action listener stub.

Code:

 <ice:inputFile id="inputFileName"
                      width="600"
                      actionListener="#{educationSummary.addAttachmentActionListener}"/>

The addAttachmentActionListener simply logs a message that it was called.

When I upload a file (click the upload button), the file gets uploaded to the server and I get an exception logged. It's not apparent from the log snippet below, but the exception is happening when the page is being refreshed. I'm not seeing this exception when other action listeners are getting invoked, only when I invoke the inputFile actionListener.

Code:

 [#|2010-07-08T10:13:26.396-0500|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=30;_ThreadName=pool-2-thread-1;|2010-07-08 10:13:26,395 [pool-2-thread-1] DEBUG com.applygenie.portlet.portfolio.summary.EducationSummaryBean - addAttachmentActionListener
 |#]
 
 [#|2010-07-08T10:13:26.425-0500|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=30;_ThreadName=pool-2-thread-1;|2010-07-08 10:13:26,424 [pool-2-thread-1] DEBUG com.applygenie.portlet.portfolio.PortfolioSessionBean - findDocumentLibraryEntries: dlPath=[User Documents, 12901, Portfolio Attachments, About]
 |#]
 
 [#|2010-07-08T10:13:26.434-0500|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=30;_ThreadName=pool-2-thread-1;|2010-07-08 10:13:26,431 [pool-2-thread-1] ERROR com.applygenie.portlet.lib.LiferayDocumentLibraryService - findFolder: Error locating folder: groupId=10926m dlPath=[User Documents, 12901, Portfolio Attachments, About]
 com.liferay.portal.security.auth.PrincipalException: PermissionChecker not initialized
 	at com.liferay.portal.service.base.PrincipalBean.getPermissionChecker(PrincipalBean.java:77)
 	at com.liferay.portlet.documentlibrary.service.impl.DLFolderServiceImpl.getFolder(DLFolderServiceImpl.java:146)
 	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:597)
 	at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
 	at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
 	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
 	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
 	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
 	at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
 	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
 	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 	at $Proxy157.getFolder(Unknown Source)
 	at com.liferay.portlet.documentlibrary.service.DLFolderServiceUtil.getFolder(DLFolderServiceUtil.java:94)
 	at com.liferay.portlet.documentlibrary.service.DLFolderServiceUtil$getFolder.call(Unknown Source)
 	at com.applygenie.portlet.lib.LiferayDocumentLibraryService$_findFolder_closure1.doCall(LiferayDocumentLibraryService.groovy:81)
 	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:597)
 	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
 	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
 	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
 	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:880)
 	at groovy.lang.Closure.call(Closure.java:279)
 	at groovy.lang.Closure.call(Closure.java:292)
 	at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:1163)
 	at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:1139)
 	at org.codehaus.groovy.runtime.dgm$96.invoke(Unknown Source)
 	at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:270)
 	at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
 	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
 	at com.applygenie.portlet.lib.LiferayDocumentLibraryService.findFolder(LiferayDocumentLibraryService.groovy:80)
 	at com.applygenie.portlet.lib.LiferayDocumentLibraryService.this$2$findFolder(LiferayDocumentLibraryService.groovy)
 	at com.applygenie.portlet.lib.LiferayDocumentLibraryService$this$2$findFolder.callCurrent(Unknown Source)
 	at com.applygenie.portlet.lib.LiferayDocumentLibraryService.findEntries(LiferayDocumentLibraryService.groovy:38)
 	at com.applygenie.portlet.lib.LiferayDocumentLibraryService$findEntries.call(Unknown Source)
 	at com.applygenie.portlet.portfolio.PortfolioSessionBean.findDocumentLibraryEntries(PortfolioSessionBean.groovy:198)
 	at com.applygenie.portlet.portfolio.PortfolioSessionBean$findDocumentLibraryEntries.call(Unknown Source)
 	at com.applygenie.portlet.portfolio.summary.EducationSummaryBean.getAttachments(EducationSummaryBean.groovy:143)
 	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:597)
 	at javax.el.BeanELResolver.getValue(BeanELResolver.java:293)
 	at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:175)
 	at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:72)
 	at com.sun.el.parser.AstValue.getValue(AstValue.java:138)
 	at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:206)
 	at com.sun.faces.application.ValueBindingValueExpressionAdapter.getValue(ValueBindingValueExpressionAdapter.java:113)
 	at javax.faces.component.ValueExpressionValueBindingAdapter.getValue(ValueExpressionValueBindingAdapter.java:84)
 	at javax.faces.component.UIData.getValue(UIData.java:614)
 	at com.icesoft.faces.component.panelseries.UISeries.getValue(UISeries.java:572)
 	at com.icesoft.faces.component.panelseries.UISeries.getDataModel(UISeries.java:357)
 	at com.icesoft.faces.component.panelseries.UISeries.processCurrentRowData(UISeries.java:144)
 	at com.icesoft.faces.component.panelseries.UISeries.setRowIndex(UISeries.java:136)
 	at com.icesoft.faces.component.ext.renderkit.TableRenderer.renderFacet(TableRenderer.java:146)
 	at com.icesoft.faces.renderkit.dom_html_basic.TableRenderer.encodeBegin(TableRenderer.java:122)
 	at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:813)
 	at javax.faces.component.UIData.encodeBegin(UIData.java:967)
 	at com.icesoft.faces.component.panelseries.UISeries.encodeBegin(UISeries.java:298)
 	at com.icesoft.faces.component.ext.HtmlDataTable.encodeBegin(HtmlDataTable.java:110)
 	at com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParentAndChildren(DomBasicRenderer.java:356)
 	at com.icesoft.faces.renderkit.dom_html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:96)
 	at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:837)
 	at com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParentAndChildren(DomBasicRenderer.java:358)
 	at com.icesoft.faces.renderkit.dom_html_basic.GridRenderer.encodeChildren(GridRenderer.java:208)
 	at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:837)
 	at com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParentAndChildren(DomBasicRenderer.java:358)
 	at com.icesoft.faces.renderkit.dom_html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:96)
 	at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:837)
 	at com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParentAndChildren(DomBasicRenderer.java:358)
 	at com.icesoft.faces.renderkit.dom_html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:96)
 	at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:837)
 	at com.icesoft.faces.component.util.CustomComponentUtils.renderChild(CustomComponentUtils.java:339)
 	at com.icesoft.faces.component.paneltabset.PanelTabSetRenderer.writeTabCell(PanelTabSetRenderer.java:977)
 	at com.icesoft.faces.component.paneltabset.PanelTabSetRenderer.encodeEnd(PanelTabSetRenderer.java:423)
 	at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:861)
 	at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:503)
 	at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:497)
 	at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:497)
 	at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:497)
 	at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:497)
 	at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:497)
 	at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:467)
 	at com.icesoft.faces.application.D2DViewH|#]
 
 [#|2010-07-08T10:13:26.434-0500|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=30;_ThreadName=pool-2-thread-1;|andler.renderView(D2DViewHandler.java:159)
 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
 	at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.render(PersistentFacesState.java:176)
 	at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.executeAndRender(PersistentFacesState.java:312)
 	at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.setupAndExecuteAndRender(PersistentFacesState.java:323)
 	at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState$RenderRunner.run(PersistentFacesState.java:447)
 	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:637)
 |#]

(2) Searching the ICEfaces and Liferay forums lead me to suspect that the inputFile component wasn't supported in portlets. To test this out, I build and installed the ICEfaces portlet component showcase.

Code:

 cd icefaces/samples/component-showcase/portlets
 ant clean
 ant liferay.glassfishv2

and the installed dist/component-showcase.war into Liferay. I then added the ICEfaces:FileUpload portlet to a Liferay page and encountered the following problems with the portlet;

unchecking the "Auto upload" checkbox didn't make the upload button appear

regardless of the state of "Auto upload", after browsing to a file to upload the file path would momentarily appear in the browse text field. The file does get uploaded to the glassfish/domains/domain1/applications/j2ee-modules/component-showcase/upload folder

the uploaded file never shows up in the Uploaded Files table

nothing is logged

This behavior appears to be similar to what I'm seeing in my code, i.e. the file is getting uploaded but something goes wrong afterwards.

To wrap this up, I'm looking for a definitive answer as to whether the inputFile component will or will not work in a portlet installed in Liferay. If it will work, then I'm also looking for some help with my particular problem or perhaps with getting the File Upload showcase portlet working properly.

Thanks.

I'm developing portlets for ICEfaces/Liferay and they're all Groovy.

I'm not taking advantage of any dynamic compilation. The portlets are compiled and then packaged into WAR files for deployment to Liferay. However, I still get the groovy syntax and simple backing beans are a snap.

I don't have any examples to share, they're just normal portlets written in Groovy.

-- JB

I don't see any problems with your example. I'm using a commandButton instead of the commandLink that you're using, but I don't see why that would be a problem. However, there was one thing that caused me some confusion and may be your problem also.

In your commandLink component, you're specifying the ID of the panelConfirmation. In your example;

Code:

 <ice:commandLink action="#{Management.remove}"
                                               immediate="true"
                                               panelConfirmation="saveConfirmPanel">

you're specifying an panelConfirmation with id="saveConfirmPanel".

With this code, ICEfaces is going to look for a panelConfirmation component with this id, at the same location in the DOM hierarchy. It's likely that your panelConfirmation component is not at the same location in the DOM hierarchy as the commandLink component and so it isn't found.

You can try one of these;

(1) place your panelConfirmation component immediately after your commandLink component to ensure that they're siblings in the DOM hireatchy.

(2) use the ::: notation when specifying the panelConfirmation id in the commandLink component

Code:

 <ice:commandLink action="#{Management.remove}"
                                               immediate="true"
                                               panelConfirmation=":::saveConfirmPanel">

-- JB

I am successfully using <ice:panelConfirmation> in a portlet using ICEfaces 1.8.2 and Liferay 5.2.3.

Would you provide more details concerning the problem that your having?

-- JB

Thanks for the reply. I had looked at that Wiki article but I apparently didn't read it all the way through as I thought that it only pertained to making a custom portlet indexable.

Given your nudge, I was able to construct something that satisfies my immediate needs. The following snippet of Groovy code below searches for blog entries in the "MyGroup" community that have the "mytag" tag. The code then extracts the entryid and title from the results to construct a URL to the result.

Code:

 // Only search the Blogs portlet in the MyGroup group
 BooleanQuery contextQuery = BooleanQueryFactoryUtil.create()
 contextQuery.addRequiredTerm(Field.PORTLET_ID, PortletKeys.BLOGS)
 Group group = GroupLocalServiceUtil.getGroup(companyId, "MyGroup")
 contextQuery.addRequiredTerm(Field.GROUP_ID, group.groupId)
 
 // Search for entries with the specified tag
 String keywords = "mytag"
 BooleanQuery searchQuery = BooleanQueryFactoryUtil.create()
 searchQuery.addTerm(Field.TAGS_ENTRIES, keywords)
 
 // Combine the two subqueries
 BooleanQuery fullQuery = BooleanQueryFactoryUtil.create()
 fullQuery.add(contextQuery, BooleanClauseOccur.MUST)
 fullQuery.add(searchQuery, BooleanClauseOccur.MUST)
 
 try {
     Hits hits = SearchEngineUtil.search(companyId, fullQuery, QueryUtil.ALL_POS, QueryUtil.ALL_POS)
     def hitList = hits.toList()
 
     hitList.each { document ->
         long entryId = GetterUtil.getLong(document.get(Field.ENTRY_CLASS_PK))
         String title = GetterUtil.getString(document.get(Field.TITLE))
 
         // Construct a URL to the blog entry
         def docUrl = "${pathMain}/blogs/find_entry?entryId=${entryId}"
     }
 }
 catch (SearchException e) {
     log.error e
 }

Thanks again.

I'm attempting to call Liferay's search API in one of my ICEfaces portlet. I'm stuck at the call to OpenSearch.search .

All 3 variations of this method (see below) require an HttpServletRequest parameter which, to the best of my knowledge, I don't have access to in an ICEfaces portlet.

Code:

public interface OpenSearch {
 
 	public boolean isEnabled();
 
 	public String search(HttpServletRequest request, String url)
 		throws SearchException;
 
 	public String search(
 			HttpServletRequest request, long userId, String keywords,
 			int startPage, int itemsPerPage, String format)
 		throws SearchException;
 
 	public String search(
 			HttpServletRequest request, long groupId, long userId,
 			String keywords, int startPage, int itemsPerPage, String format)
 		throws SearchException;
 
 }

I tried to get the HttpServletRequest using an approach that I found in another thread;

Code:

ExternalContext externalContext = FacesContext.getCurrentInstance().getExternalContext();
 RenderRequest renderRequest = (RenderRequest) externalContext.getRequest();
 HttpServletRequest httpServletRequest = PortalUtil.getOriginalServletRequest(PortalUtil.getHttpServletRequest(renderRequest));

But this didn't work and instead resulted in the exception

java.lang.RuntimeException: Unable to get the HTTP servlet request from com.icesoft.faces.webapp.http.portlet.PortletExternalContext

I'm at a loss to determine how I can call make use of the Liferay search API from an ICEfaces portlet. I'm open to suggestions.

Thanks.

I'm doing something very similar to what you described, but it appears to be working for me.

In my dataTable, I have a button defined as:

Code:

 <ice:commandButton id="DeleteButtonId"
                    image="/Delete_16x16.png"
                    value="#{activity.id}"
                    actionListener="#{bean.deleteActionListener}" />

where activity.id is the primary key for the row object.

In my managed bean, the action listener is defined as:

Code:

 public void deleteActionListener(ActionEvent e) 
 {
     Long id = (Long)((HtmlCommandButton)e.getComponent()).getValue();
     
     // Locate and delete the object with the primary key of id and then refresh
     // the table data
 }

Since I'm using the primary key, the code isn't order dependent.

OK. I think that I now understand how the PortletSession scopes differ from the JSF managed bean scopes. I couldn't find anything describing this is Horstmann's book.

I'll implement your suggestion and change from JSF application scoped managed beans to programatically using PortletSession.APPLICATION_SCOPE beans to exchange information between my portlets.

Thanks for your help.

I'm sorry to say that that I don't fully understand your response.

It is my understanding that a portlet scoped attribute (PortletSession.PORTLET_SCOPE) is equivalent to a session scoped managed bean in JSF and that an application scoped attributes (PortletSession.APPLICATION_SCOPE) is equivalent to an application scoped managed bean in JSF. If this is correct, then your example is simply a non-JSF way of doing the same thing and it doesn't solve my problem.

Since it more likely that my understanding is wrong, would you please clarify how the scoping of the portlet session attributes differ from the JSF managed beans? Thanks.

I'm having some problems (or confusion) with ICEfaces IPC. I have two portlets that are contained in the same WAR and deployed to the same Liferay page. I want them to communicate via ICEfaces IPC. I'm using the SessionRenderer API.

I have successfully gotten this to work if I use an application scoped managed bean for shared data. However, since these portlets are on the same page, the shared data is unique to the user and application scope seems inappropriate.

However, if I change the scope of the managed bean (that is being used for shared data) to session, the portlets are not able to communicate properly. With this configuration, I'm able to determine that the AJAX push is executing, but it appears that the thread updating the secondary portlet is accessing a different instance of the session scoped managed bean.

When I consult the developer documentation, it states that the following conditions are required for using IPC in portlets;

Deploy the portlets that need to communicate in the same archive (.war file).

Use application-scoped beans to manage shared state between the portlets.

Use the ICEfaces Ajax Push feature to trigger client updates when the shared state changes.

So it seems that that behavior that I'm seeing is consistent with the documentation. However, using application scoped managed beans for shared data between two portlets on the same page doesn't seem appropriate.

I'm curious if anyone else is using ICEfaces IPC for portlets on the same page and how you're dealing with the application / session scoped managed bean issue.

I'm also seeing these log messages using ICEfaces 1.8.2, Liferay 5.2.3 and GlassFish 2.1. I see that there has been no activity on the Jira ticket. Is downgrading to 1.8.1 a viable solution?

Code:

 [#|2009-11-25T10:09:22.436-0600|SEVERE|sun-appserver2.1|com.icesoft.net.messaging.MessagePipeline|_ThreadID=34;_ThreadName=Timer-14;_RequestID=73bd63fd-ed8c-47b6-ae9d-3b3f3fa39f9b;|
 com.icesoft.net.messaging.MessageServiceException: java.io.FileNotFoundException: http://[0:0:0:0:0:0:0:1%0]:8080/ag-useraccount-portlet/block/message
 	at com.icesoft.net.messaging.http.HttpAdapter.publish(HttpAdapter.java:292)
 	at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:151)
 	at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:159)
 	at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:159)
 	at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:159)
 	at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:159)
 	at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:159)
 	at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:159)
 	at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:159)
 	at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:159)
 	at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:159)
 	at com.icesoft.net.messaging.PublishTask.run(PublishTask.java:46)
 	at java.util.TimerThread.mainLoop(Timer.java:512)
 	at java.util.TimerThread.run(Timer.java:462)
 Caused by: java.io.FileNotFoundException: http://[0:0:0:0:0:0:0:1%0]:8080/ag-useraccount-portlet/block/message
 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1311)
 	at com.icesoft.net.messaging.http.HttpAdapter.publish(HttpAdapter.java:253)
 	... 13 more
 |#]