Showing posts with label Java. Show all posts
Showing posts with label Java. Show all posts

Tuesday, August 2, 2016

Remote deployment failed (oracle.jdevimpl.deploy.common.Jsr88RemoteDeployer) with Oracle® JDeveloper

The problem

Using JDeveloper 12.1.3, I had created a dummy BPMN Process with just a User Task bound to a human task. For this task I had also auto-generated an input form. Deploying the task form went fine, but when trying to deploy the BPMN process I got the following error:


[08:30:27 AM] Deployment cancelled.
[08:30:27 AM] Taskflow deployment failed to deploy to server. Remote deployment failed
[08:30:27 AM] Deployment cancelled.
[08:30:27 AM] ----  Deployment incomplete  ----.
[08:30:27 AM] Remote deployment failed (oracle.jdevimpl.deploy.common.Jsr88RemoteDeployer)

The cause

After trying various things, I discovered the problem was my proxy settings in Oracle® JDeveloper.

The solution

Tools -> Preferences -> Web Browser and Proxy -> Proxy Settings, and then I set it to No Proxy. 
Now I could deploy the process without any errors. 

I assume it would also have worked if I had set it to Manual Proxy Settings, and then added my hostname to the exception list.

Monday, March 14, 2016

Oracle® WebLogic managed server reaches ADMIN state during startup due to name collision

The problem

When starting a Oracle® WebLogic managed server it halts when reaching the ADMIN state. 
Looking at the managed server's out file I saw the following error:

<Mar 15, 2016 8:45:40 AM UTC> <Error> <Deployer> <BEA-149231> <Unable to set the activation state to true for the application "MyDataSource".
weblogic.application.ModuleException: weblogic.common.ResourceException: Failed to bind remote object (ClusterableRemoteRef(6058417782957188722S:my-server:soa_domain:soa_server1 null)/289        [weblogic.jdbc.common.internal.RemoteDataSource]) to replica aware stub at MY_DS(ClusterableRemoteRef(6058417782957188722S:my-server:soa_domain:soa_server1 [6058417782957188722S:my-server:soa_domain:soa_server1/288])/288        [weblogic.jdbc.common.internal.RemoteDataSource])
        at weblogic.jdbc.module.JDBCModule.activate(JDBCModule.java:411)
        at weblogic.application.internal.flow.ModuleListenerInvoker.activate(ModuleListenerInvoker.java:114)
        at weblogic.application.internal.flow.ModuleStateDriver$2.next(ModuleStateDriver.java:195)
        at weblogic.application.internal.flow.ModuleStateDriver$2.next(ModuleStateDriver.java:190)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
        Truncated. see log file for complete stacktrace
Caused By: weblogic.common.ResourceException: Failed to bind remote object (ClusterableRemoteRef(6058417782957188722S:my-server:soa_domain:soa_server1 null)/289   [weblogic.jdbc.common.internal.RemoteDataSource]) to replica aware stub at MY_DS(ClusterableRemoteRef(6058417782957188722S:my-server:


The cause

The error above says I have a problem starting the MyDataSource data source due to a name collision. Logging into the WebLogic console, and looking at my data sources, I realized I had two data sources with the same JNDI location. The reason was that I had prepared a new data source long time ago, and forgotten all about it. During the startup of the managed server, my new data source had started up, but the old one could of course not start since it had the same JNDI  location.

The solution

  1. Removed the old and obsolete data source with the conflicting JNDI location.
  2. Checked the managed server's out file for other errors, and there were none. 
  3. Resumed startup of the managed server so the server state changed from ADMIN to RUNNING. 



Thursday, March 10, 2016

Oracle® SOA Suite 12.1.3 startup fails with CoherenceException due to ensureWKAAddresses

The problem

After a fresh install of Oracle® SOA Suite 12.1.3 with BPM and BAM enabled, both the SOA server and the BAM server failed to startup due to the following exception:

<Mar 9, 2016 9:49:34 AM UTC> <Error> <weblogic-coherence-integration> <BEA-000012> <Server bam_server1 is configured with localhost as the Unicast Listen Address which is an error in Coherence Production mode. A generated Coherence WKA list will not operate correctly across multiple machines.>
Mar 09, 2016 9:49:36 AM oracle.dms.servlet.DMSServletFilter setEagerlySetContextValues
INFO: The setting that controls the eager fetching of some types of execution context data has been set to true.
<Mar 9, 2016 9:49:37 AM UTC> <Critical> <WebLogicServer> <BEA-000362> <Server failed. Reason:

There are 1 nested errors:

weblogic.cacheprovider.coherence.CoherenceException:
    at weblogic.cacheprovider.coherence.CoherenceClusterManager.ensureWKAAddresses(CoherenceClusterManager.java:510)
    at weblogic.cacheprovider.coherence.CoherenceClusterManager.configureClusterService(CoherenceClusterManager.java:236)
    at weblogic.cacheprovider.CacheProviderServerService.bootCoherenceFromWLSCluster(CacheProviderServerService.java:225)
    at weblogic.cacheprovider.CacheProviderServerService.initCoherence(CacheProviderServerService.java:94)
    at weblogic.cacheprovider.CacheProviderServerService.initialize(CacheProviderServerService.java:71)
    at weblogic.cacheprovider.CacheProviderServerService.start(CacheProviderServerService.java:65)
    at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:78)
    at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1017)
    at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:388)
    at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:430)
    at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
    at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)
    at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82)
    at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488)
    at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)
    at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
    at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)
    at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)
    at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:263)

