Managed Servers with Duplicate GUIDs

I have two SLES10 SP4 / OES2SP3 vm servers that had the same GUID in the ZCC. They were removed via the /opt/novell/zenworks/bin/novell-zenworks-xplat-uninstall. The zenworks directories were removed and the associated novell-zenworks-xplat packages and java packages were removed with YaST.
Both servers were re-started. The PreAgentPkg_AgentLinuxComplete.bin was run on the first and it registered in the ZCC. Twelve hours later I ran the PreAgent on the second and it completed successfully but did not show up in the ZCC. On a hunch I ran zac fsg on the second server and it came back with the same GUID the first server registered with.
Does anyone know how GUIDs are determined and more importantly, how to resolve this?
Thanks for any enlightenment.

(I was afraid of that :>)
What are the Reconciliation Settings in your Zone?
On 10/2/2012 4:26 PM, pwhitham wrote:
>
> The first attempt failed using plain http. Switched to https: and it was
> successfull. However, it registered with this info:
> Serial Number 4b36e5767765416bb620abd9f8e095dc
> GUID: 3449e3dd28d240aca090270511449a9f
>
> The GUID was the same GUID that the first server was using and that
> server promptly disappeared from the ZCC as soon as the second one
> registered.
>
> The second server had entries in the message log pointing back to the
> first server.
> "The managed device xxxx-srvr01 with guid
> 3449e3dd28d240aca090270511449a9f and IP address(es) 10.47.144.18 failed
> to register due to invalid authentication info."
>
> So what do these servers have in commom that would cause the same GUID
> to be generated on both of them. The first server was a vm built a year
> ago. The second server was migrated from Netware 6.5 to OES over three
> years back.
>
>
Craig Wilson - MCNE, MCSE, CCNA
Novell Knowledge Partner
Novell does not officially monitor these forums.
Suggestions/Opinions/Statements made by me are solely my own.
These thoughts may not be shared by either Novell or any rational human.

