Deploying ADF applications to GlassFish: oracle.adf.share.config.FallbackConfigImpl.getMDSInstance error

What to do when you get "MDSInstance" exception after deployment of ADF enterprise application to GlassFish 3.1.* ? I met this probem today, when I tried to deploy my app to the new GlassFish instance. The deployment ended admittedly successful, but the application threw an exception:

INFO: JSF1048: PostConstruct/PreDestroy annotations present.  ManagedBeans methods marked with these annotations will have said annotations processed.
SEVERE: java.lang.RuntimeException: class org.apache.catalina.core.ApplicationContextFacade
    at oracle.adf.share.ADFContext.initADFContext(ADFContext.java:2108)
    at oracle.adfinternal.view.faces.config.rich.FacesDatabindingConfigurator.init(FacesDatabindingConfigurator.java:51)
    at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.init(GlobalConfiguratorImpl.java:399)
    at oracle.adfinternal.view.faces.webapp.rich.RegistrationFilter.init(RegistrationFilter.java:56)
    at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.init(TrinidadFilterImpl.java:120)
    at org.apache.myfaces.trinidad.webapp.TrinidadFilter.init(TrinidadFilter.java:54)
    at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:264)
    at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:120)
    at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4685)
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:5377)
    at com.sun.enterprise.web.WebModule.start(WebModule.java:498)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:733)
    at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2019)
    at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1669)
    at com.sun.enterprise.web.WebApplication.start(WebApplication.java:109)
    at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
    at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
    at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:301)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
    at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
    at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:214)
    at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:207)
    at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:148)
    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 com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
    at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
    at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
    at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
    at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
    at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
    at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
    at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
    at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
    at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
    at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
    at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
    at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
    at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
    at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
    at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._service(GrizzlyContainer.java:182)
    at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:147)
    at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:148)
    at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
    at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
    at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
    at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
    at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
    at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
    at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
    at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
    at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
    at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
    at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
    at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
    at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.reflect.InvocationTargetException
    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 oracle.adf.share.ADFContext.initADFContext(ADFContext.java:2068)
    ... 71 more
Caused by: oracle.adf.share.ADFShareException: getMDSInstance error
    at oracle.adf.share.config.FallbackConfigImpl.getMDSInstance(FallbackConfigImpl.java:103)
    at oracle.adf.share.config.FallbackConfigImpl.getDefaultMDSInstance(FallbackConfigImpl.java:114)
    at oracle.adf.share.config.ADFConfigImpl.getMDSInstance(ADFConfigImpl.java:652)
    at oracle.adf.share.config.ADFConfigImpl.getMDSInstance(ADFConfigImpl.java:632)
    at oracle.adf.share.config.ADFContextMDSConfigHelperImpl.getMDSInstance(ADFContextMDSConfigHelperImpl.java:274)
    at oracle.adf.share.ADFContext.getMDSInstanceAsObject(ADFContext.java:1790)
    at oracle.adf.share.http.ServletADFContext.initialize(ServletADFContext.java:490)
    at oracle.adf.share.http.ServletADFContext.initThreadContext(ServletADFContext.java:397)
    at oracle.adf.share.http.ServletADFContext.initThreadContextIfNeeded(ServletADFContext.java:322)
    ... 76 more
Caused by: java.lang.NoClassDefFoundError: oracle/ias/cache/CacheException
    at oracle.mds.core.MDSInstance.initCache(MDSInstance.java:1649)
    at oracle.mds.core.MDSInstance.<init>(MDSInstance.java:1786)
    at oracle.mds.core.MDSInstance.<init>(MDSInstance.java:1738)
    at oracle.mds.core.MDSInstance.findAndStoreMDSInstance(MDSInstance.java:2035)
    at oracle.mds.core.MDSInstance.getOrCreateInstance(MDSInstance.java:529)
    at oracle.mds.core.MDSInstance.getOrCreateInstance(MDSInstance.java:492)
    at oracle.adf.share.config.ADFMDSConfig.getDefaultMDSInstance(ADFMDSConfig.java:452)
    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 oracle.adf.share.config.FallbackConfigImpl.getMDSInstance(FallbackConfigImpl.java:83)
    ... 84 more
Caused by: java.lang.ClassNotFoundException: oracle.ias.cache.CacheException
    at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
    ... 96 more

As it turned out it wasn't bug in my sourcecode, but in fact my mistake. I forgot to check the GlassFish configuration.

To avoid this error you simply need to configure JVM Cache for MDS. To do this simply add JVM Option "-Doracle.mds.cache=simple" to your domain.xml descriptor. It can look like fragment cited below:

<java-config debug-options="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9009" system-classpath="" classpath-suffix="">
        ...
        <jvm-options>-Doracle.mds.cache=simple</jvm-options>
      </java-config> 

