[jira] [Commented] (AXIS2-5745) Changing a service name doesn't update its TypeTable struct

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (AXIS2-5745) Changing a service name doesn't update its TypeTable struct

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/AXIS2-5745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16160982#comment-16160982 ]

Thorsten Schöning commented on AXIS2-5745:
------------------------------------------

Any ideas on how to fix this properly? I see multiple ways and maybe my use-case gets clearer if I'm describing it using some concrete examples:

Some of my services are deployed individually for each customer/mandator into the same Axis2 repo using some simple naming convention by adding a suffix. In the following example the suffixes ".sp1" and ".sp2" are used for what is basically the same logical service, only as individual and distinct deployments, no files shared. To not need to change too many configuration files, the "services.xml" of those services contain the exact same service name. Because those names need to be unique in Axis2, I simply change those names in the LifeCycle callback using the unique directory name created in the Axis2 service repository. So one service called "Auth" in "services.xml" in both example deployments becomes "de.am_soft.sm_mtg.backend.sp1.Auth" etc.

Axis2-Repo:

{CODE}
tschoening@potsdam:/var/lib/tomcat7/webapps/axis2/WEB-INF/services$ ls -lisa
[...]
130911  4 lrwxrwxrwx 1 tomcat7 tomcat7   61 Apr 20  2015 de.am_soft.sm_mtg.backend.sp1
131348  4 lrwxrwxrwx 1 tomcat7 tomcat7   61 Apr 20  2015 de.am_soft.sm_mtg.backend.sp2
{CODE}

services.xml:

{CODE}
<service name="Auth"
                        class="de.am_soft.util.backend.svcs.WsAxis2SvcLc">
        <Description>
                de.am_soft.sm_mtg.backend.svcs.ws.WsAuth
        </Description>

        <parameter name="ServiceClass">
                de.am_soft.sm_mtg.backend.svcs.ws.WsAuth
        </parameter>

        <messageReceivers>
                <messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-only"
                                                        class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver"
                />
                <messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out"
                                                        class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"
                />
        </messageReceivers>
</service>
{CODE}

axis2/services/listServices:

{CODE}
de.am_soft.sm_mtg.backend.sp1.Auth
de.am_soft.sm_mtg.backend.sp2.Auth
{CODE}

This works fine for some years now, besides the problem described initially. So if you say it is wrong or a misusage of the LifeCycle/deployment, in my opinion it should be disallowed to change service names at all. I would need an alternative solution for my use-case then of course... If you say my use-case is valid, I need a solution for the problem with the not up-to-date internal structures anymore after I change the name.

1. The low level rewriting of TypeTable I'm currently doing externally could be done in AxisService.setName. But that's only one internal structure and seems more like an ugly hack.

2. ServiceBuilder.populateService calls the lifecycle of a service at the end currently. In theory it could be called a lot earlier maybe allowing to set a name before it is used in internal structures. We would need a way to not let the set values be overridden by what is parsed form the config then.

3. ServiceBuilder.populateService could query for settings at runtime using some other interface than the lifecycle and merge those with what is available using the config as some fallback. Could be the same interface curently used with "some_element" and some proxy/dispatcher/whatever first calls the new interface and without any value it forwards to "some_element" like is currently used. The interesting question would be which data would be provided to that interface because I need to determine the directory my sertvice ist stored in... Currently I'm using two approaches, either "AxisService.getFileName" or "service.getClassLoader().getResource".

4. Storing an "initial service name" in AxisService.setName if not already available and use that while querying TypeTable and similar structs.

Any other ideas?

I'm not sure I completely understand where and how the TypeTable is filled initially and sometimes AxisService-instances are already created with names using a special CTOR, without ServiceBuilder.populateService. But I do have the feeling that if changing names is allowed, Axis2 should maintain up-to-date structures internally.


