The JavaEE Xperience

I was working on a PoC to integrate Bing and Google maps with webcenter. The idea was to use the javascript apis for this. While doing this, I encountered this strange issue.

I had a taskflow with two page fragments and this was meant to be embedded as a region in another page. The bug is that javascript included using the af:resource doesn’t get loaded in any page fragment other than the default activity. Presumably looks like the af:resource contents are not (re)painted when the region gets repainted. This happens with inline javascripts and also source-linked javascripts. The workaround is to use trh:Script instead of af:resource or (less elegantly) to embed all the required javascript into the default activity page. I chose to go with option 1.

P.S: There are other gotchas with the maps integration. I had to turn off PPR navigation to make the maps work. It looks like neither the Google nor the Bing API is particularly fond of div’s that are dynamically inserted into the HTML DOM. That is what I think happens with PPR navigation i.e. ADF rewrites the DOM (via Javascript?) with the new page elements.

This was a gotcha moment.

A colleague was attempting to create a custom taskflow for use in WebCenter Spaces. So this is what he did.

1) Deployed the custom taskflow as an ADF Library
2) Added the jar into the libraries of the WebCenterSpacesSharedLibExtension project and ensured the shared library deployment included it in the WAR.
3) Deployed the shared library to weblogic.
4) Deployed extend.spaces with the new library reference.

Everything went smoothly except the user couldn’t even get to the Login page anymore!! :-O The browser displayed the following

OracleJSP error: oracle.jsp.parse.JavaCodeException: Line # 6, oracle.jsp.parse.JspParseTagScriptlet@22e077e8
Error: Java code in jsp source files is not allowed in ojsp.next mode.

On looking at the log files there was this exception (see fullstack below) -

java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.application.ApplicationFactory

This sounded a bit weird. How can a Faces factory class be missing in the WebCenter domain? After all, WebCenter uses ADF which is a Faces implementation. It was the most curious thing.  Now, I don’t have a proper explanation for this but the problem was caused by the fact that the web.xml in the shared library contained all the ADF and Faces related references – servlets, filters and the like.  

I can only hazard a guess – when weblogic tries to load the library reference (quite naturally this has to be done before the web application – Spaces, in this case – is initialized). Now, the shared library contains a web.xml that among other things defines servlets and filters that are Faces-related. So, weblogic attempts to load up the filters (the TrinidadFilter is of specific interest in the stacktrace). However, the shared library does not go through the Faces web application lifecycle and does not get initialized as a Faces application (meaning the ApplicationFactory didn’t get init-ed). Anyway, cleaning out the web.xml worked the magic.

Of course, we still have the question of what happened with the web.xml. If you look at the vanilla web.xml that ships with the WebCenterSpacesSharedLibExtension project, you will see that it has no Faces references and in fact, only references a custom servlet. What happened was this – when the ADF Library was added to the library references of WebCenterSpacesSharedLibExtension, JDeveloper in all helpfulness went ahead and configured the web.xml to add ADF support. Eeeks!!! A simple enough thing but took an hour or so to get to the “Duh!” moment.

java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.application.ApplicationFactory
        at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:725)
        at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:239)
        at oracle.adfinternal.view.faces.config.rich.FacesDatabindingConfigurator._setupAdfDatabindingForJsf(FacesDatabindingConfigurator.java:122)
        at oracle.adfinternal.view.faces.config.rich.FacesDatabindingConfigurator.init(FacesDatabindingConfigurator.java:53)
        at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.init(GlobalConfiguratorImpl.java:399)
        at oracle.adfinternal.view.faces.webapp.rich.RegistrationFilter.init(RegistrationFilter.java:53)
        at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.init(TrinidadFilterImpl.java:110)
        at org.apache.myfaces.trinidad.webapp.TrinidadFilter.init(TrinidadFilter.java:54)
        at weblogic.servlet.internal.FilterManager$FilterInitAction.run(FilterManager.java:332)
        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
        at weblogic.servlet.internal.FilterManager.loadFilter(FilterManager.java:98)
        at weblogic.servlet.internal.FilterManager.preloadFilters(FilterManager.java:59)
        at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1876)
        at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:3153)
        at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1508)
        at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:482)
        at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:425)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
        at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:119)
        at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:200)
        at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:247)
        at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:425)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
        at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:119)
        at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:27)
        at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:636)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
        at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:205)
        at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:58)
        at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:161)
        at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79)
        at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:569)
        at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:150)
        at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:116)
        at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:323)
        at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:844)
        at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1253)
        at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:440)
        at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:163)