To run ADF Essential app you need usually more memory. You can assign it by the way, adding next JVM parameter: -XX:MaxPermSize=_your_memory_setting_
Finally my extension of domain.xml looks like:

<java-config debug-options="-Xdebug 
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9009" 
system-classpath="" classpath-suffix="">
        ...
        <jvm-options>-Doracle.mds.cache=simple</jvm-options><jvm-options>-XX:MaxPermSize=512m</jvm-options>
      </java-config>

Installing node manager as a Windows service

To install node Manager as a Windows service you should perform following steps:

Step 1 - Install Node Manager as Windows Service:
Execute the following script: FMW_HOME/WL_HOME/server/bin/installNodeMgrSvc.cmd (by example C:\Oracle\Middleware\wlserver_10.3\server\bin\installNodeMgrSvc.cmd).
This should create a Windows Service called "Oracle WebLogic NodeManager (PATH_TO_DOMAIN)". Go to Windows Services and double click it. On the Log On tab, check the option "This Account" and provide the user/password you plan to use to run the WLS under windows.
Click OK and start the service, and next st op the service. This should create default node manager configuration files you could modify in next step.

Step 2 - Configure Node Manager Properties File:
Go to FMW_HOME/WL_HOME/common/nodemanager folder (by example C:\Oracle\Middleware\wlserver_10.3\common\nodemanager) and open nodemanager.properties file. Change the following properties to:

SecureListener=false
//If set to true, use the SSL listener, otherwise use the plain socket. There is better solution to set this to false, especially when you start to deal with nodemanager.

CrashRecoveryEnabled=true
//The CrashRecoveryEnabled configuration property allows Node Manager to restart servers after a system crash. The property is not enabled by default.

StartScriptEnabled=true

Finally you can start nodemanager service once again.

If you are trying to automate the environment using Node Manager and WLST and you are trying to Start the Admin Server and all the Managed Server using WLST only. And the Managed servers are to be started for the first time using WLST and Node Manager then you may encounter the below error :

<Feb 21, 2013 5:39:56 AM PST> <Critical> <WebLogicServer> <BEA-000362> <Server failed. Reason: 

There are 1 nested errors:

weblogic.management.ManagementException: Booting as admin server, but servername, UCM_server1, does not match the admin server name, AdminServer
    at weblogic.management.provider.internal.RuntimeAccessService.start(RuntimeAccessService.java:67)
    at weblogic.t3.srvr.ServerServicesManager.startService(ServerServicesManager.java:461)
    at weblogic.t3.srvr.ServerServicesManager.startInStandbyState(ServerServicesManager.java:166)
    at weblogic.t3.srvr.T3Srvr.initializeStandby(T3Srvr.java:881)
    at weblogic.t3.srvr.T3Srvr.startup(T3Srvr.java:568)
    at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:469)
    at weblogic.Server.main(Server.java:71)

> 

Cause :

The reason for the above error is that when the Managed Server are to be started for the first time using the Node Manager and WLST,  the boot.properties file ( at %domain_home%/servers/ManagedServer/security/) and startup.properties file ( %domain_home%/servers/ManagedServer/data/NodeManager/) should be already present.
Solution :

To generate the boot.properties file , and startup.properties file use the below WLST command :

nmGenBootStartupProps('NameOfManagedServer') 



wls:/SEOD/serverConfig> nmGenBootStartupProps('UCM_server1')

Successfully generated boot.properties at C:\Users\Administrator\Desktop\servers

\UCM_server1\data\nodemanager\boot.properties.

Successfully generated startup.properties at C:\Users\Administrator\Desktop\serv

ers\UCM_server1\data\nodemanager\startup.properties.

JSF @ManagedBean vs CDI @Named

There is a lot of discussions regarding differences between @ManagedBean and @Named annotations.  It appears that pretty much everyone is suggesting @Named as a best solution. As you can read, people say often that "...the presence of JSF 2 annotations is only to enable those on top of a Servlet containers ...".


I think this is not the whole truth.

Annotations from th package "javax.faces.bean" are provided for JSF managed beans where CDI annotations are helpers for CDI managed beans. Why I wrote JSF managed beans and CDI managed beans? Cause from the technical point of view JSF beans and CDI beans are completely separate entities. Managed bean is an object that it's life cycle is managed by a container. When JSF managed beans are managed by JSF container, CDI beans are managed by CDI container, and finally other types of beans (by example EJB) are managed by separate containers (by example EJB container) and so on.

Each container works independently. You could think about every container as a an independent process, which starts when server starts, scans loaded classes, gather and store some metadata about them, then when you need an object of a class at runtime they will give you instances of those classes and after finishing the job, they will destroy them.

So. We have different types of mananeged beans, and different types of managed bean containers. But which is "better" for typical JSF application?