>
<Mar 9, 2016 9:49:37 AM UTC> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FAILED.>
<Mar 9, 2016 9:49:37 AM UTC> <Error> <WebLogicServer> <BEA-000383> <A critical service failed. The server will shut itself down.>
<Mar 9, 2016 9:49:37 AM UTC> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FORCE_SHUTTING_DOWN.>

The cause

As stated in the exception, the issue is that the servers are listening on localhost instead of the actual hostname while the Oracle® WebLogic Server is running in Production mode.

The solution

There are multiple solutions to this one, but the two most obvious ones are to either run Oracle® WebLogic Server is running in Development mode, or to listen to the actual hostname instead of localhost. I would not recommend the former. Not unless it is a single user development system.

Run the hostname command to find the actual hostname. The hostname command works on both Linux, Unix and Windows.
Edit the managed servers through the  Oracle® WebLogic Server console, and set the value returned from the hostname command as the Listen Address,

Tuesday, March 1, 2016

Could not initialize class sun.awt.X11GraphicsEnvironment for frevvo module in Oracle® BPM Suite 12.2.1

The problem

BPM Composer in Oracle® BPM Suite 12.2.1 fails when open enterprise maps, and the SOA server's out file says:

<Mar 1, 2016 7:31:43 AM UTC> <Error> <HTTP> <BEA-101017> <[ServletContext@881844748[app:frevvo module:/frevvo path:null spec-version:3.1]] Root cause of ServletException.
java.lang.NoClassDefFoundError: Could not initialize class sun.awt.X11GraphicsEnvironment
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:264)
    at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:103)
    at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:82)
    at sun.awt.X11FontManager.isHeadless(X11FontManager.java:511)
    Truncated. see log file for complete stacktrace
>

The cause

The JVM was not running headless, and it did not have a DISPLAY variable set to point to a X server.

The solution

Added -Djava.awt.headless=true to the soa server, and restarted it.

Friday, February 5, 2016

The domain version 12.2.1.0.0 is greater than the release version 12.1.3.0 of this server when starting an Oracle® WebLogic managed server.

The problem

After starting the Oracle® WebLogic AdminServer in a sandbox environment, I attempted to start the managed servers, but got the following errors in the $DOMAIN_HOME/servers/<ms-server>/logs/<ms-server>.out log file:

<Error> <Configuration Management> <BEA-150001> <An error occurred while connecting to the Administration Server to bootstrap through the URL: http://localhost:7001/bea_wls_management_internal2/Bootstrap,
 user: weblogic.
weblogic.management.configuration.ConfigurationException: [Management:141252]The domain version 12.2.1.0.0 is greater than the release version 12.1.3.0 of this server.
        at weblogic.management.provider.internal.BootStrapHelper.getBootStrapStruct(BootStrapHelper.java:147)
        at weblogic.management.provider.internal.RuntimeAccessImpl.initialize(RuntimeAccessImpl.java:444)
        at weblogic.management.provider.internal.RuntimeAccessService.start(RuntimeAccessService.java:70)
        at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:78)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1017)
        at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:388)
        at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:430)
        at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
        at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)
        at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82)
        at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488)
        at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)
        at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:606)
        at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
        at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:231)
        at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:254)
        at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:413)
        at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
        at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)
        at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82)
        at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488)
        at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)
        at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
        at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)
        at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)

The cause

I was at first a bit puzzled by the message "The domain version 12.2.1.0.0 is greater than the release version 12.1.3.0 of this server." because the AdminServer console footer said it was version 12.1.3.0, and the startup scripts in $DOMAIN_HOME/bin also only pointed to 12.1.3.0 binaries.

I discovered there were 12.2.1.0.0 binaries installed in a new $ORACLE_HOME, but as mentioned, these binaries were not referenced by the scripts in $DOMAIN_HOME/bin.

The fact that 12.2.1.0.0 binaries were available on the file system suggested someone had either planned to create a new 12.2.1.0.0 domain, or planned to upgrade the existing 12.1.3.0 domain.