> Changing a service name doesn't update its TypeTable struct
> -----------------------------------------------------------
>
>                 Key: AXIS2-5745
>                 URL: https://issues.apache.org/jira/browse/AXIS2-5745
>             Project: Axis2
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.6.2
>         Environment: Windows 8.1 x86-64, Tomcat 7.0.68 x86-64
>            Reporter: Thorsten Schöning
>         Attachments: WsAxis2SvcLc.java
>
>
> I have an implementation of ServiceLifeCycle in which I'm overriding startUp and change the name of my service in some special way to make my deployment easier. I'm simply implementing some kind of mandator mechanism based on exploded services and their unique name in the file system.
> This worked pretty fine the last years, but today I encountered that Axis2 is handling structures internally in which the service name is used as some component of a key. Those structures were built before startUp was called and were not updated on a changed service name. My service generated an exception for some reason, Axis2 tried to handle that and failed itself with a NPE, which made debugging pretty hard of course because the original exception was lost.
> The NPE was thrown in the following line 183 of RPCMessageReceiver and the not up to date structure was TypeTable for the service, that's why elementQName was null instead of a valid object. Gladly I was able to access that map in my ServiceLifeCycle implementation and update the generated keys and QNames with my new updated service name. I would have expected that if I'm able to change the service name, structs containing it would get updated automatically by Axis 2, which at least for TypeTable currently isn't the case.
> {CODE}
> 175            Class[] exceptionTypes = method.getExceptionTypes();
> 176            for (Class exceptionType : exceptionTypes){
> 177                if (exceptionType.getName().equals(cause.getClass().getName())){
> 178                    // this is an bussiness logic exception so handle it properly
> 179                    String partQName = inMessage.getAxisService().getName() + getSimpleClassName(exceptionType);
> 180                    TypeTable typeTable = inMessage.getAxisService().getTypeTable();
> 181                    QName elementQName = typeTable.getQNamefortheType(partQName);
> 182                    SOAPFactory fac = getSOAPFactory(inMessage);
> 183                    OMElement exceptionElement = fac.createOMElement(elementQName);
> 184
> 185                    if (exceptionType.getName().equals(Exception.class.getName())){
> 186                        // this is an exception class. so create a element by hand and add the message
> 187                       OMElement innterExceptionElement = fac.createOMElement(elementQName);
> 188                       OMElement messageElement = fac.createOMElement("Message", inMessage.getAxisService().getTargetNamespace(), null);
> 189                       messageElement.setText(cause.getMessage());
> {CODE}
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.axis2/axis2-adb/1.6.2/org/apache/axis2/rpc/receivers/RPCMessageReceiver.java/#183
> I'm currently unable to build Axis2 from src and am not sure where one would implement such a change, therefore can't provide patches, but instead I'll simply post my implemantation of the change for TypeTable in my ServiceLifeCycle. In my case, TypeTable contained the following data for my old service name "SoapAuth":
> {CODE}
> complexTypeMap  HashMap<K,V>  (id=165)
> {java.sql={http://sql.java/xsd}SQLException, SoapAuthSecurityException={http://soap.ws.clients.backend.docs.docsrv.am_soft.de}SoapAuthSecurityException, java.sql.SQLException={http://sql.java/xsd}SQLException, logout={http://soap.ws.clients.backend.docs.docsrv.am_soft.de}logout, java.io={http://io.java/xsd}FileNotFoundException, SoapAuthSQLException={http://soap.ws.clients.backend.docs.docsrv.am_soft.de}SoapAuthSQLException, cookieAbgleich={http://soap.ws.clients.backend.docs.docsrv.am_soft.de}cookieAbgleich, SoapAuthClassNotFoundException={http://soap.ws.clients.backend.docs.docsrv.am_soft.de}SoapAuthClassNotFoundException, SoapAuthFileNotFoundException={http://soap.ws.clients.backend.docs.docsrv.am_soft.de}SoapAuthFileNotFoundException, java.io.IOException={http://io.java/xsd}IOException, SoapAuthIOException={http://soap.ws.clients.backend.docs.docsrv.am_soft.de}SoapAuthIOException, java.io.FileNotFoundException={http://io.java/xsd}FileNotFoundException}
> {CODE}
> My LifeCycle changes the name from "SoapAuth" to "de.am_soft.docsrv.docs.backend.SoapAuth" and therefore I simply rename all entries with the wrong service name, remove them and put new ones in.
> {CODE}
> private void updateSvcTypeTable(AxisService service,
> String oldSvcName,
> String newSvcName)
> {
> TypeTable tt = service.getTypeTable();
> @SuppressWarnings("unchecked")
> Map<String, QName> schemaMap = tt.getComplexSchemaMap();
> Map<String, QName> addSchemaMap = new HashMap<String, QName>(schemaMap.size());
> for (Iterator<Entry<String, QName>> it = schemaMap.entrySet().iterator();
> it.hasNext(); )
> {
> Entry<String, QName> entry = it.next();
> String key = entry.getKey();
> QName value = entry.getValue();
> if (!key.startsWith(oldSvcName))
> {
> continue;
> }
> String newKeyRegExp = String.format("^\\Q%s\\E", oldSvcName);
> String newValueRegExp = String.format("}\\Q%s\\E", oldSvcName);
> String newKey = key.replaceFirst(newKeyRegExp, newSvcName);
> String newValue = value.toString().replaceFirst(newValueRegExp, "}".concat(newSvcName));
> addSchemaMap.put(newKey, QName.valueOf(newValue));
> it.remove();
> }
> schemaMap.putAll(addSchemaMap);
> }
> {CODE}
> {CODE}
> private void changeSvcName(AxisService service)
> {
> logger.trace("Start: {}", service.getName());
> File configDir = this.getConfigDir(service);
> File svcDir = configDir.getParentFile().getParentFile();
> String oldSvcName = service.getName();
> String newSvcName = svcDir.getName().concat(".").concat(oldSvcName);
> service.setName(newSvcName);
> this.updateSvcTypeTable(service, oldSvcName, newSvcName);
> logger.trace("End: {}", service.getName());
> }
> {CODE}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]