You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Tony Dean (JIRA)" <ji...@apache.org> on 2007/10/23 16:53:50 UTC

[jira] Created: (AXIS2-3297) Service classloading issues when undeploying and redeploying a service with the same name.

Service classloading issues when undeploying and redeploying a service with the same name.
------------------------------------------------------------------------------------------

                 Key: AXIS2-3297
                 URL: https://issues.apache.org/jira/browse/AXIS2-3297
             Project: Axis 2.0 (Axis2)
          Issue Type: Bug
          Components: kernel
    Affects Versions: 1.3
         Environment: Windows XP/Jboss 4.2.
            Reporter: Tony Dean


I have a service called 'Maker' that generates new services upon client requests.  If it creates and deploys a new service called 'myService' for instance and then later removes this service (deletes from repository), and then generates an entirely new service with the same name, but with totally different functionality (ie., class name is the same, but has different functionality, the service.xml is similar, and the wsdl is totally different), it appears that when the client invokes the new service that the original service's (the service that was removed) class is executed instead of the class that is associated with the new service.  It appears that Axis2 is performing some service caching that is not getting replaced by new service deployment.  If I stop and restart the jboss server such that Axis2 is started from scratch, it loads everything just fine and the new class for that service is executed when the service is invoked by the client just as expected.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


[jira] Commented: (AXIS2-3297) Service classloading issues when undeploying and redeploying a service with the same name.

Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/AXIS2-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541855 ] 

Deepal Jayasinghe commented on AXIS2-3297:
------------------------------------------

I tested similar scenario and it worked for me. Will you be able to provide a test case or smt to regenerate the issue.

Thanks
Deepal

> Service classloading issues when undeploying and redeploying a service with the same name.
> ------------------------------------------------------------------------------------------
>
>                 Key: AXIS2-3297
>                 URL: https://issues.apache.org/jira/browse/AXIS2-3297
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.3
>         Environment: Windows XP/Jboss 4.2.
>            Reporter: Tony Dean
>
> I have a service called 'Maker' that generates new services upon client requests.  If it creates and deploys a new service called 'myService' for instance and then later removes this service (deletes from repository), and then generates an entirely new service with the same name, but with totally different functionality (ie., class name is the same, but has different functionality, the service.xml is similar, and the wsdl is totally different), it appears that when the client invokes the new service that the original service's (the service that was removed) class is executed instead of the class that is associated with the new service.  It appears that Axis2 is performing some service caching that is not getting replaced by new service deployment.  If I stop and restart the jboss server such that Axis2 is started from scratch, it loads everything just fine and the new class for that service is executed when the service is invoked by the client just as expected.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


[jira] Commented: (AXIS2-3297) Service classloading issues when undeploying and redeploying a service with the same name.

Posted by "Tony Dean (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/AXIS2-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635249#action_12635249 ] 

Tony Dean commented on AXIS2-3297:
----------------------------------

Deepal, were you able to verify this bug?  The fix appears to be simple.

> Service classloading issues when undeploying and redeploying a service with the same name.
> ------------------------------------------------------------------------------------------
>
>                 Key: AXIS2-3297
>                 URL: https://issues.apache.org/jira/browse/AXIS2-3297
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.3
>         Environment: Windows XP/Jboss 4.2.
>            Reporter: Tony Dean
>
> I have a service called 'Maker' that generates new services upon client requests.  If it creates and deploys a new service called 'myService' for instance and then later removes this service (deletes from repository), and then generates an entirely new service with the same name, but with totally different functionality (ie., class name is the same, but has different functionality, the service.xml is similar, and the wsdl is totally different), it appears that when the client invokes the new service that the original service's (the service that was removed) class is executed instead of the class that is associated with the new service.  It appears that Axis2 is performing some service caching that is not getting replaced by new service deployment.  If I stop and restart the jboss server such that Axis2 is started from scratch, it loads everything just fine and the new class for that service is executed when the service is invoked by the client just as expected.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


[jira] Resolved: (AXIS2-3297) Service classloading issues when undeploying and redeploying a service with the same name.

Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AXIS2-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Deepal Jayasinghe resolved AXIS2-3297.
--------------------------------------

    Resolution: Cannot Reproduce

> Service classloading issues when undeploying and redeploying a service with the same name.
> ------------------------------------------------------------------------------------------
>
>                 Key: AXIS2-3297
>                 URL: https://issues.apache.org/jira/browse/AXIS2-3297
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.3
>         Environment: Windows XP/Jboss 4.2.
>            Reporter: Tony Dean
>
> I have a service called 'Maker' that generates new services upon client requests.  If it creates and deploys a new service called 'myService' for instance and then later removes this service (deletes from repository), and then generates an entirely new service with the same name, but with totally different functionality (ie., class name is the same, but has different functionality, the service.xml is similar, and the wsdl is totally different), it appears that when the client invokes the new service that the original service's (the service that was removed) class is executed instead of the class that is associated with the new service.  It appears that Axis2 is performing some service caching that is not getting replaced by new service deployment.  If I stop and restart the jboss server such that Axis2 is started from scratch, it loads everything just fine and the new class for that service is executed when the service is invoked by the client just as expected.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


[jira] Reopened: (AXIS2-3297) Service classloading issues when undeploying and redeploying a service with the same name.

Posted by "Tony Dean (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AXIS2-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tony Dean reopened AXIS2-3297:
------------------------------


I'm sorry I never provided feedback.  I had some time today to look at this again and have determined the root cause.

If you enable "application" scope for your service, Axis2 caches the serviceGroupContext in the configurationContext so there is only one instance per service.  The serviceContext is associated with the serviceGroupContext and contains the actual service implementation class.

The problem comes into play when the serviceGroup is removed from the system.  Well, you think it is removed since the service is not longer callable.  However, the serviceGroupContext and therefore the serviceContext are still assoicated with the system's configurationContext.  Therefere, if someone comes along and creates a new serviceGroup by the same name, the same "old" serviceGroupContext and serviceContext will be used... and therefore, the old service implemenation class will try to be used with the new service... this causes big problems.

The only remedy is to restart Axis2 and/or the application server.

The fix for this problem is to remove the serviceGroupContext from the configurationContext when the serviceGroup is deleted.  This can be done by updating the ApplicationSessionServiceGroupContexts map.



> Service classloading issues when undeploying and redeploying a service with the same name.
> ------------------------------------------------------------------------------------------
>
>                 Key: AXIS2-3297
>                 URL: https://issues.apache.org/jira/browse/AXIS2-3297
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.3
>         Environment: Windows XP/Jboss 4.2.
>            Reporter: Tony Dean
>
> I have a service called 'Maker' that generates new services upon client requests.  If it creates and deploys a new service called 'myService' for instance and then later removes this service (deletes from repository), and then generates an entirely new service with the same name, but with totally different functionality (ie., class name is the same, but has different functionality, the service.xml is similar, and the wsdl is totally different), it appears that when the client invokes the new service that the original service's (the service that was removed) class is executed instead of the class that is associated with the new service.  It appears that Axis2 is performing some service caching that is not getting replaced by new service deployment.  If I stop and restart the jboss server such that Axis2 is started from scratch, it loads everything just fine and the new class for that service is executed when the service is invoked by the client just as expected.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org