After discussing this with a colleague it became clear that he had installed the new binaries, and that all he wanted to do with them was to create response files for running the upgrade of a domain on a different server. He only intended to run the information collection part, but it had obviously also touched the $DOMAIN_HOME/config/confix.xml file in the 12.1.3.0 domain, and changed the version parameter to 12.2.1.0.0 as shown below:

$ grep version $DOMAIN_HOME/config/config.xml
<?xml version='1.0' encoding='UTF-8'?>
  <domain-version>12.2.1.0.0</domain-version>
  <configuration-version>12.2.1.0.0</configuration-version>

The solution

  1. Shutdown the entire domain. In my case that meant the AdminServer and the NodeManager.
  2. Took a file system backup of $DOMAIN_HOME
  3. Edited $DOMAIN_HOME/config/config.xml and replaced the two occurences of 12.2.1.0.0 with 12.1.3.0.0
  4. Started the NodeManager, the AdminServer and the managed servers up without any errors.

Post-change verification:

$ grep version config.xml
<?xml version='1.0' encoding='UTF-8'?>
  <domain-version>12.1.3.0.0</domain-version>
  <configuration-version>12.1.3.0.0</configuration-version>

Unexpected EOF in prolog when starting Oracle® WebLogic AdminServer

The problem

The Oracle® WebLogic AdminServer has started up and reached RUNNING state, but I have the habit of checking the AdminServer.out file after startup, and today I saw the following error:

<Error> <Default> <J2EE JMX-47001> <A JAXB error occurred during unmarshalling of "usermessagingconfig.xml".
javax.xml.bind.UnmarshalException
 - with linked exception:
[Exception [EclipseLink-25004] (Eclipse Persistence Services - 2.5.2.v20140319-9ad6abd): org.eclipse.persistence.exceptions.XMLMarshalException
Exception Description: An error occurred unmarshalling the document
Internal Exception: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
 at [row,col {unknown-source}]: [1,0]]
        at org.eclipse.persistence.jaxb.JAXBUnmarshaller.handleXMLMarshalException(JAXBUnmarshaller.java:980)
        at org.eclipse.persistence.jaxb.JAXBUnmarshaller.unmarshal(JAXBUnmarshaller.java:588)
        at org.eclipse.persistence.jaxb.JAXBUnmarshaller.unmarshal(JAXBUnmarshaller.java:140)
        at oracle.as.config.persistence.jaxb.JAXBXmlPersistenceManagerImpl.load(JAXBXmlPersistenceManagerImpl.java:190)
        at oracle.as.jmx.framework.util.DefaultConfigObjectMBeanAssociationInfo.loadConfigObject(DefaultConfigObjectMBeanAssociationInfo.java:638)
        at oracle.as.jmx.framework.util.DefaultConfigObjectMBeanAssociationInfo.initializeConfigObjectAndAssociatedMBean(DefaultConfigObjectMBeanAssociationInfo.java:676)
        at oracle.as.jmx.framework.wls.spi.ComponentMBeans.registerMBeans(ComponentMBeans.java:244)
        at oracle.as.jmx.framework.wls.spi.ComponentMBeans.registerDomainLevelMBeans(ComponentMBeans.java:356)
        at oracle.as.jmx.framework.wls.spi.ComponentMBeans.registerRuntimeMBeanServerMBeans(ComponentMBeans.java:373)
        at oracle.as.jmx.framework.wls.spi.JMXFrameworkProviderImpl$3.run(JMXFrameworkProviderImpl.java:1134)
        at java.security.AccessController.doPrivileged(Native Method)
        at oracle.as.jmx.framework.wls.spi.JMXFrameworkProviderImpl.initRuntimeMBeanServer(JMXFrameworkProviderImpl.java:1127)
        at oracle.as.jmx.framework.wls.spi.JMXFrameworkProviderImpl.access$200(JMXFrameworkProviderImpl.java:210)
        at oracle.as.jmx.framework.wls.spi.JMXFrameworkProviderImpl$2.run(JMXFrameworkProviderImpl.java:1080)
        at java.lang.Thread.run(Thread.java:745)
Caused By: Exception [EclipseLink-25004] (Eclipse Persistence Services - 2.5.2.v20140319-9ad6abd): org.eclipse.persistence.exceptions.XMLMarshalException

The cause

The usermessagingconfig.xml in question was located in $DOMAIN_HOME/config/fmwconfig/usermessagingconfig.xml

ls -l $DOMAIN_HOME/config/fmwconfig/usermessagingconfig.xml confirmed that the file had not been update since the 9th of September 2015, but then again this WebLogic server had been running for several months before I restarted it today. This is a sandbox server so it is used very infrequently.

ls -l $DOMAIN_HOME/config/fmwconfig/usermessagingconfig.xml also showed me that the size was 0 bytes. 

