Passing parameter to included page using jsp:include in JSF 1.2

If you want to pass a parameter to an included page in JSF 1.2, it is not possible to do it like this:

<jsp:include page="header.jsp">
      <jsp:param value="main" name="pageTitle"/>
</jsp:include>

No way you can retrieve the parameter in header.jsp
This is because the JSF cycle already has built up it's view. Parameters you set while rendering, are not yet in the view that jsf created for this request. You could use the c:set tag and retrieve it using a scriptlet, but we want to do it clean and use no scriptlets in jsf, right.

The trick to do it is by binding a UIInput component in the first page to a certain value, and reading that value in the included file.

Say we have a request scoped bean (called pc_Header) HeaderBean.java with variable of type UIInput and name pageTitle. Then you can set the pagetitle in your main page like this:

<h:inputHidden binding="#{pc_Header.pagetitle}" value="My Title"></h:inputHidden>

This value can be used in the included header like this:

<h:outputText value=#{pc_Header.pagetitle.value}" />

Could not find or load xsl resource in WID testing WebSphere ESB component

When testing a mediation component in WebSphere Integration Developer 7 (WID), my xsl transformation failed with this message in the exception trace:

Caused by: com.ibm.wsspi.sibx.mediation.MediationConfigurationException: CWSXM3110E: Exception while initializing the XSL transformation engine with stylesheet 'xslt/MapInput_req_1.xsl'. This has been reported by the following entity: com.ibm.wbiserver.transform.exceptions.TransformServiceConfigurationException: CWSXM3108E: XSLTransform primitive could not find or load the resource 'xslt/MapInput_req_1.xsl'. This has been reported by the following entity: {1}

at com.ibm.ws.sibx.mediation.primitives.util.ExceptionHelper.newMediationConfigurationException(ExceptionHelper.java:96)

at com.ibm.ws.sibx.mediation.primitives.xslt.XSLTMediation.obtainTransformer(XSLTMediation.java:1380)

at com.ibm.ws.sibx.mediation.primitives.xslt.XSLTMediation.init(XSLTMediation.java:574)

at com.ibm.ws.sibx.scax.mediation.component.ESBFlowBuilder.createJavaMediationPrimitive(ESBFlowBuilder.java:1047)

... 54 more

Refer to the server logs for more information.

And in the systemout.log this trace was available:

 

[17/03/11 13:51:57:880 CET] 00000033 MFCImplementa E   CWSXM0202E: An unexpected exception occurred when processing mediation flow for component AuthenticationMediation in module AuthenticationMediation: CWSXM1025E: An unexpected exception occurred when the flow was called: CWSXM0111E:  Service runtime exception calling an import from mediation component AuthenticationMediation in module AuthenticationMediation: CWSXM0206E: An unexpected exception occurred.: com.ibm.ws.sibx.scax.mediation.component.FlowBuildException: CWSXM1007E: Mediation primitive MapToMember in mediation component AuthenticationMediation in module AuthenticationMediation encountered a problem during initialization.

CWSXM3108E: XSLTransform primitive could not find or load the resource 'xslt/MapToMember_res_1.xsl'.

 When opening the project the Enterprise Explorer, I could see that the xsl file was not there for MapToMember_Res_1.map. Normally the xsl file s are generated when building.

Luckily I found a workaround:

I could force WID to generate the xsl file by testing the transformation in the mapping editor of the transformation.

 Hitting the Test Map button (second from the right), made WID generate the xsl file! Sometimes it was not generated. Then I had to really execute the test before the xsl file was generated...

When deploying the module and testing the component, the xsl file was picked up, and the mediation completed successfully. One the problem persisted. The good old remove, restart, re-add of the project gave the final breakthrough.

Publishing failed in WebSphere Integration Developer

When publishing my Module to a brand new created ESB profile in WebSphere Integration Developer (WID), everything runs fine. But hitting the publish button after a change to republish the project was less fun.

"The publish encountered some problems and the application may not have been installed or it may have been successfully installed but was unable to start."
The reason being "Failure uploading archive to server"

I found 2 articles giving a different solution:
This technote 1414552 explains that the hostname verification service should be disabled to make sure the publishing does not mind any unresolved hostnames.


This blogpost on www.soa.si tells you that you can change to hostname in the server configuration, to make the publishing work.

None of the 2 methods worked for me. But thinking about why the hostname could not be resolved, I sudddenly saw the light: I configured a proxy in WID to access the online help system. Adding the hostname of the local machine to the "No Proxy For" list made the publishing successful.
You can find these settings in the preferences screen (window > preferences) in the general section, Network connections.