While exploring options to develop an upload-to-database feature, I came across repeated suggestions that using Oracle MultiMedia (previously InterMedia) datatypes (OrdDoc, OrdImage, etc.) was the way to go. A few forums started me off in the right direction. This one for e.g. However, it wasn’t as straightforward to get it working especially given that there was no documentation whatsoever around OrdDomain types in the Fusion guides. So these are the steps that need to be done. Read the rest of this entry »

The weblogic server provides a nifty API –  weblogic.servlet.security.ServletAuthentication. This class allows you to invoke authentication services from any controller – Servlets, JSF Managed Beans. This is pretty cool as you can do away with the j_security_check authentication and build your custom logic. Or perform programmatic authentication.

I am currently using this for a WebCenter Portal project where, based on a set of database derived parameters, I have to force the user to perform certain actions after login. My login page currently contains a custom login taskflow that implements the necessary logic for me. Of course, there are other ways to do this, but I needed to use ADF components (including BC) and using a bounded task flow seemed the best bet.

Note:

1) The ServletAuthentication class is present in the file wlserver_10.3\server\lib\weblogic.jar

2) If the logic requires logging the user out while in the taskflow, use ServletAuthentication.logout() instead of ServletAuthentication.invalidateAll(). If invalidateAll() is used, any navigation after this will result in an error.

In the default WebCenter Portal generated by JDeveloper, anonymous-role is granted “view” privilege on the home page. This may not always be desirable. The portal may not have any public content to put on the home page. In my current project, the entire portal has to be secured and available only to authenticated users. You would imagine this is a straight-forward thing to achieve but it’s not.

To turn off access to home page, I edited the page hierarchy and removed the grants assigned to anonymous-role. Now, when the user attempts to access /faces/oracle/webcenter/portalapp/pages/home.jspx, the user gets redirected correctly to the login page. However, if the user were to use the pretty url /pages_home the server throws a 404 error (perhaps an incorrectly flagged 403?) and the user is left with a very unhelpful error page. The trouble with this is that the user may choose to bookmark after his/her initial login and that bookmark will invariably point at the pretty URL.

There is also another side-effect to this. When the user hits logout, webcenter redirects the user to the current page after logout. Given that faces-config.xml contains a “logout_success” navigation case, I imagined that changing this to point at, say, the login page would work. Alas no. The only way to make this work was to change the Logout link to a goLink with the destination set to “adfAuthentication?logout=true&end_url=\faces\oracle\webcenter\portalapp\pages\login.jspx”.

Oh and this is w.r.t WebCenter 11.1.1.5.

Update: Thanks to Andrejus for an excellent workaround. His technique to solve the Session time-out problem can be applied here too.

When you copy the WebCenter FX skin, the copied skin doesn’t work as expected. Without any changes to the copy, I would expect the skin to render the same as WebCenter FX but it doesn’t. My guess is that the copied skin doesn’t inherit properly from the internal base skin used by WebCenter FX. The only way to overcome this is to copy the contents of the internal skin css into the copied skin. Read the rest of this entry »

With Webcenter PS3, Oracle offers something they term “Round-trip Development” using JDeveloper. Simply put, this enables you to

a) download resources from WebCenter Spaces to JDeveloper
b) edit or extend the resources in JDeveloper
c) Directly upload the resources to the server.
Read the rest of this entry »

Documenting some of the quirks, bugs and workarounds in WebCenter Spaces. These apply to PS2. Read the rest of this entry »

Contd from here.

I’ve managed to solve this. Thanks to the Oracle support note 1068828.1, we looked at MDS customizations as an option. It’s still a bit of a hack but works for our case. Read the rest of this entry »

Another bug? Validation messages from the ADF BC layer don’t display correctly within Webcenter Spaces. Instead of the custom validation message that’s setup in the BC layer, Spaces always displays “Unexpected error(s) occurred. You may want to contact Administrator with the error reference.” The error-ed fields are flagged correctly though. I have raised an SR with Oracle for this. I am told that Webcenter Spaces considers any Exception outside of the oracle.webcenter package to be an unexpected error. I am waiting to see if Oracle gets back with a feasible workaround. Hmmm!

Given that ADF taskflows are a recommended way to extend webcenter spaces, I find this limitation, well, very limiting.