I remembered that the mount point where WebLogic stores its domain configuration files ran out of disk space in September last year. At that time it corrupted the EmbeddedLDAP folder, but after clearing the log files and re-creating the EmbeddedLDAP, WebLogic was started up again. In hindsight I realize that the same error with usermessagingconfig.xml must have been in AdminServer.out back then as well, but I obviously failed to notice it at the time. 

The solution

I added the following to $DOMAIN_HOME/config/fmwconfig/usermessagingconfig.xml:

<?xml version="1.0"?>
<MessagingConfiguration xmlns="http://www.oracle.com/ucs/messaging/config"
                        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                        xsi:schemaLocation="http://www.oracle.com/ucs/messaging/config ../config.xsd" version="12.1.3.0.0">


  <Server>
  </Server>

</MessagingConfiguration>

Then restarted the AdminServer, and the error was gone.

Tuesday, January 19, 2016

ORA-01017: invalid username/password; logon denied when updating WebLogic data source and you know the username and password are correct

Background

The title might sound a bit confusing, because everyone that has experienced an ORA-01017 knows it only happens if either the database username or password is incorrect.

I recently had to change the password for all of the infrastructure component schemas in a Oracle® SOA Suite 12.1.3 installation. How to do it is documented at https://docs.oracle.com/middleware/1213/core/ASADM/repos.htm#ASADM637

After running the modifyBootStrapCredential for the OPSS configuration I expected everything to be dandy except a few ORA-01017 errors for the data sources I had not yet updated with the new password. Everything I needed to do was to edit each data source and provide the new password. Or so I thought...

The problem

When I tried to apply the changes I got the following ORA-01017 error for each data source I tried to edit:


I was a bit thunderstruck at first because the username and passwords worked fine in both SQL*Plus and in SQL Developer.

The AdminServer out file contained errors like this:
<Jan 19, 2016 1:15:54 PM UTC> <Error> <Deployer> <BEA-149205> <Failed to initialize the application "LocalSvcTblDataSource" due to error weblogic.application.ModuleException: weblogic.common.resourcepool.ResourceSystemException:
 Could not create connection for datasource '<data source name>'.

 The returned message is: ORA-01017: invalid username/password; logon denied

 It is likely that the login or password is not valid.
 It is also possible that something else is invalid in
 the configuration or that the database is not available.
weblogic.application.ModuleException: weblogic.common.resourcepool.ResourceSystemException:
 Could not create connection for datasource '<data source name>'.

 The returned message is: ORA-01017: invalid username/password; logon denied

 It is likely that the login or password is not valid.
 It is also possible that something else is invalid in
 the configuration or that the database is not available.
        at weblogic.jdbc.module.JDBCModule.prepare(JDBCModule.java:350)
        at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:100)
        at weblogic.application.internal.flow.ModuleStateDriver$1.next(ModuleStateDriver.java:175)
        at weblogic.application.internal.flow.ModuleStateDriver$1.next(ModuleStateDriver.java:170)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
        Truncated. see log file for complete stacktrace
Caused By: weblogic.common.resourcepool.ResourceSystemException:
 Could not create connection for datasource '<data source name>'.

 The returned message is: ORA-01017: invalid username/password; logon denied

 It is likely that the login or password is not valid.
 It is also possible that something else is invalid in
 the configuration or that the database is not available.
        at weblogic.jdbc.common.internal.JDBCUtil.parseException(JDBCUtil.java:322)
        at weblogic.jdbc.common.internal.ConnectionEnvFactory.makeConnection0(ConnectionEnvFactory.java:492)
        at weblogic.jdbc.common.internal.ConnectionEnvFactory.access$000(ConnectionEnvFactory.java:20)
        at weblogic.jdbc.common.internal.ConnectionEnvFactory$1.run(ConnectionEnvFactory.java:388)
        at java.security.AccessController.doPrivileged(Native Method)
        Truncated. see log file for complete stacktrace
>

The workaround

For each data source I had to do the following to work around this problem:

  1. Clicked the Lock & Edit button.
  2. Had to note which targets the data source was using.
  3. Removed the targets from the data source, and clicked on the Save button.
  4. Clicked on the Activate Changes button.
  5. Clicked the Lock & Edit button.
  6. Updated the password for the data source, and clicked on the Save button.
  7. Clicked on the Activate Changes button.
  8. Clicked the Lock & Edit button.
  9. Added the targets that I noted in step 2 to the data source, before I clicked on the Save button.
  10. Clicked the Activate Changes button.

After all data sources had been updated with the new passwords, and the data sources had been re-targeted, I did a full domain restart. 

While I started the AdminServer up, I looked out for errors like these which could indicate I had forgotten to update some data sources:

<Jan 19, 2016 1:32:34 PM UTC> <Error> <Deployer> <BEA-149205> <Failed to initialize the application "<data source name>" due to error weblogic.application.ModuleException: weblogic.common.resourcepool.ResourceSystemException