The JSF managed beans are the part of JSF specifitacion from early 1.0 version, while the CDI container was introduced to the Java EE version 6.0 as a default, platform wide, managed beans framework. From this point of view you should use CDI where it is possible. CDI beans are far more advanced and flexible than simple JSF managed beans. With CDI you can use interceptors, conversation scope, events, type safe injection, decorators, stereotypes, producer methods and so on. In short words: as many says CDI is preferred over plain JSF because CDI allows for JavaEE-wide dependency injection. Of course if you need all this stuff.

But. There isn't any JSF managed beans advantage over CDI beans?

There are two simple issues which comes to my mind:

1. View Scope managed beans is a compelling reason to stick with JSF @ManagedBean - especially when you use a lot of AJAX requests. There is no standard replacement for this in CDI.
2. Efficiency is the next reason worth to consider. Especially if you work with Servlet container and CDI would be installed as an addition.

Webcenter Content UCM-CS-000001 java.io.IOException: !csUnableToFinishReadingStreamWithLength

As I noticed in one of our UCM instances, for some time has been steadily increasing the count of exceptions:

<2013-02-15 10:33:40 CET> <Error> <oracle.ucm.idccs> <UCM-CS-000001> <wyjątek ogólny
java.io.IOException: !csUnableToFinishReadingStreamWithLength,
default/repo_ucm/ucm_cluster/weblayout/groups/public/documents/doc/mdaw/mde2/~edisp/016565.pdf,
696043,936043!csUnableToFinishedReadingBytesBeingWritten!$socket write error: Connection reset by peer.
 at intradoc.common.DataStreamWrapperUtils.copyInStreamToOutputStream(DataStreamWrapperUtils.java:126)
 at intradoc.server.ServiceHttpImplementor.sendStreamResponse(ServiceHttpImplementor.java:2296)
 at intradoc.server.Service.doResponse(Service.java:2081)
 at intradoc.server.FileService.doResponse(FileService.java:1469)
 at intradoc.server.ServiceRequestImplementor.doRequest(ServiceRequestImplementor.java:802)
 at intradoc.server.Service.doRequest(Service.java:1890)
 at intradoc.server.ServiceManager.processCommand(ServiceManager.java:435)
 at intradoc.server.IdcServerThread.processRequest(IdcServerThread.java:265)
 at intradoc.server.IdcServerThread.run(IdcServerThread.java:160)
 at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
 at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
Caused By: java.net.SocketException: socket write error: Connection reset by peer.
 at jrockit.net.SocketNativeIO.writeBytesPinned(Native Method)
 at jrockit.net.SocketNativeIO.socketWrite(SocketNativeIO.java:46)
 at java.net.SocketOutputStream.socketWrite0(SocketOutputStream.java)
 at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
 at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
 at intradoc.common.DataStreamWrapperUtils.copyInStreamToOutputStream(DataStreamWrapperUtils.java:74)
 at intradoc.server.ServiceHttpImplementor.sendStreamResponse(ServiceHttpImplementor.java:2296)
 at intradoc.server.Service.doResponse(Service.java:2081)
 at intradoc.server.FileService.doResponse(FileService.java:1469)
 at intradoc.server.ServiceRequestImplementor.doRequest(ServiceRequestImplementor.java:802)
 at intradoc.server.Service.doRequest(Service.java:1890)
 at intradoc.server.ServiceManager.processCommand(ServiceManager.java:435)
 at intradoc.server.IdcServerThread.processRequest(IdcServerThread.java:265)
 at intradoc.server.IdcServerThread.run(IdcServerThread.java:160)
 at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
 at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
>

As I found with a small help of google above exception is a "typical" UCM broken pipe error, which is most often caused by the following:

• The network drops while the content server is attempting to communicate.
• The user cancels the request.
• The database is down or refuses a connection.

In the first reaction I thought:

In my cause it looks like TCP RST error when transferring data to the client application. The remote server can sent a RST packet to indicate an immediate dropping of the connection. This occurs when a packet is sent from UCM end of the connection but the other end does not recognize the connection. It will send back a packet with the RST bit set in order to forcibly close the connection. This can happen if the other side crashes and then comes back up, or if it calls close() on the socket while there is data from UCM in transit. Finally it is an indication that some of the data that are previously sent by UCM may not have been received.

After verifying the logs and code of my client applications I returned to start point of investigation. Client applications did not report any errors. There is also immposible that client side permemently drops connections.

I can't suspect network errors, cause client apps and UCM are running on the same physical machine.

Thereby I come up against a brick wall ...

Preview: JSF Components Wizard Beta will appear in early March

I would like to inform you that we are approaching the beta release of our new project: JSF Components Wizard. Although the current version of the product is prepared to release, we are still developing the project website. 

If nothing unexpected wouldn't happen, we will be ready in early March.