Similar Messages

  • SCOM 2012 Get Gray Management Servers With PowerShell

    Hi,
    I have SCOM 2012 R2.
    I want to get all the Management Servers that are in Gray state using powershell. How can I do that?
    I couldn't find anything good in the internet.
    The best I got was Get-SCOMManagementServer but when I tested it out - it still showed that my gateway's HealthState was "Success" even though it was gray.
    Thanks,
    Yakir.

    Hi,
    Check if this one helps
    Get-SCOMClass-name"Microsoft.SystemCenter.ManagementServer"|get-scomclassinstance|selectdisplayname,healthstate
    I dont what is your final objective, but check this link
    http://blogs.technet.com/b/jasonrydstrand/archive/2013/03/27/daily-scom-health-check-with-powershell.aspx

  • Managed Servers not starting with options configured in config.xml

    Hi,
    I Installed an Weblogic 10.3 on a Red Hat system and i configured an domain and 2 managed servers.
    I configured the servers with some java arguments like this:
    -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/home/oracle/logs/managed-server{1,2}_gc.log -XX:NewSize=128m -XX:MaxNewSize=128m -Xms384m -Xmx384m -XX:PermSize=128m
    I do see in the ${DOMAIN_HOME}/config/config.xml the managed servers with the settings that I have configured it via the Web Gui Admin Console.
    Now I want to start the Managed Servers with the following command:
    +cd ${DOMAIN_HOME}/bin+
    +./startManagedWebLogic.sh managed-server1 http://admin:port+
    When i check the console, I don't see the correct JVM settings! Also other options that I configured in the Web Gui Admin Console, don't appear in the logfile.
    The JVM settings I see, are those from the AdminServer.
    How can I change/fix this?
    Please help.
    Kind regards,
    Werner

    Hi,
    Please add the changes to the startup script startManagedWeblogic.sh.
    You can add the memory args settings as "-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/home/oracle/logs/managed-server{1,2}_gc.log -XX:NewSize=128m -XX:MaxNewSize=128m -Xms384m -Xmx384m -XX:PermSize=128m"
    Please let me know if it dosent fix.

  • Error while starting managed servers in a cluster

    Hi,
              I have Weblogic 8.1.3 deployed on my system. We've have a Ant script that set's up the project domain etc. We have an admin server and two other managed servers which are part of a cluster. I am able to start the admin server and access the admin console without any errors. However when I start any of the managed servers in the cluster, using the following command (startManagedWebLogic.cmd Reactor-1 http://localhost:80 OR startManagedWebLogic.cmd Reactor-2 http://localhost:80)
              I get the error listed below. The same Ant script was used to setup the project on another system and it worked but I haven't been able to set it up on my system.
              The error says that it could be due to servers having duplicate names in the cluster but thats not the case here, the managed servers are named Reactor-1 and 2.
              Also, the IP address being accessed, 192.168.141.50:81 is not my system, its another system on the network. I've done a full text search for the IP address but I've not been able to find it in ANY file under c:\bea.
              Can someone please tell me if I've missed something? I'd appreciated any help with this.
              Thanks
              Ameeth
              <Mar 21, 2005 4:52:43 PM GMT+05:30> <Notice> <Cluster> <BEA-000142> <Trying to download cluster JNDI tree from server Reactor-1
              .>
              <Mar 21, 2005 4:52:44 PM GMT+05:30> <Warning> <Net> <BEA-000905> <Could not open connection with host: 127.0.0.1 and port: 81.>
              <Mar 21, 2005 4:52:44 PM GMT+05:30> <Error> <Cluster> <BEA-000141> <TCP/IP socket failure occurred while fetching statedump ove
              r HTTP from Reactor-1.
              java.net.ConnectException: Tried all: '1' addresses, but could not connect over HTTP to server: '127.0.0.1', port: '81'
              at weblogic.net.http.HttpClient.openServer(Ljava.lang.String;I)V(HttpClient.java:275)
              at weblogic.net.http.HttpClient.openServer()V(HttpClient.java:329)
              at weblogic.net.http.HttpClient.<init>(Ljava.net.URL;Lweblogic.security.SSL.SSLClientInfo;Lweblogic.security.SSL.SSLSoc
              ketFactory;I)V(HttpClient.java:128)
              at weblogic.net.http.HttpClient.New(Ljava.net.URL;Lweblogic.security.SSL.SSLClientInfo;Lweblogic.security.SSL.SSLSocket
              Factory;I)Lweblogic.net.http.HttpClient;(HttpClient.java:196)
              at weblogic.net.http.HttpURLConnection.connect()V(HttpURLConnection.java:119)
              at weblogic.cluster.MemberManager.waitForSync(J)V(MemberManager.java:213)
              at weblogic.cluster.MemberManager.waitToSyncWithCurrentMembers()V(MemberManager.java:160)
              at weblogic.cluster.ClusterCommunicationService.initialize()V(ClusterCommunicationService.java:58)
              at weblogic.t3.srvr.T3Srvr.initializeHere()V(T3Srvr.java:924)
              at weblogic.t3.srvr.T3Srvr.initialize()V(T3Srvr.java:670)
              at weblogic.t3.srvr.T3Srvr.run([Ljava.lang.String)I(T3Srvr.java:344)
              at weblogic.Server.main([Ljava.lang.String)V(Server.java:32)
              >
              <Mar 21, 2005 4:52:47 PM GMT+05:30> <Notice> <Security> <BEA-090170> <Loading the private key stored under the alias DemoIdenti
              ty from the jks keystore file C:\bea\weblogic81\server\lib\DemoIdentity.jks.>
              <Mar 21, 2005 4:52:47 PM GMT+05:30> <Notice> <Security> <BEA-090171> <Loading the identity certificate stored under the alias D
              emoIdentity from the jks keystore file C:\bea\weblogic81\server\lib\DemoIdentity.jks.>
              <Mar 21, 2005 4:52:47 PM GMT+05:30> <Warning> <WebLogicServer> <BEA-000311> <Attempting to use low strength (exportable) certif
              icates with a full strength (domestic) license.>
              <Mar 21, 2005 4:52:47 PM GMT+05:30> <Notice> <Security> <BEA-090169> <Loading trusted certificates from the jks keystore file C
              :\bea\weblogic81\server\lib\DemoTrust.jks.>
              <Mar 21, 2005 4:52:47 PM GMT+05:30> <Notice> <Security> <BEA-090169> <Loading trusted certificates from the jks keystore file C
              :\bea\JROCKI~1\jre\lib\security\cacerts.>
              <Mar 21, 2005 4:52:48 PM GMT+05:30> <Notice> <WebLogicServer> <BEA-000355> <Thread "SSLListenThread.Default" listening on port
              7002, ip address 127.0.0.1>
              <Mar 21, 2005 4:52:48 PM GMT+05:30> <Notice> <WebLogicServer> <BEA-000355> <Thread "ListenThread.Default" listening on port 81,
              ip address 127.0.0.1>
              <Mar 21, 2005 4:52:48 PM GMT+05:30> <Notice> <Cluster> <BEA-000102> <Joining cluster ReactorCluster on 237.0.0.1:7001>
              <Mar 21, 2005 4:52:48 PM GMT+05:30> <Notice> <WebLogicServer> <BEA-000332> <Started WebLogic Managed Server "Reactor-1" for dom
              ain "ReactorAdminServer" running in Development Mode>
              <Mar 21, 2005 4:52:48 PM GMT+05:30> <Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode>
              <Mar 21, 2005 4:52:51 PM GMT+05:30> <Warning> <Net> <BEA-000905> <Could not open connection with host: 127.0.0.1 and port: 82.>
              <Mar 21, 2005 4:52:52 PM GMT+05:30> <Error> <Cluster> <BEA-000141> <TCP/IP socket failure occurred while fetching statedump ove
              r HTTP from 8288749592481618145S:localhost:[81,81,-1,-1,81,-1,-1,0,0]:192.168.141.50:81,192.168.141.50:82:ReactorAdminServer:Re
              actor-1.
              java.io.IOException: Reference to server no longer exists.
              Possible reasons for failure include having servers with duplicate names running on a cluster. Please check your configuratio
              n for this error.
              at weblogic.rmi.cluster.ServerInfoManager.updateServerInfo(Lweblogic.rmi.cluster.ServerInfo)V(ServerInfoManager.java:1
              11)
              at weblogic.rmi.cluster.ServerInfoManager.readUpdate(Ljava.lang.Object)V(ServerInfoManager.java:95)
              at weblogic.cluster.MemberAttributes.readExternal(Ljava.io.ObjectInput)V(MemberAttributes.java:103)
              at java.io.ObjectInputStream.readExternalData(Ljava.io.Externalizable;Ljava.io.ObjectStreamClass)V(Unknown Source)
              at java.io.ObjectInputStream.readOrdinaryObject(Z)Ljava.lang.Object;(Unknown Source)
              at java.io.ObjectInputStream.readObject0(Z)Ljava.lang.Object;(Unknown Source)
              at java.io.ObjectInputStream.readObject()Ljava.lang.Object;(Unknown Source)
              at weblogic.cluster.HTTPExecuteRequest.execute(Lweblogic.kernel.ExecuteThread)V(HTTPExecuteRequest.java:91)
              at weblogic.kernel.ExecuteThread.execute(Lweblogic.kernel.ExecuteRequest)V(ExecuteThread.java:219)
              at weblogic.kernel.ExecuteThread.run()V(ExecuteThread.java:178)
              at java.lang.Thread.startThreadFromVM(Ljava.lang.Thread)V(Unknown Source)

    make sure you use a unique cluster multicast ip address. are you sure that your etc/hosts file has proper entries for localhost?

  • Have NodeManager start managed servers on machine reboot

    Is there any way to have the Node Manager start all the managed servers belonging to a domain when a server reboots?
    I know I could create a separate Windows service for each of the managed servers I want running when the server comes on-line, or I could do some fancy scripting at start-up to connect to the Node Manager and have it start the managed servers.
    But I was hoping there would be a more elegant way of having the NM start them when it comes on-line.
    Ideas appreciated,
    dmac.

    Hi Dmac,
    To achieve this in Windows, you must consider the following WLS Components:
    1. Node Manager
    2. Admin Server
    3. Managed Server
    Node Manager
    For Node Manager, if you want the component to start automatically on boot up, your best option is to create a Windows Service. You may have selected the option to create a service for Node Manager during the WebLogic Server installation. Use Start -> Run -> services.msc from the Start menu to load the Windows Services Manager. If there is no service for Node Manager, use the following steps to create one.
    Create a Windows service for Node Manager:
    1. WL_HOME\server\bin\installNodeMgrSvc.cmd
    2. Verify in Windows Services that a service was created.
    Admin Server
    For the Admin Server, you can also create a Windows Service. Here are the steps for doing so:
    Create a Windows service for the Admin Server
    1. Create a text file named %MIDDLEWARE_HOME%\user_projects\domains\<domain name>\servers\AdminServer\security\boot.properties. Add the following lines:
    username=weblogic
    password=<the weblogic username password>
    2. Create a command script called installAdmServer_Service.cmd which you will want to make sure has lines like:
    SETLOCAL
    set DOMAIN_NAME=<your wls domain>
    set USERDOMAIN_HOME=<path to domain> # e.g., C:\middleware\FMW11g\user_projects\domains\ClassicDomain
    set SERVER_NAME=AdminServer
    set PRODUCTION_MODE=true
    cd %USERDOMAIN_HOME%
    call %USERDOMAIN_HOME%\bin\setDomainEnv.cmd
    call "<your middleware home>\wlserver_10.3\server\bin\installSvc.cmd"
    ENDLOCAL
    3. For troubleshooting/debugging purposes it is helpful to redirect standard out and error to a text file. Although most information is captured in the AdminServer server log files, you will not see all standard out and error when the server is started via a MS Windows Service (unlike when you start an AdminServer from the command prompt using startWebLogic.cmd). To redirect standard out to a text file, backup and edit installSvc.cmd and change the line at the bottom of the file so it includes the -log parameter, e.g.
    "%WL_HOME%\server\bin\beasvc" -install -svcname:"%DOMAIN_NAME%_%SERVER_NAME%" -javahome:"%JAVA_HOME%" -execdir:"%USERDOMAIN_HOME%" -extrapath:"%WL_HOME%\server\bin" -password:"%WLS_PW%" -cmdline:%CMDLINE% -log:"<your middleware home>\user_projects\domains\<your wls domain name>\servers\AdminServer\logs\AdminServer-stdout.txt"
    4. Now run "installAdmServer_Service.cmd." The Service should be installed. It will have a name like "beasvc %DOMAIN_NAME%_%SERVER_NAME%" (e.g. beasvc ClassicDomain_AdminServer). The Service "Startup Type" will be "Automatic." Start the Service. The Service will come back fairly quickly to say it is started. The actual time taken for the admin server to start and reach a state of 'RUNNING' will be longer - perhaps two or three minutes. The state of the server can be monitored by reviewing the stdout txt file.
    Managed Server
    For the Managed Server, you can also create a Windows Service. Here are the steps for doing so:
    Create a Windows service for the Managed Server (using wls_forms as an example)
    1. Create a text file named %MIDDLEWARE_HOME%\user_projects\domains\<domain name>\servers\WLS_FORMS\security\boot.properties. Add the following lines:
    username=weblogic
    password=<the weblogic username password e.g manager11g>
    2. Create a command script called installWLSFORMS_Service.cmd which has lines like
    SETLOCAL
    set DOMAIN_NAME=<your wls domain>
    set USERDOMAIN_HOME=<path to domain> # e.g. C:\middleware\FMW11g\user_projects\domains\ClassicDomain
    set SERVER_NAME=WLS_FORMS
    set PRODUCTION_MODE=true
    set ADMIN_URL=http://mymachine.mycompany.com:7001
    cd %USERDOMAIN_HOME%
    call %USERDOMAIN_HOME%\bin\setDomainEnv.cmd
    call "<your middleware home>\wlserver_10.3\server\bin\installSvc.cmd"
    ENDLOCAL
    NOTES:
    a. The ADMIN_URL value should reference the AdminServer hostname and listen port.
    b. The SERVER_NAME value is case sensitive. For example, if you are creating a MS Windows service for a different managed server such as 'wls_ods1' then the value needs to match the case of the server name otherwise the startup of the server via the MS Windows service will fail.
    c. Be careful that there are no trailing spaces after each line in the command file - trailing spaces will cause the managed server to fail at startup. For example a trailing space in the ADMIN_URL value will result in the error
    <19-Jan-2010 11:37:58 o'clock GMT> <Error> <EmbeddedLDAP> <BEA-171524> <Cannot determine the Listen address for the Admin server
    3. Now run "installWLSFORMS_Service.cmd." The Service should be installed, it will have a name like "beasvc %DOMAIN_NAME%_%SERVER_NAME%" (e.g. beasvc ClassicDomain_WLS_FORMS). The Service "Startup Type" will be "Automatic." Start the Service. The Service will come back fairly quickly to say it is started. The actual time taken for the managed server to start and reach a state of 'RUNNING' will be longer - perhaps two or three minutes. The state of the server can be monitored by reviewing the stdout txt file.
    Configuring the Windows service to restart upon failure
    As with any Windows Service, it is possible to configure the service to restart itself upon failure. These are standard options available when configuring a Windows Service in the context of Windows Services Manager. However, it is important to understand that Windows Services Manager only monitors the JVM process. If the JVM process fails (shuts down), then Windows Services Manager will attempt to restart it. But there are some scenarios where the Admin Server or Managed Server may go into an unhealthy or failed state but the JVM is still running. The Windows Service will not know to restart the process in these cases, whereas if the Admin Server and Managed Server had been started using Node Manager, Node Manager would recognize such a state and restart the process accordingly. So it may be desirable to start Node Manager with a Windows Service and then start the Admin Server and Managed Servers with Node Manager to take advantage of this monitoring feature. Below you will find one such example of how to do this.
    Example of starting the Admin Server and a Managed Server using Node Manager
    1. Create a batch script similar to this:
    Myscript.cmd
    call D:\Product\Oracle\Middleware\user_projects\domains\base_domain\bin\setDomainEnv.cmd
    java weblogic.WLST D:\Product\Oracle\Middleware\user_projects\domains\base_domain\ServerStart.py
    2. Create a Python script similar to this:
    ServerStart.py
    nmConnect('weblogic', 'welcome1', '192.168.0.101', '5556', 'base_domain','D:\Product\Oracle\MIDDLE~1\USER_P~1\domains\BASE_D~1','ssl')
    nmStart('AdminServer')
    connect ('weblogic','welcome1','t3://192.168.0.101:7001')
    nmstart('myserver','Server','t3://192.168.0.101:7002')
    If you want this to happen automatically on boot up, you can run the script (myscript.cmd) from the Windows Scheduler. You must configure the scheduler to run the script on system startup. This will execute the script without requiring an interactive login to Windows (unattended).
    Some Additional Information to Remember
    The startup.properties file for the Admin and Managed servers must have "AutoRestart=true." This can be set in the "Health Monitoring" tab for each respective server in the WLS console.
    The boot.properties file must be configured and present for each server that you plan to start automatically so that you are not prompted for the user name and password each time. If you are not currently prompted when you start the servers then it is already done.
    The nodemanager.properties file must have "StartScriptEnabled=true" and "StartScriptName=StartWeblogic.cmd" in place.

  • Load Balancing Directory Servers with Access Manager - Simple questions

    Hi.
    We are in the process of configuring 2 Access Manager instances (servers) accessing the same logical LDAP repository (comprising physically of two Directory Servers working together with Multi-Master Replication configured and tested) For doing this, we are following guide number 819-6258.
    The guide uses BigIP load balancer for load balancing the directory servers. However, we intend to use Directory Proxy Server. Since we faced some (unresolved) issues last time that we used DPS, there are some simple questions that I would be very grateful to have answers to:
    1. The guide, in section 3.2.10 (To configure Access Manager 1 with the Directory Server load balancer), talks about making changes at 4 places, and replacing the existing entry (hostname and port) with the load balancer's hostname and port (assuming that the load balancer has already been configured). It says that changes need not be made on Access Manager 2 since the LDAPs are in replication, and hence changes will be replicated at all places. However, the guide also states that changes have to be made in two files, namely AMConfig.properties, and the serverconfig.xml file. But these changes will not be reflected on Access Manager 2, since these files are local on each machine.
    Question 1. Do changes have to be made in AMConfig.properties and serverconfig.xml files on the other machine hosting Access Manager 2?
    Question 2: What is the purpose of putting these values here? Specifically, what is achieved by specifying the Directory server host and port in AMConfig.properties, as well as in serverconfig.xml?
    Question 3. In the HTTP console, there is the option of specifying multiple primary LDAP servers, as well as multiple secondary LDAP servers. What is the purpose of these? Are secondary servers attempted when none of the list in the primary list are accessible? Also, if there are multiple entries in the primary server list, are they accessed in a round robin fashion (hereby providing rudimentary load balancing), or are other servers accessed only when the one mentioned first is not reachable etc.?
    2. Since I do not have a load balancer setup yet, I tried the following deviation to the above, which, according to me, should have worked. If viewed in the HTTP console, LDAP / Membership / MSISDN and Policy configuration all pointed to the DS on host 1. When I changed all these to point to the directory server on host 2 (and made AMConfig.properties and serverconfig.xml on host 1 point to DS of host 2 as well), things should have worked fine, but apparently Access manager 1 could not be started. Error from Webserver:
    [14/Aug/2006:04:30:36] info (13937): WEB0100: Loading web module in virtual server [https-machine_1_FQDN] at [search]
    [14/Aug/2006:04:31:48] warning (13937): CORE3283: stderr: Exception in thread "EventService" java.lang.ExceptionInInitializerError
    [14/Aug/2006:04:31:48] warning (13937): CORE3283: stderr: at com.iplanet.services.ldap.event.EventServicePolling.run(EventServicePolling.java:132)
    [14/Aug/2006:04:31:48] warning (13937): CORE3283: stderr: at java.lang.Thread.run(Thread.java:595)
    [14/Aug/2006:04:31:48] warning (13937): CORE3283: stderr: Caused by: java.lang.InterruptedException
    [14/Aug/2006:04:31:48] warning (13937): CORE3283: stderr: at com.sun.identity.sm.ServiceManager.<clinit>(ServiceManager.java:74)
    [14/Aug/2006:04:31:48] warning (13937): CORE3283: stderr: ... 2 more
    In effect, AM on 1 did not start. On rolling back the changes, things again worked like previously.
    Will be really grateful for any help / insight / experience on dealing with the above.
    Thanks!

    Update to the above, incase anyone is reading:
    We setup a similar setup in Windows, and it worked. Here is a detailed account of what was done:
    1. Host 1: Start installer, install automatically, chose Directory server, Directory Administration server, Directory Proxy server, Web server, Access Manager.
    All installed, and worked fine. (AMConfig.properties, serverconfig.xml, and the info in LDAP service, all pointed to HOST1:389)
    2. Host 2: Start installer, install automatically, chose Directory server, Directory Administration server, Directory Proxy server, Web server, Access Manager.
    All installed, and worked fine. (AMConfig.properties, serverconfig.xml, and the info in LDAP service, all pointed to HOST2:389)
    3. Host 1: Started replication. Set to Master
    4. Host 2: Started replication. Set to Master
    5. Host 1: Setup replication agreement to Host 2
    6. Host 2: Setup replication agreement to Host 1
    7. Initiated the remote replica from Host 1 ----> Host 2
    Note that since default installation uses abc.....xyz as the encryption key, setting this to same was not an issue.
    9. Started webserver for Host 1 and logged into AM as amadmin.
    10. Added Host 2 FQDN in DNS Aliases / Realms
    11. Added http://HOST2_FQDN:80 in the Platform server (instance) list.
    12. Started Host 2 webserver. Logged in AM on Host 2, things worked fine.
    At this stage, note the following:
    a) Host 1:
    AMConfig.properties file has
    com.iplanet.am.directory.host=host1_FQDN
    and
    com.iplanet.am.directory.port=389
    serverconfig.xml has:
    <Server name="Server1" host="host1_FQDN" port="389" type="SIMPLE" />
    b) Host 2:
    AMConfig.properties file has
    com.iplanet.am.directory.host=host2_FQDN
    and
    com.iplanet.am.directory.port=389
    serverconfig.xml has:
    <Server name="Server1" host="host2_FQDN" port="389" type="SIMPLE" />
    c) If one logs into AM, and checks LDAP servers for LDAP / Policy Configuration / Membership etc services, they all contain Host2_FQDN:389 (which makes sense, since replica 2 was initialized from 1)
    Returning back to the configuations:
    13. On Host 1, login into the Admin server console of the Directory server. Navigate to the DPS, and confgure the following:
    a) Network Group
    b) LDAP servers
    c) Load Balancing
    d) Change Group
    e) Action on-bind
    f) Allow all actions (permit modification / deletion etc.).
    g) any other configuations required - Am willing to give detailed steps if someone needs them to help me / themselves! :)
    So now, we have DPS configured and running on Host1:489, and distributing load to DS1 and DS2 on a 50:50 basis.
    14. Now, log into AM on Host 1, and instead of Host1_fqdn:389 (for DS) in the following places, specify Host1_fqdn:489 (for the DPS)--
    LDAP Authentication
    MSISDN server
    Membership Service
    Policy configuation.
    Verified that this propagated to the Policy Configuration service and the LDAP authentication service that are already registered with the default organization.
    15. Log out of AM. Following the documentation, modify directory.host and directory.port in AMConfig.properties to point to Host 1_FQDN and 489 respectively. Make this change in AMConfig.properties of both Host 1 as well as 2.
    16. Edit serverconfig.xml on both hosts, and instead of they pointing to their local directory servers, point both to host1_FQDN:489
    17. When you start the webserver, it will refuse to start. Will spew errors such as:
    [https-host1_FQDN]: Sun ONE Web Server 6.1SP5 B06/23/2005 17:36
    [https-host1_FQDN]: info: CORE3016: daemon is running as super-user
    [https-host1_FQDN]: info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_04] from [Sun Microsystems Inc.]
    [https-host1_FQDN]: info: WEB0100: Loading web module in virtual server [https-host1_FQDN] at [amserver]
    [https-host1_FQDN]: warning: WEB6100: locale-charset-info is deprecated, please use parameter-encoding
    [https-host1_FQDN]: info: WEB0100: Loading web module in virtual server [https-host1_FQDN] at [ampassword]
    [https-host1_FQDN]: warning: WEB6100: locale-charset-info is deprecated, please use parameter-encoding
    [https-host1_FQDN]: info: WEB0100: Loading web module in virtual server [https-host1_FQDN] at [amcommon]
    [https-host1_FQDN]: info: WEB0100: Loading web module in virtual server [https-host1_FQDN] at [amconsole]
    [https-host1_FQDN]: warning: WEB6100: locale-charset-info is deprecated, please use parameter-encoding
    [https-host1_FQDN]: info: WEB0100: Loading web module in virtual server [https-host1_FQDN] at [search]
    [https-host1_FQDN]: warning: CORE3283: stderr: netscape.ldap.LDAPException: error result (32); matchedDN = dc=sun,dc=com; No such object (DN changed)
    [https-host1_FQDN]: warning: CORE3283: stderr: Got LDAPServiceException code=-1
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.services.ldap.DSConfigMgr.getConnection(DSConfigMgr.java:357)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.services.ldap.DSConfigMgr.getNewFailoverConnection(DSConfigMgr.java:314)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.services.ldap.DSConfigMgr.getNewConnection(DSConfigMgr.java:253)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.services.ldap.DSConfigMgr.getNewProxyConnection(DSConfigMgr.java:184)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.services.ldap.DSConfigMgr.getNewProxyConnection(DSConfigMgr.java:194)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.ums.DataLayer.initLdapPool(DataLayer.java:1248)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.ums.DataLayer.(DataLayer.java:190)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.ums.DataLayer.getInstance(DataLayer.java:215)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.ums.DataLayer.getInstance(DataLayer.java:246)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.sun.identity.sm.ldap.SMSLdapObject.initialize(SMSLdapObject.java:156)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.sun.identity.sm.ldap.SMSLdapObject.(SMSLdapObject.java:124)
    [https-host1_FQDN]: warning: CORE3283: stderr: at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    [https-host1_FQDN]: warning: CORE3283: stderr: at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
    [https-host1_FQDN]: warning: CORE3283: stderr: at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
    [https-host1_FQDN]: warning: CORE3283: stderr: at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
    [https-host1_FQDN]: warning: CORE3283: stderr: at java.lang.Class.newInstance0(Class.java:350)
    [https-host1_FQDN]: warning: CORE3283: stderr: at java.lang.Class.newInstance(Class.java:303)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.sun.identity.sm.SMSEntry.(SMSEntry.java:216)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.sun.identity.sm.ServiceSchemaManager.(ServiceSchemaManager.java:67)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.am.util.AMClientDetector.getServiceSchemaManager(AMClientDetector.java:219)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.am.util.AMClientDetector.(AMClientDetector.java:94)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.sun.mobile.filter.AMLController.init(AMLController.java:85)
    [https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:262)
    [https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:322)
    [https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:120)
    [https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3271)
    [https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.StandardContext.start(StandardContext.java:3747)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.ias.web.WebModule.start(WebModule.java:251)
    [https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1133)
    [https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.StandardHost.start(StandardHost.java:652)
    [https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1133)
    [https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:355)
    [https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.startup.Embedded.start(Embedded.java:995)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.ias.web.WebContainer.start(WebContainer.java:431)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.ias.web.WebContainer.startInstance(WebContainer.java:500)
    [https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.ias.server.J2EERunner.confPostInit(J2EERunner.java:161)
    [https-host1_FQDN]: failure: WebModule[amserver]: WEB2783: Servlet /amserver threw load() exception
    [https-host1_FQDN]: javax.servlet.ServletException: WEB2778: Servlet.init() for servlet LoginLogoutMapping threw exception
    [https-host1_FQDN]: at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:949)
    [https-host1_FQDN]: at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:813)
    [https-host1_FQDN]: at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3478)
    [https-host1_FQDN]: at org.apache.catalina.core.StandardContext.start(StandardContext.java:3760)
    [https-host1_FQDN]: at com.iplanet.ias.web.WebModule.start(WebModule.java:251)
    [https-host1_FQDN]: at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1133)
    [https-host1_FQDN]: at org.apache.catalina.core.StandardHost.start(StandardHost.java:652)
    [https-host1_FQDN]: at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1133)
    [https-host1_FQDN]: at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:355)
    [https-host1_FQDN]: at org.apache.catalina.startup.Embedded.start(Embedded.java:995)
    [https-host1_FQDN]: at com.iplanet.ias.web.WebContainer.start(WebContainer.java:431)
    [https-host1_FQDN]: at com.iplanet.ias.web.WebContainer.startInstance(WebContainer.java:500)
    [https-host1_FQDN]: at com.iplanet.ias.server.J2EERunner.confPostInit(J2EERunner.java:161)
    [https-host1_FQDN]: ----- Root Cause -----
    [https-host1_FQDN]: java.lang.NullPointerException
    [https-host1_FQDN]: at com.sun.identity.authentication.UI.LoginLogoutMapping.init(LoginLogoutMapping.java:71)
    [https-host1_FQDN]: at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:921)
    [https-host1_FQDN]: at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:813)
    [https-host1_FQDN]: at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3478)
    [https-host1_FQDN]: at org.apache.catalina.core.StandardContext.start(StandardContext.java:3760)
    [https-host1_FQDN]: at com.iplanet.ias.web.WebModule.start(WebModule.java:251)
    [https-host1_FQDN]: at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1133)
    [https-host1_FQDN]: at org.apache.catalina.core.StandardHost.start(StandardHost.java:652)
    [https-host1_FQDN]: at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1133)
    [https-host1_FQDN]: at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:355)
    [https-host1_FQDN]: at org.apache.catalina.startup.Embedded.start(Embedded.java:995)
    [https-host1_FQDN]: at com.iplanet.ias.web.WebContainer.start(WebContainer.java:431)
    [https-host1_FQDN]: at com.iplanet.ias.web.WebContainer.startInstance(WebContainer.java:500)
    [https-host1_FQDN]: at com.iplanet.ias.server.J2EERunner.confPostInit(J2EERunner.java:161)
    [https-host1_FQDN]:
    [https-host1_FQDN]: info: HTTP3072: [LS ls1] http://host1_FQDN:58080 [i]ready to accept requests
    [https-host1_FQDN]: startup: server started successfully
    Success!
    The server https-host1_FQDN has started up.
    The server infact, didn't start up (nothing even listening on 58080).
    However, if AMConfig.properties is left as it originally was, and only serverconfig.xml files were changed as mentioned above, web servers started fine, and things worked all okay. (Alright, except for some glitches when viewed in /amconsole. If /amserver/console is accessed, all is good. Can this mean that all is still not well? I am not sure).
    So far so good. Now comes the sad part. When the same is done on Solaris 9, things dont work. You continue to get the above error, OR the following error, and the web server will refuse to start:
    Differences in Solaris and Windows are as follows:
    1. Windows hosts have 1 IP and hostname. Solaris hosts have 3 IPs and hostnames (for DS, DPS, and webserver).
    No other difference from an architectural perspective.
    Any help / insight on why the above is not working (and why the hell does the documentation seem so sketchy / insecure / incorrect).
    Thanks a bunch!

  • Integrate other directory servers with access manager

    How to integrate other directory servers with access manager ?

    Please read the Access Manager admin guide at http://docs.sun.com/app/docs/doc/819-4670/6n6qardvq
    Any further questions regarding this integration, post them to the AM forum at http://forums.sun.com/forum.jspa?forumID=770

  • Is it possible to manage the servers with RSAT in a different domain?

    Hi All,
    In our infrastructure, all the servers are in the domain A. But as per the organization policy, laptops are only allowed to join domain B, not allowed to join domain A. Is there a way to manage the domain A services (DC/DNS/DHCP/etc) with RSAT on laptops?
    As of now I'm only able to use RDP to log on every server in domain A every time.
    P.S. As of now most of the servers are Windows Server 2008 R2, and most of the workstations are Windows 7. There will be some new servers with Windows Server 2012 and Windows Server 2012 R2 OS in the future.
    Thanks,
    高麻雀

    Hi,
    As far as I know, we could only manage a remote server using RSAT in the same domain.
    Best Regards,
    Andy Qi
    Andy Qi
    TechNet Community Support

  • Run Admin Server with multiple Managed Servers each using different userid?

    We currently run separate WebLogic domain instances for each business application in a Unix environment. Each one is created using a unix userid unique to that application and which owns all the files and is used to run the process when that particular WebLogic instance is started up. We have run this way for a while.
    I am considering altering our approach to the one that is recommended, i.e. in our Production environment we would run a single Admin instance with numerous managed servers. One issue I'm stuck on is the fact that in our current environment, each application has a different unix userid that owns the files making up the WebLogic domain instance and that WebLogic instance is run under that userid.
    I've investigated and experimented using WebLogic 10.3 preview and WebLogic 10.0, but I haven't been able to determine what I have to do to make each managed server's files and processes belong to a different unix userid, if that is even possible.
    Is there a way, using the recommended approach, where there is a single Admin instance that has multiple managed servers whose files and processes are owned by different unique, unix userids?
    If not, how would you separate access to each of the Managed Servers so that the programmers who maintain them don't have access to Managed Servers that they are not responsible for?
    Thanks for any help or suggestions.....

    Hi:
    I played with this stuff and I found that this will work, without the Location elements:
    <IfModule mod_weblogic.c>
    MatchExpression /app1 WebLogicHost=server1|WebLogicPort=7003
    MatchExpression /app2 WebLogicHost=server2|WebLogicPort=7003
    </IfModule>
    Also this will work too, with no entries inside the IfModule element:
    <Location /app1 >
    SetHandler weblogic-handler
    WebLogicHost server1
    WebLogicPort 7003
    </Location>
    <Location /app2 >
    SetHandler weblogic-handler
    WebLogicHost server2
    WebLogicPort 7003
    </Location>

  • Re: Precompiling JSP with admin/managed servers

    Thanks, but I'm not doing any copying.
              The admin/managed-server communication copies things to the managed server,
              which then always recompiles the pages when hit.
              -Greg
              Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              "Robert Coonrad" <[email protected]> wrote in message
              news:[email protected]...
              >
              > check out post 8366...i found that i was not preserving
              > the lastmodified date on my jsps and this was causing
              > unnecessary re-compilation.
              >
              > hope it helps...
              > bobc
              >
              > "Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote:
              > >I believe I have exhausted all permutations of EARing/notEARing,
              > >WARing/notWARing, placing precompiled jsp class files in WEB-INF/classes,
              > >placing them in a static location and setting workingDir to that
              location,
              > >combinations of the above.
              > >
              > >No matter what, the managed server re-compiles pages the first time they
              > >are
              > >hit. Non admin/managed-server I have no problems.
              > >
              > >Can anyone from BEA comment on this problem? Or give me a workaround
              > >for
              > >getting a cluster working with precompiled jsps?
              > >
              > >-Greg
              > >
              > >"Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote in message
              > >news:[email protected]...
              > >> Grrr... The JSP engine is extremely frustrating! I've spent many hours
              > >> fighting the "staleness" checker in WL. I've been through all of the
              > >> newsgroup messages pertaining to pre-compiling, etc., and I've gotten
              > >> pre-compilation working on single-server deployments, but admin/managed
              > >> server deployments have me beat.
              > >>
              > >> WL6.1, SP1, Solaris
              > >>
              > >> I've done the pageCheckSeconds=-1 and the workingDir is set to a fixed
              > >> place. The fixed place contains pre-compiled versions of all jsps
              > >made on
              > >> that machine using jspc not 20 minutes earlier using the JSP files
              > >in the
              > >> exploded EAR file used by the admin server as the model for managed
              > >> servers.. The managed servers are on the same machine.
              > >>
              > >> When the admin server gives an application to a managed server, the
              > >managed
              > >> server creates a temporary directory containing all of the webapp
              > >> components, etc. The file timestamps on these files is the set by
              > >the
              > >> copying process to the time of the managed server boot (why?!?!????!?),
              > >so
              > >> the staleness check always thinks they are new and could care less
              > >what
              > >> precompiled jsps I have in my workingDir, the WEB-INF/classes
              directory,
              > >or
              > >> anywhere else. The pageCheckSeconds=-1 seems to be completely ignored
              > >in
              > >> this scenario.
              > >>
              > >> If I tell the managed server to precompile everything on boot (about
              > >45
              > >> minutes for this app) it will create versions of the classes that match
              > >th
              > >e
              > >> new JSP file timestamps, but this does not even survive a reboot of
              > >the
              > >> managed server because it AGAIN creates a new temp version of
              everything
              > >on
              > >> the next reboot with new timestamps.
              > >>
              > >> If I wait for the managed server to boot and find the directory like
              > >> .../applications/.wlnotdelete_man1/wlap7336/webapp/... and physically
              > >copy
              > >> (via cp -pr to retain timestamps) all of the original webapp components
              > >on
              > >> top of the temp versions, the staleness checker is happy and the
              > >> pre-compiled versions work fine.
              > >>
              > >> There HAS to be a way to package pre-compiled versions of the JSPs
              > >in the
              > >> "model" application in the admin server and keep from having to
              precompile
              > >> the JSPs on every managed server every time managed server is booted..
              > >>
              > >> It would help if we had a way to bypass the staleness checking
              > >completely..
              > >> Or you guys should make the timestamps on the files copied by the
              > >> admin/managed deployment process match properly so the staleness
              checker
              > >> doesn't think the JSP is different.
              > >>
              > >> It would also help if the engineer who wrote this could explain the
              > >rules
              > >> being implemented by the staleness checker. So far all the messages
              > >in
              > >the
              > >> newsgroup have amounted to point solutions for problems without a good
              > >> understanding of what the engine is checking for and/or doing under
              > >the
              > >> covers. Looking at the generated .java files for the JSP pages helps,
              > >but
              > >> it is not good enough...
              > >>
              > >> Anyone out there have a working admin/managed server JSP application?
              > >> -Greg
              > >>
              > >> -----------------------------------------------------------
              > >> Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              > >> www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              > >>
              > >>
              > >>
              > >
              > >
              >
              

    The admin/managed-server communication copies things to the managed server, which then always recompiles the pages when hit.
              This is a known issue and is fixed. The timestamps of the compiled classes was not being preserved when extracted from the war file used to distribute to the managed servers. This will be available in WLS6.1 Service Pack 3 - and there is a temporary patch available for SP2. Please ask your friendly BEA support person for it (you can refer to CR058946)
              I'd give you the patch myself, but they like to keep track of these things...
              Regards,
              Alex
              "Girish" <[email protected]> wrote in message news:[email protected]...
              >
              > "Aditya Kiran Gavvala" <[email protected]> wrote:
              > >Greg,
              > >
              > >I have been following your posts, because our application deployment
              > >ran
              > >into exact same problem you ran into. I had spent a full two days
              > >researching into the problem. And I figured the solution. Hope this
              > >helps.
              > >
              > >Here are my discoveries:
              > >
              > >The following applies only to the following environment:
              > >OS: Linux (perhaps for Win/Unix/Solaris etc)
              > >WLS 6.0 SP2 ( no rolling patches): I found Rolling Patch2 (RP2) not useful
              > >for this problem.
              > >Clustered environment with Admin/Managed servers
              > >
              > >- When you compile JSP using weblogic.jspc compiler it puts the JSP file
              > >timestamp into the compiled class. You can see it in the generated java
              > >file
              > >(you need to supply -keepgenerated switch to jspc)
              > >
              > >- When a request is made to a JSP page after the application is deployed,
              > >it
              > >seems to be retrieving this timestamp from the compiled class file and
              > >comparing it with the JSP file timestamp. If they dont match a compile
              > >command gets run by the server. Thereby you see a compile happening at
              > >run
              > >time.
              > >
              > >- If you have exploded directory deployment, when you start the managed
              > >servers they create a ".war" file (under some temp dir) with all the
              > >JSP
              > >source files going into the file. You can notice this by looking into
              > >the
              > >server log file. Therefore all JSP source files get a brand new timestamp
              > >in
              > >the archive (a timestamp later than what was put class files by
              > >weblogic.jspc). So, the server at run time sees that the timestamp in
              > >the
              > >class file is older than the JSP source file and runs a recompile. So
              > >DONT
              > >DO EXPLODED directory deployment if your environment is as described
              > >in this
              > >post.
              > >
              > >- If you have ".war" file deployment, you will not have a problem. At
              > >the
              > >start up time managed server still creates "".war" file under a temp
              > >directory however it seems to be copying the content of the your ".war"
              > >file. So, the timestamps of JSP remain the same as they were before.
              > >SO NO
              > >RE-COMPILATION.
              > >
              > >- Another important thing to remember is to make sure you specify the
              > >workingDir in the weblogic.xml file. That is where the precompiled class
              > >files should reside. This should be any directory the server uses as
              > >scratch
              > >pad to compile classes or find (pre)compiled classes. This is not a
              > >directory inside your .war file is what I am trying to get at.
              > >
              > >Hope this helps,
              > >Aditya
              > >
              > >"Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote in message
              > >news:[email protected]...
              > >> Thanks, but I'm not doing any copying.
              > >>
              > >> The admin/managed-server communication copies things to the managed
              > >server,
              > >> which then always recompiles the pages when hit.
              > >>
              > >> -Greg
              > >>
              > >> -----------------------------------------------------------
              > >> Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              > >> www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              > >>
              > >> "Robert Coonrad" <[email protected]> wrote in message
              > >> news:[email protected]...
              > >> >
              > >> > check out post 8366...i found that i was not preserving
              > >> > the lastmodified date on my jsps and this was causing
              > >> > unnecessary re-compilation.
              > >> >
              > >> > hope it helps...
              > >> > bobc
              > >> >
              > >> > "Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote:
              > >> > >I believe I have exhausted all permutations of EARing/notEARing,
              > >> > >WARing/notWARing, placing precompiled jsp class files in
              > >WEB-INF/classes,
              > >> > >placing them in a static location and setting workingDir to that
              > >> location,
              > >> > >combinations of the above.
              > >> > >
              > >> > >No matter what, the managed server re-compiles pages the first time
              > >they
              > >> > >are
              > >> > >hit. Non admin/managed-server I have no problems.
              > >> > >
              > >> > >Can anyone from BEA comment on this problem? Or give me a workaround
              > >> > >for
              > >> > >getting a cluster working with precompiled jsps?
              > >> > >
              > >> > >-Greg
              > >> > >
              > >> > >"Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote in message
              > >> > >news:[email protected]...
              > >> > >> Grrr... The JSP engine is extremely frustrating! I've spent many
              > >hours
              > >> > >> fighting the "staleness" checker in WL. I've been through all
              > >of the
              > >> > >> newsgroup messages pertaining to pre-compiling, etc., and I've
              > >gotten
              > >> > >> pre-compilation working on single-server deployments, but
              > >admin/managed
              > >> > >> server deployments have me beat.
              > >> > >>
              > >> > >> WL6.1, SP1, Solaris
              > >> > >>
              > >> > >> I've done the pageCheckSeconds=-1 and the workingDir is set to
              > >a
              > >fixed
              > >> > >> place. The fixed place contains pre-compiled versions of all
              > >jsps
              > >> > >made on
              > >> > >> that machine using jspc not 20 minutes earlier using the JSP files
              > >> > >in the
              > >> > >> exploded EAR file used by the admin server as the model for managed
              > >> > >> servers.. The managed servers are on the same machine.
              > >> > >>
              > >> > >> When the admin server gives an application to a managed server,
              > >the
              > >> > >managed
              > >> > >> server creates a temporary directory containing all of the webapp
              > >> > >> components, etc. The file timestamps on these files is the set
              > >by
              > >> > >the
              > >> > >> copying process to the time of the managed server boot
              > >(why?!?!????!?),
              > >> > >so
              > >> > >> the staleness check always thinks they are new and could care
              > >less
              > >> > >what
              > >> > >> precompiled jsps I have in my workingDir, the WEB-INF/classes
              > >> directory,
              > >> > >or
              > >> > >> anywhere else. The pageCheckSeconds=-1 seems to be completely
              > >ignored
              > >> > >in
              > >> > >> this scenario.
              > >> > >>
              > >> > >> If I tell the managed server to precompile everything on boot
              > >(about
              > >> > >45
              > >> > >> minutes for this app) it will create versions of the classes that
              > >match
              > >> > >th
              > >> > >e
              > >> > >> new JSP file timestamps, but this does not even survive a reboot
              > >of
              > >> > >the
              > >> > >> managed server because it AGAIN creates a new temp version of
              > >> everything
              > >> > >on
              > >> > >> the next reboot with new timestamps.
              > >> > >>
              > >> > >> If I wait for the managed server to boot and find the directory
              > >like
              > >> > >> .../applications/.wlnotdelete_man1/wlap7336/webapp/... and physically
              > >> > >copy
              > >> > >> (via cp -pr to retain timestamps) all of the original webapp
              > >components
              > >> > >on
              > >> > >> top of the temp versions, the staleness checker is happy and the
              > >> > >> pre-compiled versions work fine.
              > >> > >>
              > >> > >> There HAS to be a way to package pre-compiled versions of the
              > >JSPs
              > >> > >in the
              > >> > >> "model" application in the admin server and keep from having to
              > >> precompile
              > >> > >> the JSPs on every managed server every time managed server is
              > >booted..
              > >> > >>
              > >> > >> It would help if we had a way to bypass the staleness checking
              > >> > >completely..
              > >> > >> Or you guys should make the timestamps on the files copied by
              > >the
              > >> > >> admin/managed deployment process match properly so the staleness
              > >> checker
              > >> > >> doesn't think the JSP is different.
              > >> > >>
              > >> > >> It would also help if the engineer who wrote this could explain
              > >the
              > >> > >rules
              > >> > >> being implemented by the staleness checker. So far all the messages
              > >> > >in
              > >> > >the
              > >> > >> newsgroup have amounted to point solutions for problems without
              > >a
              > >good
              > >> > >> understanding of what the engine is checking for and/or doing
              > >under
              > >> > >the
              > >> > >> covers. Looking at the generated .java files for the JSP pages
              > >helps,
              > >> > >but
              > >> > >> it is not good enough...
              > >> > >>
              > >> > >> Anyone out there have a working admin/managed server JSP application?
              > >> > >> -Greg
              > >> > >>
              > >> > >> -----------------------------------------------------------
              > >> > >> Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              > >> > >> www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              > >> > >>
              > >> > >>
              > >> > >>
              > >> > >
              > >> > >
              > >> >
              > >>
              > >>
              > >
              > >
              >
              [att1.html]
              

  • Precompiling JSP with admin/managed servers

    Grrr... The JSP engine is extremely frustrating! I've spent many hours
              fighting the "staleness" checker in WL. I've been through all of the
              newsgroup messages pertaining to pre-compiling, etc., and I've gotten
              pre-compilation working on single-server deployments, but admin/managed
              server deployments have me beat.
              WL6.1, SP1, Solaris
              I've done the pageCheckSeconds=-1 and the workingDir is set to a fixed
              place. The fixed place contains pre-compiled versions of all jsps made on
              that machine using jspc not 20 minutes earlier using the JSP files in the
              exploded EAR file used by the admin server as the model for managed
              servers.. The managed servers are on the same machine.
              When the admin server gives an application to a managed server, the managed
              server creates a temporary directory containing all of the webapp
              components, etc. The file timestamps on these files is the set by the
              copying process to the time of the managed server boot (why?!?!????!?), so
              the staleness check always thinks they are new and could care less what
              precompiled jsps I have in my workingDir, the WEB-INF/classes directory, or
              anywhere else. The pageCheckSeconds=-1 seems to be completely ignored in
              this scenario.
              If I tell the managed server to precompile everything on boot (about 45
              minutes for this app) it will create versions of the classes that match the
              new JSP file timestamps, but this does not even survive a reboot of the
              managed server because it AGAIN creates a new temp version of everything on
              the next reboot with new timestamps.
              If I wait for the managed server to boot and find the directory like
              .../applications/.wlnotdelete_man1/wlap7336/webapp/... and physically copy
              (via cp -pr to retain timestamps) all of the original webapp components on
              top of the temp versions, the staleness checker is happy and the
              pre-compiled versions work fine.
              There HAS to be a way to package pre-compiled versions of the JSPs in the
              "model" application in the admin server and keep from having to precompile
              the JSPs on every managed server every time managed server is booted..
              It would help if we had a way to bypass the staleness checking completely..
              Or you guys should make the timestamps on the files copied by the
              admin/managed deployment process match properly so the staleness checker
              doesn't think the JSP is different.
              It would also help if the engineer who wrote this could explain the rules
              being implemented by the staleness checker. So far all the messages in the
              newsgroup have amounted to point solutions for problems without a good
              understanding of what the engine is checking for and/or doing under the
              covers. Looking at the generated .java files for the JSP pages helps, but
              it is not good enough...
              Anyone out there have a working admin/managed server JSP application?
              -Greg
              Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              

              check out post 8366...i found that i was not preserving
              the lastmodified date on my jsps and this was causing
              unnecessary re-compilation.
              hope it helps...
              bobc
              "Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote:
              >I believe I have exhausted all permutations of EARing/notEARing,
              >WARing/notWARing, placing precompiled jsp class files in WEB-INF/classes,
              >placing them in a static location and setting workingDir to that location,
              >combinations of the above.
              >
              >No matter what, the managed server re-compiles pages the first time they
              >are
              >hit. Non admin/managed-server I have no problems.
              >
              >Can anyone from BEA comment on this problem? Or give me a workaround
              >for
              >getting a cluster working with precompiled jsps?
              >
              >-Greg
              >
              >"Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote in message
              >news:[email protected]...
              >> Grrr... The JSP engine is extremely frustrating! I've spent many hours
              >> fighting the "staleness" checker in WL. I've been through all of the
              >> newsgroup messages pertaining to pre-compiling, etc., and I've gotten
              >> pre-compilation working on single-server deployments, but admin/managed
              >> server deployments have me beat.
              >>
              >> WL6.1, SP1, Solaris
              >>
              >> I've done the pageCheckSeconds=-1 and the workingDir is set to a fixed
              >> place. The fixed place contains pre-compiled versions of all jsps
              >made on
              >> that machine using jspc not 20 minutes earlier using the JSP files
              >in the
              >> exploded EAR file used by the admin server as the model for managed
              >> servers.. The managed servers are on the same machine.
              >>
              >> When the admin server gives an application to a managed server, the
              >managed
              >> server creates a temporary directory containing all of the webapp
              >> components, etc. The file timestamps on these files is the set by
              >the
              >> copying process to the time of the managed server boot (why?!?!????!?),
              >so
              >> the staleness check always thinks they are new and could care less
              >what
              >> precompiled jsps I have in my workingDir, the WEB-INF/classes directory,
              >or
              >> anywhere else. The pageCheckSeconds=-1 seems to be completely ignored
              >in
              >> this scenario.
              >>
              >> If I tell the managed server to precompile everything on boot (about
              >45
              >> minutes for this app) it will create versions of the classes that match
              >th
              >e
              >> new JSP file timestamps, but this does not even survive a reboot of
              >the
              >> managed server because it AGAIN creates a new temp version of everything
              >on
              >> the next reboot with new timestamps.
              >>
              >> If I wait for the managed server to boot and find the directory like
              >> .../applications/.wlnotdelete_man1/wlap7336/webapp/... and physically
              >copy
              >> (via cp -pr to retain timestamps) all of the original webapp components
              >on
              >> top of the temp versions, the staleness checker is happy and the
              >> pre-compiled versions work fine.
              >>
              >> There HAS to be a way to package pre-compiled versions of the JSPs
              >in the
              >> "model" application in the admin server and keep from having to precompile
              >> the JSPs on every managed server every time managed server is booted..
              >>
              >> It would help if we had a way to bypass the staleness checking
              >completely..
              >> Or you guys should make the timestamps on the files copied by the
              >> admin/managed deployment process match properly so the staleness checker
              >> doesn't think the JSP is different.
              >>
              >> It would also help if the engineer who wrote this could explain the
              >rules
              >> being implemented by the staleness checker. So far all the messages
              >in
              >the
              >> newsgroup have amounted to point solutions for problems without a good
              >> understanding of what the engine is checking for and/or doing under
              >the
              >> covers. Looking at the generated .java files for the JSP pages helps,
              >but
              >> it is not good enough...
              >>
              >> Anyone out there have a working admin/managed server JSP application?
              >> -Greg
              >>
              >> -----------------------------------------------------------
              >> Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              >> www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              >>
              >>
              >>
              >
              >
              

  • JMS with managed servers

    I have created two independent server instances, each with their own applications directory, config.xml file, etc. Now I want them to be able to use JMS to communicate with each other. It is my impression that there are a couple of ways to do this, the easiest of these being to add the server instances as managed servers to the same administration server so they exist in the same domain, then set up a single JMS configuration for that domain. Is this right?
              If so, how do I set the administration server for an independent server instance? Must I also explicitly change its domain to match that of the administration server?
              Or is this not possible and I need to use a messaging bridge?
              Thanks in advance.
              David

    Hi David,
              I'm not sure, but I don't think you can set up an admin server for an "independent server instance". I think all servers in the domain are either a "managed server", or an "admin server", where managed servers get their configuration from the admin server. Regardless, with the "domain" approach, I assume you are leaning towards going a bit further and configuring a cluster, which would automatically allow any app on any server within the cluster to transparently lookup any resource in the cluster in the global JNDI context. All of this information is in the general documentation (not the JMS documentation).
              I think there are pluses and minuses to either approach you mention. For simplicity, if you don't need clustering features, you might simply want to try the "interop" approach and see if its good enough for your purposes, rather than going through the trouble of setting up an admin server and a cluster:
              http://e-docs.bea.com/wls/docs81/faq/interop.html
              In this approach, cross-communication always involves references the remote server's URL at some point, but this URL might be specified via configuration (MDB, bridge, SAF, foreign dest all provide ability to specify a URL).
              Hope this helps,
              Tom

  • Problem with discovering Managed Servers

    Hi,
    I got problem with discovering managed servers, when I restart only administration
    server while managed servers are running. During restart of admin server everything
    seems to be ok (the directive: Starting discovery of managed server... appears
    on the screen).
    However when I start admin console through http, I cannot monitor performance,
    browse logs etc. I can only shutdown managed server and I can see in a server
    tag that particular managed servers are running.
    I'm looking forward for any clues
    Michal

    Sorry,
    i cannot stop those managed server - in Control tab I have active only option
    to start those server but they are running. In logging tab when I want to browse
    the log the message that probably this server is not running appear. However in
    the tab when all servers are listened there is a message that they are running
    "Michal" <[email protected]> wrote:
    >
    Hi,
    I got problem with discovering managed servers, when I restart only administration
    server while managed servers are running. During restart of admin server
    everything
    seems to be ok (the directive: Starting discovery of managed server...
    appears
    on the screen).
    However when I start admin console through http, I cannot monitor performance,
    browse logs etc. I can only shutdown managed server and I can see in
    a server
    tag that particular managed servers are running.
    I'm looking forward for any clues
    Michal

  • Creating Weblogic domain with Admin Server and managed servers on different

    I am trying to create Weblogic domain where Admin Server and managed servers on different machines. However I am unable to find any steps which would allow me to do so. The config.sh script always creates an Admin Server. Please help.

    Whilst the method that Lawrence gives can result in a domain that is perfectly functional, it is a method that can result in errors as you are having to enter the same information twice. Also you will create two admin servers, as the second domain creation will have the console added to it on the renamed admin server and this will give issues.
    The best method to create a domain spamming multiple physical machines, is to create the domain with all the components on the first machine. This means planning the domain and making sure all components are added once; so having the information about the domain written out is wise. Ensure that the WLS software is installed in the same path on each machine before starting.
    Then copy the domain that you have created from one machine to the other, keeping the same paths. You can simply copy (I've used this method multiple times without issue) but the supported way would be to use the WLST PACK and UNPACK methods. These create and extract domains from templates. Some more information on these is given here -> http://docs.oracle.com/cd/E13179_01/common/docs100/pack/intro.html#wp1069056

  • Problems with deploying file to one of the managed servers on a cluster

    We are running Weblogic 10.3.
    When I start both managed servers from the Admin Console, one fails with the error below and in Admin state, but the other managed server starts up correctly.
    The only difference from when it was first working is that the managed server ServerBox1 was imaged and loaded onto new hardware and all network/os properties configured the same as the old box.
    ####<Timestamp> <Info> <Deployer> <box1> <ServerBox1> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1333048292425> <BEA-149059> <Module DocFile.war of application DocFile is transitioning from STATE_NEW to STATE_PREPARED on server ServerBox1.>
    ####<Mar 29, 2012 3:11:32 PM EDT> <Error> <HTTP> <box1> <ServerBox1> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1333048292488> <BEA-101064> <[WebAppModule(DocFile:DocFile.war)] Error parsing descriptor in Web appplication "/domainPath/servers/ServerBox1/stage/DocFile/DocFile.war"
    java.lang.NullPointerException
           at com.bea.xbean.regex.RangeToken.match(RangeToken.java:485)
           at com.bea.xbean.regex.RegularExpression.matchString(RegularExpression.java:1673)
           at com.bea.xbean.regex.RegularExpression.matches(RegularExpression.java:1432)
           at com.bea.xbean.regex.RegularExpression.matches(RegularExpression.java:1370)
           at com.bea.xbean.schema.SchemaTypeImpl.matchPatternFacet(SchemaTypeImpl.java:1362)
           at com.bea.xbean.values.JavaDecimalHolderEx.validateLexical(JavaDecimalHolderEx.java:71)
           at com.bea.xbean.validator.Validator.validateAtomicType(Validator.java:1296)
           at com.bea.xbean.validator.Validator.validateSimpleType(Validator.java:1259)
           at com.bea.xbean.validator.Validator.validateSimpleType(Validator.java:1195)
           at com.bea.xbean.validator.Validator.handleText(Validator.java:835)
           at com.bea.xbean.validator.Validator.textEvent(Validator.java:820)
           at com.bea.xbean.validator.Validator.nextEvent(Validator.java:250)
           at com.bea.xbean.validator.ValidatingXMLStreamReader.validate_event(ValidatingXMLStreamReader.java:654)
           at com.bea.xbean.validator.ValidatingXMLStreamReader.next(ValidatingXMLStreamReader.java:544)
           at com.bea.xbean.richParser.XMLStreamReaderExtImpl.next(XMLStreamReaderExtImpl.java:1122)
           at com.bea.xbean.richParser.XMLStreamReaderExtImpl$CharSeqTrimWS.fillBuffer(XMLStreamReaderExtImpl.java:804)
           at com.bea.xbean.richParser.XMLStreamReaderExtImpl$CharSeqTrimWS.reload(XMLStreamReaderExtImpl.java:755)
           at com.bea.xbean.richParser.XMLStreamReaderExtImpl.getBigIntegerValue(XMLStreamReaderExtImpl.java:155)
           at com.bea.staxb.runtime.internal.UnmarshalResult.getBigIntegerValue(UnmarshalResult.java:467)
           at com.bea.staxb.runtime.internal.IntegerToIntTypeConverter.getObject(IntegerToIntTypeConverter.java:34)
           at com.bea.staxb.runtime.internal.BaseSimpleTypeConverter.unmarshal(BaseSimpleTypeConverter.java:39)
           at com.bea.staxb.runtime.internal.LiteralUnmarshalResult.unmarshalElementProperty(LiteralUnmarshalResult.java:167)
           at com.bea.staxb.runtime.internal.LiteralUnmarshalResult.extractAndFillElementProp(LiteralUnmarshalResult.java:136)
           at com.bea.staxb.runtime.internal.ByNameUnmarshaller.deserializeContents(ByNameUnmarshaller.java:51)
           at com.bea.staxb.runtime.internal.AttributeUnmarshaller.unmarshalIntoIntermediary(AttributeUnmarshaller.java:47)
           at com.bea.staxb.runtime.internal.LiteralUnmarshalResult.unmarshalElementProperty(LiteralUnmarshalResult.java:164)
           at com.bea.staxb.runtime.internal.LiteralUnmarshalResult.extractAndFillElementProp(LiteralUnmarshalResult.java:136)
           at com.bea.staxb.runtime.internal.ByNameUnmarshaller.deserializeContents(ByNameUnmarshaller.java:51)
           at com.bea.staxb.runtime.internal.AttributeUnmarshaller.unmarshalIntoIntermediary(AttributeUnmarshaller.java:47)
           at com.bea.staxb.runtime.internal.UnmarshalResult.unmarshalBindingType(UnmarshalResult.java:189)
           at com.bea.staxb.runtime.internal.UnmarshalResult.unmarshalDocument(UnmarshalResult.java:159)
           at com.bea.staxb.runtime.internal.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:65)
           at weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(MarshallerFactory.java:141)
           at weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescriptorManager.java:306)
           at weblogic.application.descriptor.AbstractDescriptorLoader2.getDescriptorBeanFromReader(AbstractDescriptorLoader2.java:788)
           at weblogic.application.descriptor.AbstractDescriptorLoader2.createDescriptorBean(AbstractDescriptorLoader2.java:409)
           at weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescriptorBeanWithoutPlan(AbstractDescriptorLoader2.java:759)
           at weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescriptorBean(AbstractDescriptorLoader2.java:768)
           at weblogic.servlet.internal.WebAppDescriptor.getWebAppBean(WebAppDescriptor.java:141)
           at weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.java:1193)
           at weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:350)
           at weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedModuleDriver.java:176)
           at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:93)
           at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:387)
           at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
           at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:58)
           at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:42)
           at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:615)
           at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
           at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:191)
           at weblogic.application.internal.SingleModuleDeployment.prepare(SingleModuleDeployment.java:16)
           at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:155)
           at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60)
           at weblogic.deploy.internal.targetserver.AppDeployment.prepare(AppDeployment.java:141)
           at weblogic.management.deploy.internal.DeploymentAdapter$1.doPrepare(DeploymentAdapter.java:39)
           at weblogic.management.deploy.internal.DeploymentAdapter.prepare(DeploymentAdapter.java:187)
           at weblogic.management.deploy.internal.AppTransition$1.transitionApp(AppTransition.java:21)
           at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:233)
           at weblogic.management.deploy.internal.ConfiguredDeployments.prepare(ConfiguredDeployments.java:165)
           at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:122)
           at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:173)
           at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:89)
           at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
           at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
           at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
    >
    ####<Timestamp> <Info> <Deployer> <box1> <ServerBox1> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1333048292506> <BEA-149061> <Module DocFile.war of application DocFile failed to transition from STATE_NEW to STATE_PREPARED on server ServerBox1.>
    ####<Mar 29, 2012 3:11:32 PM EDT> <Error> <Deployer> <box1> <ServerBox1> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1333048292727> <BEA-149205> <Failed to initialize the application 'DocFile' due to error weblogic.application.ModuleException: [HTTP:101064][WebAppModule(DocFile:DocFile.war)] Error parsing descriptor in Web appplication "/domainPath/servers/ServerBox1/stage/DocFile/DocFile.war"
    java.lang.NullPointerException
           at com.bea.xbean.regex.RangeToken.match(RangeToken.java:485)
           at com.bea.xbean.regex.RegularExpression.matchString(RegularExpression.java:1673)
           at com.bea.xbean.regex.RegularExpression.matches(RegularExpression.java:1432)
           at com.bea.xbean.regex.RegularExpression.matches(RegularExpression.java:1370)
           at com.bea.xbean.schema.SchemaTypeImpl.matchPatternFacet(SchemaTypeImpl.java:1362)
           at com.bea.xbean.values.JavaDecimalHolderEx.validateLexical(JavaDecimalHolderEx.java:71)
           at com.bea.xbean.validator.Validator.validateAtomicType(Validator.java:1296)
           at com.bea.xbean.validator.Validator.validateSimpleType(Validator.java:1259)
           at com.bea.xbean.validator.Validator.validateSimpleType(Validator.java:1195)
           at com.bea.xbean.validator.Validator.handleText(Validator.java:835)
           at com.bea.xbean.validator.Validator.textEvent(Validator.java:820)
           at com.bea.xbean.validator.Validator.nextEvent(Validator.java:250)
           at com.bea.xbean.validator.ValidatingXMLStreamReader.validate_event(ValidatingXMLStreamReader.java:654)
           at com.bea.xbean.validator.ValidatingXMLStreamReader.next(ValidatingXMLStreamReader.java:544)
           at com.bea.xbean.richParser.XMLStreamReaderExtImpl.next(XMLStreamReaderExtImpl.java:1122)
           at com.bea.xbean.richParser.XMLStreamReaderExtImpl$CharSeqTrimWS.fillBuffer(XMLStreamReaderExtImpl.java:804)
           at com.bea.xbean.richParser.XMLStreamReaderExtImpl$CharSeqTrimWS.reload(XMLStreamReaderExtImpl.java:755)
           at com.bea.xbean.richParser.XMLStreamReaderExtImpl.getBigIntegerValue(XMLStreamReaderExtImpl.java:155)
           at com.bea.staxb.runtime.internal.UnmarshalResult.getBigIntegerValue(UnmarshalResult.java:467)
           at com.bea.staxb.runtime.internal.IntegerToIntTypeConverter.getObject(IntegerToIntTypeConverter.java:34)
           at com.bea.staxb.runtime.internal.BaseSimpleTypeConverter.unmarshal(BaseSimpleTypeConverter.java:39)
           at com.bea.staxb.runtime.internal.LiteralUnmarshalResult.unmarshalElementProperty(LiteralUnmarshalResult.java:167)
           at com.bea.staxb.runtime.internal.LiteralUnmarshalResult.extractAndFillElementProp(LiteralUnmarshalResult.java:136)
           at com.bea.staxb.runtime.internal.ByNameUnmarshaller.deserializeContents(ByNameUnmarshaller.java:51)
           at com.bea.staxb.runtime.internal.AttributeUnmarshaller.unmarshalIntoIntermediary(AttributeUnmarshaller.java:47)
           at com.bea.staxb.runtime.internal.LiteralUnmarshalResult.unmarshalElementProperty(LiteralUnmarshalResult.java:164)
           at com.bea.staxb.runtime.internal.LiteralUnmarshalResult.extractAndFillElementProp(LiteralUnmarshalResult.java:136)
           at com.bea.staxb.runtime.internal.ByNameUnmarshaller.deserializeContents(ByNameUnmarshaller.java:51)
           at com.bea.staxb.runtime.internal.AttributeUnmarshaller.unmarshalIntoIntermediary(AttributeUnmarshaller.java:47)
           at com.bea.staxb.runtime.internal.UnmarshalResult.unmarshalBindingType(UnmarshalResult.java:189)
           at com.bea.staxb.runtime.internal.UnmarshalResult.unmarshalDocument(UnmarshalResult.java:159)
           at com.bea.staxb.runtime.internal.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:65)
           at weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(MarshallerFactory.java:141)
           at weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescriptorManager.java:306)
           at weblogic.application.descriptor.AbstractDescriptorLoader2.getDescriptorBeanFromReader(AbstractDescriptorLoader2.java:788)
           at weblogic.application.descriptor.AbstractDescriptorLoader2.createDescriptorBean(AbstractDescriptorLoader2.java:409)
           at weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescriptorBeanWithoutPlan(AbstractDescriptorLoader2.java:759)
           at weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescriptorBean(AbstractDescriptorLoader2.java:768)
           at weblogic.servlet.internal.WebAppDescriptor.getWebAppBean(WebAppDescriptor.java:141)
           at weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.java:1193)
           at weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:350)
           at weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedModuleDriver.java:176)
           at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:93)
           at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:387)
           at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
           at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:58)
           at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:42)
           at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:615)
           at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
           at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:191)
           at weblogic.application.internal.SingleModuleDeployment.prepare(SingleModuleDeployment.java:16)
           at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:155)
           at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60)
           at weblogic.deploy.internal.targetserver.AppDeployment.prepare(AppDeployment.java:141)
           at weblogic.management.deploy.internal.DeploymentAdapter$1.doPrepare(DeploymentAdapter.java:39)
           at weblogic.management.deploy.internal.DeploymentAdapter.prepare(DeploymentAdapter.java:187)
           at weblogic.management.deploy.internal.AppTransition$1.transitionApp(AppTransition.java:21)
           at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:233)
           at weblogic.management.deploy.internal.ConfiguredDeployments.prepare(ConfiguredDeployments.java:165)
           at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:122)
           at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:173)
           at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:89)
           at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
           at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
           at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
    null.
    weblogic.application.ModuleException: [HTTP:101064][WebAppModule(DocFile:DocFile.war)] Error parsing descriptor in Web appplication "/domainPath/servers/ServerBox1/stage/DocFile/DocFile.war"
    java.lang.NullPointerException
           at com.bea.xbean.regex.RangeToken.match(RangeToken.java:485)
           at com.bea.xbean.regex.RegularExpression.matchString(RegularExpression.java:1673)
           at com.bea.xbean.regex.RegularExpression.matches(RegularExpression.java:1432)
           at com.bea.xbean.regex.RegularExpression.matches(RegularExpression.java:1370)
           at com.bea.xbean.schema.SchemaTypeImpl.matchPatternFacet(SchemaTypeImpl.java:1362)
           at com.bea.xbean.values.JavaDecimalHolderEx.validateLexical(JavaDecimalHolderEx.java:71)
           at com.bea.xbean.validator.Validator.validateAtomicType(Validator.java:1296)
           at com.bea.xbean.validator.Validator.validateSimpleType(Validator.java:1259)
           at com.bea.xbean.validator.Validator.validateSimpleType(Validator.java:1195)
           at com.bea.xbean.validator.Validator.handleText(Validator.java:835)
           at com.bea.xbean.validator.Validator.textEvent(Validator.java:820)
           at com.bea.xbean.validator.Validator.nextEvent(Validator.java:250)
           at com.bea.xbean.validator.ValidatingXMLStreamReader.validate_event(ValidatingXMLStreamReader.java:654)
           at com.bea.xbean.validator.ValidatingXMLStreamReader.next(ValidatingXMLStreamReader.java:544)
           at com.bea.xbean.richParser.XMLStreamReaderExtImpl.next(XMLStreamReaderExtImpl.java:1122)
           at com.bea.xbean.richParser.XMLStreamReaderExtImpl$CharSeqTrimWS.fillBuffer(XMLStreamReaderExtImpl.java:804)
           at com.bea.xbean.richParser.XMLStreamReaderExtImpl$CharSeqTrimWS.reload(XMLStreamReaderExtImpl.java:755)
           at com.bea.xbean.richParser.XMLStreamReaderExtImpl.getBigIntegerValue(XMLStreamReaderExtImpl.java:155)
           at com.bea.staxb.runtime.internal.UnmarshalResult.getBigIntegerValue(UnmarshalResult.java:467)
           at com.bea.staxb.runtime.internal.IntegerToIntTypeConverter.getObject(IntegerToIntTypeConverter.java:34)
           at com.bea.staxb.runtime.internal.BaseSimpleTypeConverter.unmarshal(BaseSimpleTypeConverter.java:39)
           at com.bea.staxb.runtime.internal.LiteralUnmarshalResult.unmarshalElementProperty(LiteralUnmarshalResult.java:167)
           at com.bea.staxb.runtime.internal.LiteralUnmarshalResult.extractAndFillElementProp(LiteralUnmarshalResult.java:136)
           at com.bea.staxb.runtime.internal.ByNameUnmarshaller.deserializeContents(ByNameUnmarshaller.java:51)
           at com.bea.staxb.runtime.internal.AttributeUnmarshaller.unmarshalIntoIntermediary(AttributeUnmarshaller.java:47)
           at com.bea.staxb.runtime.internal.LiteralUnmarshalResult.unmarshalElementProperty(LiteralUnmarshalResult.java:164)
           at com.bea.staxb.runtime.internal.LiteralUnmarshalResult.extractAndFillElementProp(LiteralUnmarshalResult.java:136)
           at com.bea.staxb.runtime.internal.ByNameUnmarshaller.deserializeContents(ByNameUnmarshaller.java:51)
           at com.bea.staxb.runtime.internal.AttributeUnmarshaller.unmarshalIntoIntermediary(AttributeUnmarshaller.java:47)
           at com.bea.staxb.runtime.internal.UnmarshalResult.unmarshalBindingType(UnmarshalResult.java:189)
           at com.bea.staxb.runtime.internal.UnmarshalResult.unmarshalDocument(UnmarshalResult.java:159)
           at com.bea.staxb.runtime.internal.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:65)
           at weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(MarshallerFactory.java:141)
           at weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescriptorManager.java:306)
           at weblogic.application.descriptor.AbstractDescriptorLoader2.getDescriptorBeanFromReader(AbstractDescriptorLoader2.java:788)
           at weblogic.application.descriptor.AbstractDescriptorLoader2.createDescriptorBean(AbstractDescriptorLoader2.java:409)
           at weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescriptorBeanWithoutPlan(AbstractDescriptorLoader2.java:759)
           at weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescriptorBean(AbstractDescriptorLoader2.java:768)
           at weblogic.servlet.internal.WebAppDescriptor.getWebAppBean(WebAppDescriptor.java:141)
           at weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.java:1193)
           at weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:350)
           at weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedModuleDriver.java:176)
           at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:93)
           at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:387)
           at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
           at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:58)
           at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:42)
           at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:615)
           at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
           at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:191)
           at weblogic.application.internal.SingleModuleDeployment.prepare(SingleModuleDeployment.java:16)
           at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:155)
           at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60)
           at weblogic.deploy.internal.targetserver.AppDeployment.prepare(AppDeployment.java:141)
           at weblogic.management.deploy.internal.DeploymentAdapter$1.doPrepare(DeploymentAdapter.java:39)
           at weblogic.management.deploy.internal.DeploymentAdapter.prepare(DeploymentAdapter.java:187)
           at weblogic.management.deploy.internal.AppTransition$1.transitionApp(AppTransition.java:21)
           at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:233)
           at weblogic.management.deploy.internal.ConfiguredDeployments.prepare(ConfiguredDeployments.java:165)
           at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:122)
           at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:173)
           at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:89)
           at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
           at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
           at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
    null
    I also noticed that the DocFile directory inside the stage directory is deleted once the ServerBox1 is started completely.
    Thanks for the assistance.

    Hi Partha. Did you get a solution to your problem with high connection delay times on your server? I'm having a similar problem and saw your post.
    Thanks,
    Mark

Maybe you are looking for