GMLC URL is "/mobicents" by default on the server, can we change that?

[angrygreenfrogs]

For example a test request looks like this:

http://192.168.60.128:8080/mobicents?msisdn=987657102293

Previously in fact I think it was "/restcomm", but something in the latest build seems to have changed this.

Is there a URL naming standard for Restcomm components like this? I was thinking it should perhaps be "/restcomm-gmlc" or "/gmlc".

And does anyone know where this URL is configured from?

[deruelle]

/restcomm-gmlc sounds good.

I think it's configured in the HTTP Servlet Resource Adaptor configuration file servlet-name, https://github.com/RestComm/jain-slee.http/blob/master/resources/http-servlet/ra/src/main/resources/META-INF/resource-adaptor-jar.xml

[Vanit]

It appears the reason context path is /mobicents and not /restcomm is that the gmlc build.xml is checking out http-servlet 2.8.5, which is really old. The latest is 2.8.56 and properly references restcomm. I can't see any issues building the GMLC with the latest tag in my testing.

In any case, I'd argue that simply renaming it to /restcomm-gmlc is the wrong solution. The http-servlet is a generic helper for servicing http requests so the jboss context path should remain generic. The real problem is that https://github.com/RestComm/gmlc/blob/master/core/slee/services/sbbs/src/main/java/org/mobicents/gmlc/slee/MobileCoreNetworkInterfaceSbb.java is responding to every request with no regard for the request path (ie /restcomm/gmlc already hits the MLP, as does any URI).

Looking at the http-servlet's documentation I can't see any support for routing beyond request types, so it would be up to MobileCoreNetworkInterfaceSbb to support known routes and else return 404.

Having said all that, where should the MLP be routing to? /restcomm/mlp? Or stick with /restcomm/gmlc?

[FerUy]

@Monix merged #49, great catch.

I vote for /restcomm/gmlc/mlp (for a later stage we will have SIP also, thus /restcomm/gmlc/sip would be used in that case).

[Vanit]

Agreed! I think we can call this specific issue closed, I've made a new issue to handle the routing component: #50

[FerUy]

Done!

[Vanit]

Can you reopen this @FerUy?

There are conflicting dependencies causing the old version of the servlet still to be loaded instead of the new version.

[FerUy]

Done @Monix

[Vanit]

I've found the culprit. The clean target has been left out of the release target dependencies, so any artifacts left from old builds are merged into every subsequent build. In this case it meant that the old and new http-servlets were deployed together if the user simply did a git pull and rebuilt the gmlc since this issue was fixed.

Looking at the git history, it looks it's been missing since 3d926cc. I suspect that's because it was deleting the entire checkout dir including the large downloaded zips.

I'm going to add the clean target back to the release target, and have it delete the following:

• target dir
• docs dir
• checkout dir (subdirectories only, so the zip files will be preserved between builds)

[FerUy]

Great @Monix, that will help reducing the huge size of the build we are having right now. Looking forward for your next commit for this fix.

[FerUy]

@Monix, I needed to revert it. Although it looked OK to me, the build in Cloudbees failed after merging. Once reverted, it's OK again. Need to investigate further.

[Vanit]

@FerUy That's a shame! Is there a failure log for that?

[FerUy]

[INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 06:11 min [INFO] Finished at: 2016-07-29T15:32:16+01:00 [INFO] Final Memory: 333M/995M [INFO] ------------------------------------------------------------------------

• ant -f release/build.xml -Drestcomm.gmlc.release.version=1.0.36 -Drelease.build.profiles=all Buildfile: /scratch/jenkins/workspace/Restcomm-GMLC/release/build.xml clean: BUILD FAILED /scratch/jenkins/workspace/Restcomm-GMLC/release/build.xml:100: Directory does not exist: /scratch/jenkins/workspace/Restcomm-GMLC/release/checkout

[Vanit]

Ah, I know the problem! failureonerror for the checkout delete should be false.

[FerUy]

I thought about setting that too actually, but preferred to investigate further.

[FerUy]

@Monix, I ran out of options after a while, so I gave it a try. It worked ;) Thanks :+1:

[Vanit]

@FerUy Awesome! Can you close this issue?

[FerUy]

Hi @Monix, I will do it soon after some testing with the latest build.

[FerUy]

@Monix ... I was just doing some testing when you asked to close the issue. Tests went perfect, great job, thanks. Closed ;)

[Vanit]

@FerUy Excellent!