fintanr's weblog

Archives

« November 2009
MonTueWedThuFriSatSun
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
      
Today

the links




Twitter Updates

    follow me on Twitter
















    20080909 Tuesday September 09, 2008

    SAAJ ClassCast Error with JDK 6
    A project I'm working on at the moment has an authentication component which uses a webservice to do most of the work. During the development I stumbled across an issue, which while appearing to be known, is not well documented in any place, so in case anyone else hits this ....

    Software Environment

    The key part here is the JDK version, from what I can discern after doing some searching all 1.6 JDK's have this issue, for the example here I'm using the 1.6.0_06 JDK (services & support), as bundled with Solaris Nevada (snv_97) (services & support), either Tomcat 6 or Glassfish 3 for the app server, and Netbeans 6.5 as the IDE. Our webservice in this case was generated using wscompile as bundled with Appserver 9.1 (services & support).

    Stacktrace

    The stacktrace that we are getting here (from Tomcat in this case, but the appserver is not important here) is
    org.apache.jasper.JasperException: java.lang.ClassCastException: 
     com.sun.xml.internal.messaging.saaj.soap.ver1_1.Message1_1Impl cannot 
     be cast to com.sun.xml.messaging.saaj.soap.MessageImpl
    	org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:541)
    	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:435)
    	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
    	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
    	javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
    
    root cause
    
    java.lang.ClassCastException: com.sun.xml.internal.messaging.saaj.soap.ver1_1.Message1_1Impl 
     cannot be cast to com.sun.xml.messaging.saaj.soap.MessageImpl
    	com.sun.xml.rpc.client.StubBase._postSendingHook(StubBase.java:231)
    	com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:324)
    	.............
    
    Whats actually going on here (and if anyone has corrections please feel free to provide them, this is not an area I've spent time reading into) is that the saaj classes that you would have used before from the webservices development packs are now present in the 1.6 jdks rt.jar, and we have a conflict between what is expected by the webservice and what we have.

    Workarounds

    A couple of workarounds exist, namely things I really don't like as the vary from environment to environment e.g. placing endorsed libs in place. A more generic workaround is to add an extra startup option of
    -Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl
    
    which eliminates the problem, but may have implications for other aspects of your application, so use with caution.
    (2008-09-09 06:35:11.0) Permalink

    20060516 Tuesday May 16, 2006

    Sun Java System Web Server 7 Tech Preview
    As part of our ongoing performance work we have been running the development builds of the Sun Java System Web Server 7 for quite some time (this work ties into what I previously termed as the Buzzword Bingo area of Suns Performance Lifestyle). Web Server 7 has just been released as a technology preview, you can download it here, as also mentioned by Chris Elving, Joe McCabe and other members of the Web Server development team.

    From the work that I have done with Web Server 7 over the last few months I have to admit that I have become a big fan of this version, its got some really nice features, particuarly in terms of admininstration, in my case the stand out administration feature is the command line interface wadm, and its massively, massively scaleable. However in terms of our benchmarking work the first step for us is to ensure that we can install the webserver automatically when we get a new build, so here as an example of a silent installation of Web Server 7.

    The example here is on my laptop, running the latest Solaris Express. I will assume that you have an unarchived version of the webserver to start with, and go from there.

    Create a statefile, you can use this as a template if you wish, in my case the statefile is the following

    [STATE_BEGIN Sun Java System Web Server c618c83b4cca71e43586cdace6e02487c986543d]
    defaultInstallDirectory = /sun/webserver7
    currentInstallDirectory = /opt/SUNWwbsvr7
    UPGRADE = false
    SELECTED_COMPONENTS = svrcore,admincli,devsupport
    USE_BUNDLED_JDK = FALSE
    JDK_LOCATION = /usr/java
    CONFIGURE_ADMIN_AS = Server
    STARTUP_ONBOOT = false
    ADMIN_HOST = prometheus
    ADMIN_SSL_PORT = 8989
    ADMIN_PORT =
    ADMIN_UID = root
    ADMIN_NAME = admin
    ADMIN_PASSWD = changeme
    AGENT_HOST =
    AGENT_SSL_PORT =
    REGISTER_ADMIN_AGENT =
    WEB_SERVERNAME = prometheus
    WEB_PORT = 80
    WEB_UID = webservd
    WEB_DOCROOT =
    SIXTYFOURBIT_INSTALL = false
    CONFIG_NAME = prometheus
    [STATE_DONE Sun Java System Web Server c618c83b4cca71e43586cdace6e02487c986543d]

    This statefile installs the webserver, adminstration server and sample applications, using the already installed jvm, and setups the admininstration server as a server rather than agent instance. You may need to generate a different id string for your machine, if so, assuming your template is saved as say /tmp/template you could do something like the following

    #!/bin/sh
    
    ID=`./setup --id`
    ID_STR=`grep STATE_BEGIN /tmp/template | awk '{print $7}' | sed -e "s/]//"`
    sed -e "s/$ID_STR/$ID/g" < /tmp/template > /tmp/ws7inst.txt
    

    And thats pretty much it, to do your install just run the setup program....

    # ./setup --silent /tmp/ws7inst.txt
    
    Installation Successful.
    
    Next Steps:
    
    1. Start the Administration Server by executing:
    
    /opt/SUNWwbsvr7/admin-server/bin/startserv
    
    2. You can access the Web Admin Server by accessing the following URL:
    
    https://prometheus:8989
    
    3. Refer to the installation log file at
    /opt/SUNWwbsvr7/setup/Sun_Java_System_Web_Server_install.log for more details.
    

    (2006-05-16 15:00:15.0) Permalink

    20051108 Tuesday November 08, 2005

    Directory Server 5.2 with less than 2Gb Entry Cache
    Part two of my notes on the 2005Q4 release of the Java Enterprise System. This one is not so much of a workaround, more of an information piece. The Directory Server folks have been hard at work further increasing the performance of the Directory Server, and one of these improvements was a change in the way the entry cache is calculated. A side effect of this is that for rigs with an entry cache of less than 2Gbs you could encounter a performance degradation.

    The workaround for this is very simple, just set the environment variable SUN_SUPPORT_SLAPD_DEFPOOL=true and restart your directory server. i.e for an ldap deployment called ds,

    # cd /var/opt/mps/serverroot/slapd-ds
    # SUN_SUPPORT_SLAPD_DEFPOOL=true; export SUN_SUPPORT_SLAPD_DEFPOOL
    # ./start-slapd
    
    This is also documented in the Sun Java System Directory Server 5.2 2005Q4 Release Notes.
    (2005-11-08 06:25:00.0) Permalink Comments [1]

    Communications Express in Webserver Container Bug Work Arounds
    The 2005Q4 release of the Java Enterprise System has come out, so I guess its time to share a few workarounds for some potential problems that you may see. First up is a product that we are working on with some of our colleagues in various parts of Sun, Communications Express. Two seperate gotcha type issues here, one of which is in the release notes, the other was hit at the end of the release cycle.

    Firstly let us describe the communications express component (communications express is also referred to as UWC, which is what I will call it for the rest of this post) of the scenario that we have deployed. This deployment is relatively straight forward, with a Directory Server tier, an Access Manager tier deployed in an Application Server Web Container then Messaging Server and UWC on the same tier, with UWC deployed in a Webserver web container, and using the Access Manager SDK. Graphically this looks like.


    All tiers in this case are deployed on Solaris 10

    The first issue is very straight forward, and is documented in the UWC release notes as bugid 6283991 (Java Exception on Web Server Startup after Configuration of Communications Express). This issue will manifest itself as a failure during the startup of your webserver with a stacktrace similar too

    info: WEB0100: Loading web module in virtual server [ms.jestest.sun.com] at [/search]
    failure: WebModule[/uwc]: WEB2680: Exception starting filter IdentitySSOAuthFilter
    java.lang.NoClassDefFoundError: com/iplanet/am/sdk/AMException
            at java.lang.Class.getDeclaredConstructors0(Native Method)
            at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328)
            at java.lang.Class.getConstructor0(Class.java:2640)
            at java.lang.Class.newInstance0(Class.java:321)
            at java.lang.Class.newInstance(Class.java:303)
    
    The workaround is to add the following entrys to your serverclasspath prefix in your server.xml
    [ split accross lines for readability ]
    
    /opt/SUNWam/lib:/opt/SUNWam/locale:/etc/opt/SUNWam/config:
    /opt/SUNWam/lib/am_sdk.jar:/opt/SUNWam/lib/am_services.jar:
    /opt/SUNWam/lib/am_logging.jar
    
    The second issue is a lot more confusing at first glance (or at least it was for me). When you deploy the SunOne Webserver on Solaris 10 using the Jes Installer the default user for the webserver is webservd. The issue that we hit here is an inability to communicate with the Access Manager tier, whose details we have configured during the initial install of our Access Manager SDK. This will manifest itself in a stacktrace similar to the following during webserver startup.
    info: CORE3282: stdout: AdminUtils: Could not initialize admin  info message: Got LDAPServiceException code=19
    info: CORE3282: stdout: 10/04/2005 02:32:46:381 PM BST: Thread[Thread-1,5,main]
    info: CORE3282: stdout: Crypt.static{}: Encryptor class= com.iplanet.services.util.JSSEncryption
    warning: CORE3283: stderr: Failed to create debug directory
    info: CORE3282: stdout: 10/04/2005 02:32:46:419 PM BST: Thread[Thread-1,5,main]
    info: CORE3282: stdout: Intilize CryptoManager in JSSEncryption.java
    info: CORE3282: stdout: 10/04/2005 02:32:46:427 PM BST: Thread[Thread-1,5,main]
    info: CORE3282: stdout: ocspCheck value in JSSEncryption : false
    info: CORE3282: stdout: 10/04/2005 02:32:46:574 PM BST: Thread[Thread-1,5,main]
    info: CORE3282: stdout: Crypt.static{}: Encryptor class= com.iplanet.services.util.JSSEncryption
    info: CORE3282: stdout: 10/04/2005 02:32:46:579 PM BST: Thread[Thread-1,5,main]
    info: CORE3282: stdout: Crypt.static{}: Encryptor class= com.iplanet.services.util.JSSEncryption
    warning: CORE3283: stderr: Exception in thread "Thread-1" java.lang.NullPointerException
    warning: CORE3283: stderr:      at java.lang.String.(String.java:479)
    warning: CORE3283: stderr:      at com.sun.identity.security.AdminPasswordAction.run(AdminPasswordAction.java:86)
    warning: CORE3283: stderr:      at java.security.AccessController.doPrivileged(Native Method)
    warning: CORE3283: stderr:      at com.sun.identity.authentication.internal.server.SMSAuthModule.initialize(SMSAuthModule.java:131)
    warning: CORE3283: stderr:      at com.sun.identity.authentication.internal.LoginContext.login(LoginContext.java:122)
    warning: CORE3283: stderr:      at com.sun.identity.authentication.internal.AuthLoginThread.run(AuthLoginThread.java:82)
    info: CORE3282: stdout: 10/04/2005 02:32:46:587 PM BST: Thread[main,5,main]
    info: CORE3282: stdout: AuthContext::getInformationRequired() returned from waiting for Callback array
    info: CORE3282: stdout: 10/04/2005 02:32:46:587 PM BST: Thread[main,5,main]
    info: CORE3282: stdout: AuthContext::getLoginStatus()
    info: CORE3282: stdout: 10/04/2005 02:32:46:588 PM BST: Thread[main,5,main]
    info: CORE3282: stdout: AuthContext::getInformationRequired() waiting for Callback array
    info: CORE3282: stdout: 10/04/2005 02:32:46:588 PM BST: Thread[main,5,main]
    info: CORE3282: stdout: AuthContext::getLoginStatus()
    
    The easiest workarounds for this (please take note of your own security considerations if applying either of these) are to either make the contents /etc/opt/SUNWam/config world readable, or else readable by webservd. For those of you with access to sunsolve this is documented as 6332324 - uwc in webserver container fails to startup due to unreadable AMConfig.properties
    (2005-11-08 05:54:00.0) Permalink Comments [4]