wsit
  1. wsit
  2. WSIT-300

JAX-WS is holding configuration files when app is deployed

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: current
    • Fix Version/s: 1.0
    • Component/s: policy
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Sun

    • Issuezilla Id:
      300

      Description

      JAX-WS holds configuration files (sun-jaxws.xml and wsit config files). This
      breaks IDE integration, because IDE deployment is done in-place (just publishing
      directory for better performance) but then users are not able to
      delete/clean&build services once they are deployed.

      These are steps to reproduce with NB and GF:

      With NB 5.5.1, Jan 11th build, here are steps that work for me ..

      • Create a service endpoint Web project, add Web service, add an operation,
        Deploy it
      • Create a client Web project, add Web service client, invoke the service
      • Delete the client
      • Delete the service endpoint project

      I see the following error in my window when deleting the service endpoint:

      – cut here –
      Deleting directory C:\Documents and Settings\Arun\WebApplication9\build
      C:\Documents and Settings\Arun\WebApplication9\nbproject\build-impl.xml:702:
      Unable to delete file C:\Documents and
      Settings\Arun\WebApplication9\build\web\WEB-INF\sun-jaxws.xml
      BUILD FAILED (total time: 0 seconds)
      – cut here –

        Activity

        snajper created issue -
        Hide
        tamiro added a comment -

        I don't think you have to delete the client.
        Once you have deployed the client, attempting
        to do a Clean and Build has been bumpting
        into the problem.

        Show
        tamiro added a comment - I don't think you have to delete the client. Once you have deployed the client, attempting to do a Clean and Build has been bumpting into the problem.
        Hide
        vivekp added a comment -

        JAXWS only parses sun-jaxws.xml. Please clarify whether you see this problem
        with sun-jaxws.xml or wsit configuration. If you see issue with sun-jaxws.xml
        then we can work on it for wsit config files which are parsed by wsit
        components, I guess policy and thats where it should be answered.

        For sun-jaxws.xml, looking at the code we are doing the right thing and you
        should not see the problem. Let me know if you do. Here is the code form
        DeploymentDescriptorParser that clsoes the readers:

        /**

        • Parses the {@code sun-jaxws.xml} file and configures
          * a set of {@link HttpAdapter}s.
          */
          public @NotNull List<A> parse(String systemId, InputStream is) {
          XMLStreamReader reader = null;
          try { reader = XMLStreamReaderFactory.create(systemId,is,true); XMLStreamReaderUtil.nextElementContent(reader); return parseAdapters(reader); } finally {
          if (reader != null) {
          try { reader.close(); } catch (XMLStreamException e) { throw new ServerRtException("runtime.parser.xmlReader",e); }
          }
          }
          }

          /**
          * Parses the {@code sun-jaxws.xml}

          file and configures

        • a set of {@link HttpAdapter}

          s.
          */
          public @NotNull List<A> parse(File f) throws IOException

          Unknown macro: { FileInputStream in = new FileInputStream(f); try { return parse(f.getPath(), in); } finally { in.close(); } }
        Show
        vivekp added a comment - JAXWS only parses sun-jaxws.xml. Please clarify whether you see this problem with sun-jaxws.xml or wsit configuration. If you see issue with sun-jaxws.xml then we can work on it for wsit config files which are parsed by wsit components, I guess policy and thats where it should be answered. For sun-jaxws.xml, looking at the code we are doing the right thing and you should not see the problem. Let me know if you do. Here is the code form DeploymentDescriptorParser that clsoes the readers: /** Parses the {@code sun-jaxws.xml} file and configures * a set of {@link HttpAdapter}s. */ public @NotNull List<A> parse(String systemId, InputStream is) { XMLStreamReader reader = null; try { reader = XMLStreamReaderFactory.create(systemId,is,true); XMLStreamReaderUtil.nextElementContent(reader); return parseAdapters(reader); } finally { if (reader != null) { try { reader.close(); } catch (XMLStreamException e) { throw new ServerRtException("runtime.parser.xmlReader",e); } } } } /** * Parses the {@code sun-jaxws.xml} file and configures a set of {@link HttpAdapter} s. */ public @NotNull List<A> parse(File f) throws IOException Unknown macro: { FileInputStream in = new FileInputStream(f); try { return parse(f.getPath(), in); } finally { in.close(); } }
        Hide
        snajper added a comment -

        I reproduced the problem for sun-jaxws.xml also with checking that it's GF java
        process which is holding the file. So, the problem may be in GF, JAX-WS, WSIT.

        I'm not aware of whole code which takes care of sun-jaxws.xml, what you posted
        looks good to me, however, the problem exists.

        Show
        snajper added a comment - I reproduced the problem for sun-jaxws.xml also with checking that it's GF java process which is holding the file. So, the problem may be in GF, JAX-WS, WSIT. I'm not aware of whole code which takes care of sun-jaxws.xml, what you posted looks good to me, however, the problem exists.
        Hide
        snajper added a comment -

        I didn't include any WSIT config files when reproducing this, which may (may not

        • depends on the way this works) put WSIT out of the picture.
        Show
        snajper added a comment - I didn't include any WSIT config files when reproducing this, which may (may not depends on the way this works) put WSIT out of the picture.
        Hide
        vivekp added a comment -

        Ok. There was similar bug fix made in the head branch by rama and to my
        recollection was ported into JAXWS 2.1, latest code looks good. Assigngin to
        rama for further evaluation.

        Show
        vivekp added a comment - Ok. There was similar bug fix made in the head branch by rama and to my recollection was ported into JAXWS 2.1, latest code looks good. Assigngin to rama for further evaluation.
        Hide
        ramapulavarthi added a comment -

        For clarification, can you include the versions of test environment.
        Glassfish 9.0 or 9.1?
        JAX-WS 2.0 or 2.1?

        Show
        ramapulavarthi added a comment - For clarification, can you include the versions of test environment. Glassfish 9.0 or 9.1? JAX-WS 2.0 or 2.1?
        Hide
        snajper added a comment -

        GF b30
        WSIT b06

        So, it's AS9.1, JAX-WS 2.1

        Show
        snajper added a comment - GF b30 WSIT b06 So, it's AS9.1, JAX-WS 2.1
        Hide
        ramapulavarthi added a comment -

        I have tried with Glassfish B30 and Netbeans 5.5.1 and am not able to reproduce
        the problem.

        It would be nice if you can attach the reproduceable netbeans project files and
        steps to reproduce it.
        Are you using J2EE 1.4 WebService? because the error you reported says unable to
        delete sun-jaxws.xml, which should n't be used if it 109 style WS.

        Tom Amiro was trying to help with his environment. His steps to reproduce are
        different, where he changes the Web Service Attributes and redeploys it and it
        complains unable to delete the wsdl.

        Seeing all this, this does n't seem to me like a problem from JAX-WS. Either
        netbeans is holding the references to files or something. See, If you can
        reproduce with standalone AS, take the wars (service and client wars) and copy
        to autodeploy and delete them.

        Show
        ramapulavarthi added a comment - I have tried with Glassfish B30 and Netbeans 5.5.1 and am not able to reproduce the problem. It would be nice if you can attach the reproduceable netbeans project files and steps to reproduce it. Are you using J2EE 1.4 WebService? because the error you reported says unable to delete sun-jaxws.xml, which should n't be used if it 109 style WS. Tom Amiro was trying to help with his environment. His steps to reproduce are different, where he changes the Web Service Attributes and redeploys it and it complains unable to delete the wsdl. Seeing all this, this does n't seem to me like a problem from JAX-WS. Either netbeans is holding the references to files or something. See, If you can reproduce with standalone AS, take the wars (service and client wars) and copy to autodeploy and delete them.
        Hide
        tamiro added a comment -

        Created an attachment (id=188)
        client project unable to clean and build

        Show
        tamiro added a comment - Created an attachment (id=188) client project unable to clean and build
        Hide
        tamiro added a comment -

        Created an attachment (id=189)
        service that goes with the client

        Show
        tamiro added a comment - Created an attachment (id=189) service that goes with the client
        Hide
        tamiro added a comment -

        I attached the service and client projects at the point
        where I was getting the following error on trying to
        do a Clean and Build on the client

        init:
        deps-clean:
        do-clean:
        Deleting directory C:\Documents and
        Settings\tamiro.SHABANG.000\WebClient109Jan5\build
        C:\Documents and
        Settings\tamiro.SHABANG.000\WebClient109Jan5\nbproject\build-impl.xml:701:
        Unable to delete file C:\Documents and
        Settings\tamiro.SHABANG.000\WebClient109Jan5\build\web\WEB-INF\classes\WebService109Jan5Service.wsdl
        BUILD FAILED (total time: 1 second)

        I've see this problem with 109 and non109 projects.
        I'm not sure if the same file get locked or not.
        It doesn't happen all the time. After playing around
        with the wsit attrs on the service and refreshing
        the client and changing wsit attrs on the client
        it will start happening and then you have to restart GF
        to clear it.

        Show
        tamiro added a comment - I attached the service and client projects at the point where I was getting the following error on trying to do a Clean and Build on the client init: deps-clean: do-clean: Deleting directory C:\Documents and Settings\tamiro.SHABANG.000\WebClient109Jan5\build C:\Documents and Settings\tamiro.SHABANG.000\WebClient109Jan5\nbproject\build-impl.xml:701: Unable to delete file C:\Documents and Settings\tamiro.SHABANG.000\WebClient109Jan5\build\web\WEB-INF\classes\WebService109Jan5Service.wsdl BUILD FAILED (total time: 1 second) I've see this problem with 109 and non109 projects. I'm not sure if the same file get locked or not. It doesn't happen all the time. After playing around with the wsit attrs on the service and refreshing the client and changing wsit attrs on the client it will start happening and then you have to restart GF to clear it.
        Hide
        ramapulavarthi added a comment -

        I could n't reproduce the problem yet.
        One strange behavior with Netbeans, NB uses inpalce deplyment for
        webapplication, when you remove webapplication it won't undeploy from the Server.

        I need a standalone jax-ws testcase reproducing the problem.

        Show
        ramapulavarthi added a comment - I could n't reproduce the problem yet. One strange behavior with Netbeans, NB uses inpalce deplyment for webapplication, when you remove webapplication it won't undeploy from the Server. I need a standalone jax-ws testcase reproducing the problem.
        Hide
        snajper added a comment -

        Well, in an ideal world, we would have that test case ;O)

        Show
        snajper added a comment - Well, in an ideal world, we would have that test case ;O)
        Hide
        tamiro added a comment -

        Vivek pointed out that you can just delete the file
        outside of NB, like with Explorer. That reminds me
        that there seems to be a consensus that the problem
        is windows specific.

        I'm downgrading this to a P3 because of the work-around.
        Not having to bounce GF is much less irritating.

        Show
        tamiro added a comment - Vivek pointed out that you can just delete the file outside of NB, like with Explorer. That reminds me that there seems to be a consensus that the problem is windows specific. I'm downgrading this to a P3 because of the work-around. Not having to bounce GF is much less irritating.
        Hide
        ramapulavarthi added a comment -

        We have identified a issue with not closing sun-jaxws.xml file after reading it.
        Fix will be available soon.

        Show
        ramapulavarthi added a comment - We have identified a issue with not closing sun-jaxws.xml file after reading it. Fix will be available soon.
        Hide
        snajper added a comment -

        I was able to reproduce Tom's file holding problem with client config file on
        solaris, using fileholder script from Jakub I get GF as holding process. After
        deploying and running client app, GF (or JAX-WS) holds client config file
        (located under WEB-INF\classes)

        I'm raising priority, because this may cause problems also with redeployment
        while changing security mechanisms.
        Also, I think the workaround mentioned by Tom and Vivek does not exist - you
        can't delete the file while it is being held even from explorer - as we
        experienced with Rama while reproducing issue with sun-jaxws.xml.

        Also, when will the fix for sun-jaxws.xml be delivered for testing?

        Show
        snajper added a comment - I was able to reproduce Tom's file holding problem with client config file on solaris, using fileholder script from Jakub I get GF as holding process. After deploying and running client app, GF (or JAX-WS) holds client config file (located under WEB-INF\classes) I'm raising priority, because this may cause problems also with redeployment while changing security mechanisms. Also, I think the workaround mentioned by Tom and Vivek does not exist - you can't delete the file while it is being held even from explorer - as we experienced with Rama while reproducing issue with sun-jaxws.xml. Also, when will the fix for sun-jaxws.xml be delivered for testing?
        Hide
        tamiro added a comment -

        Yes you are right, the file just can't be deleted when there is
        a hold on it. You have to stop GF.

        You have hit on another important ramification of this
        problem, that it may cause problems redeploying apps.
        I've been seeing that in testing security mechanisms.
        If I just changed the numbers to be added in the calculator
        sample in the client servlet, did a build, and redeploy,
        I got an error saying there was no security header in message.
        I had to undeploy the client, stop GF, clean and build the
        client, redeploy it, before the client worked.

        Show
        tamiro added a comment - Yes you are right, the file just can't be deleted when there is a hold on it. You have to stop GF. You have hit on another important ramification of this problem, that it may cause problems redeploying apps. I've been seeing that in testing security mechanisms. If I just changed the numbers to be added in the calculator sample in the client servlet, did a build, and redeploy, I got an error saying there was no security header in message. I had to undeploy the client, stop GF, clean and build the client, redeploy it, before the client worked.
        Hide
        ramapulavarthi added a comment -

        Lock on sun-jaxws.xml has been fixed. please verify the fix.
        I am trying to reproduce the locks on wsdl file.

        Show
        ramapulavarthi added a comment - Lock on sun-jaxws.xml has been fixed. please verify the fix. I am trying to reproduce the locks on wsdl file.
        Hide
        ramapulavarthi added a comment -

        Have n't been able to reproduce the problem with wsdl locking so far.

        Please include the complete steps you are following to create the issue (like do
        this in NB, right click do this.....)

        Why does n't Netbeans do undeploy before clean or delete of the project?

        Show
        ramapulavarthi added a comment - Have n't been able to reproduce the problem with wsdl locking so far. Please include the complete steps you are following to create the issue (like do this in NB, right click do this.....) Why does n't Netbeans do undeploy before clean or delete of the project?
        Hide
        vivekp added a comment -

        Ok, so after I was able to reproduce the locking behaviour with Tom's service
        and client, I found the problem. PolicyConfigParser.parseModel() creates an
        XMLStreamReader, wraps in the Parser class and calls
        WSDLModel.WSDLParser.parse(parser, ....);

        RuntimeWSDLParser, at the end of parsing calls parser.parser.close(), here
        parser.parser is XMLStreamReader. XMLStreamReader.close() only releases the
        resources it has and its javadoc says that it does not close the underlying
        stream. In nutshell, its the callers responsibility to close stream explicitly
        just closing the reader does not release the stream. So in this case you need to
        close it explicitly.

        In jaxws code we use com.sun.xml.ws.streaming.TidyXmlStreamReader which is
        created using your reader and the stream that was used to create it. See the
        diff below, I put that code in PolicyConfigResolver and also use
        TidyXMLStreamReader in PolicyConfigParser to create Parser object.
        TidyXMLStreamReader is our internal class but feel free to copy it as its too
        late for us to move it to our API. Or maybe device some other mechanism to close
        the stream after you are done calling WSDLModel.WSDLParser.parse(parser, ....);
        in some finally block.

        I have verified this fix with Tom's service and client and it works just fine
        with this fix.

        Index: PolicyConfigResolver.java
        ===================================================================
        RCS file:
        /cvs/wsit/wsit/rt/src/com/sun/xml/ws/policy/jaxws/PolicyConfigResolver.java,v
        retrieving revision 1.6
        diff -r1.6 PolicyConfigResolver.java
        26a27,28
        > import com.sun.xml.ws.streaming.TidyXMLStreamReader;
        >
        27a30
        > import java.io.InputStream;
        65c68,69
        < final XMLStreamReader reader =
        xmlInputFactory.createXMLStreamReader(systemId, systemUrl.openStream());

        > InputStream is = systemUrl.openStream();
        > final TidyXMLStreamReader reader = new
        TidyXMLStreamReader(xmlInputFactory.createXMLStreamReader(systemId, is), is);

        Show
        vivekp added a comment - Ok, so after I was able to reproduce the locking behaviour with Tom's service and client, I found the problem. PolicyConfigParser.parseModel() creates an XMLStreamReader, wraps in the Parser class and calls WSDLModel.WSDLParser.parse(parser, ....); RuntimeWSDLParser, at the end of parsing calls parser.parser.close(), here parser.parser is XMLStreamReader. XMLStreamReader.close() only releases the resources it has and its javadoc says that it does not close the underlying stream. In nutshell, its the callers responsibility to close stream explicitly just closing the reader does not release the stream. So in this case you need to close it explicitly. In jaxws code we use com.sun.xml.ws.streaming.TidyXmlStreamReader which is created using your reader and the stream that was used to create it. See the diff below, I put that code in PolicyConfigResolver and also use TidyXMLStreamReader in PolicyConfigParser to create Parser object. TidyXMLStreamReader is our internal class but feel free to copy it as its too late for us to move it to our API. Or maybe device some other mechanism to close the stream after you are done calling WSDLModel.WSDLParser.parse(parser, ....); in some finally block. I have verified this fix with Tom's service and client and it works just fine with this fix. Index: PolicyConfigResolver.java =================================================================== RCS file: /cvs/wsit/wsit/rt/src/com/sun/xml/ws/policy/jaxws/PolicyConfigResolver.java,v retrieving revision 1.6 diff -r1.6 PolicyConfigResolver.java 26a27,28 > import com.sun.xml.ws.streaming.TidyXMLStreamReader; > 27a30 > import java.io.InputStream; 65c68,69 < final XMLStreamReader reader = xmlInputFactory.createXMLStreamReader(systemId, systemUrl.openStream()); — > InputStream is = systemUrl.openStream(); > final TidyXMLStreamReader reader = new TidyXMLStreamReader(xmlInputFactory.createXMLStreamReader(systemId, is), is);
        Hide
        vivekp added a comment -

        Added myself to cc.

        Show
        vivekp added a comment - Added myself to cc.
        Hide
        vivekp added a comment -

        Assigned to Fabian.

        Show
        vivekp added a comment - Assigned to Fabian.
        Hide
        m_potociar added a comment -

        Taking it

        Show
        m_potociar added a comment - Taking it
        Hide
        m_potociar added a comment -

        Implementing the fix

        Show
        m_potociar added a comment - Implementing the fix
        Hide
        m_potociar added a comment -

        The fix is checked into CVS

        Show
        m_potociar added a comment - The fix is checked into CVS
        Hide
        tamiro added a comment -

        Configuration:
        GF promoted b33
        WSIT bleedingedge 948 (Jan 26)
        NB 5.5.1 Jan 25
        wsit toolin plugin 2.16

        After client servlet has been deployed and successfully run,
        if I make a simple change to the client, like change the
        numbers to be added, and try a Clean and Build, I'm sitll getting
        the problem with client wsdl not being deleted

        init:
        deps-clean:
        do-clean:
        Deleting directory C:\Documents and Settings\tamiro.SHABANG.000\WebClient7\build
        C:\Documents and
        Settings\tamiro.SHABANG.000\WebClient7\nbproject\build-impl.xml:701: Unable to
        delete file C:\Documents and
        Settings\tamiro.SHABANG.000\WebClient7\build\web\WEB-INF\classes\NewWebServiceService.wsdl
        BUILD FAILED (total time: 1 second)

        Show
        tamiro added a comment - Configuration: GF promoted b33 WSIT bleedingedge 948 (Jan 26) NB 5.5.1 Jan 25 wsit toolin plugin 2.16 After client servlet has been deployed and successfully run, if I make a simple change to the client, like change the numbers to be added, and try a Clean and Build, I'm sitll getting the problem with client wsdl not being deleted init: deps-clean: do-clean: Deleting directory C:\Documents and Settings\tamiro.SHABANG.000\WebClient7\build C:\Documents and Settings\tamiro.SHABANG.000\WebClient7\nbproject\build-impl.xml:701: Unable to delete file C:\Documents and Settings\tamiro.SHABANG.000\WebClient7\build\web\WEB-INF\classes\NewWebServiceService.wsdl BUILD FAILED (total time: 1 second)
        Hide
        tamiro added a comment -

        Created an attachment (id=198)
        webapp7 service

        Show
        tamiro added a comment - Created an attachment (id=198) webapp7 service
        Hide
        tamiro added a comment -

        Created an attachment (id=199)
        client app to go with webapp7 service

        Show
        tamiro added a comment - Created an attachment (id=199) client app to go with webapp7 service
        Hide
        m_potociar added a comment -

        REevaluating

        Show
        m_potociar added a comment - REevaluating
        Hide
        m_potociar added a comment -

        With the last fix my local test shows that the file is not locked anymore.
        Please check if it works for you now. The change is integrated into WSIT since
        build #1625.

        Show
        m_potociar added a comment - With the last fix my local test shows that the file is not locked anymore. Please check if it works for you now. The change is integrated into WSIT since build #1625.
        Hide
        tamiro added a comment -

        OK, I tested WSIT 1626 and am no longer
        able to reproduce the problem. Thanks!

        Show
        tamiro added a comment - OK, I tested WSIT 1626 and am no longer able to reproduce the problem. Thanks!
        Hide
        tamiro added a comment -

        Did some more testing with Hudson WSIT build 1626
        and no matter how hard I tried, the problem is not
        reproducible. Marking verified.

        Show
        tamiro added a comment - Did some more testing with Hudson WSIT build 1626 and no matter how hard I tried, the problem is not reproducible. Marking verified.
        Hide
        mmatula added a comment -

        This issue was fixed before we created 1.0 branch, so the fix is in 1.0 ->
        setting target milestone to say so.

        Show
        mmatula added a comment - This issue was fixed before we created 1.0 branch, so the fix is in 1.0 -> setting target milestone to say so.
        kenaiadmin made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 300 12918

          People

          • Assignee:
            m_potociar
            Reporter:
            snajper
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: