You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@edgent.apache.org by Christofer Dutz <ch...@c-ware.de> on 2017/05/31 07:51:24 UTC

Changing the way the the servlets are loaded.

Hi guys,

While finishing the Maven migration of the last missing tests and finding a way to get rid of the one or the other monster while at it, I noticed the two modules console/server and console/servlets.
It seems as if “servlets” contain the real servlets for the server module and the reason the modules are split up, are to be able to create a war containing the servlets and to load that in an embedded jetty in the “server” module. I think we could simplify things greatly here.

In the Flex project the submodule “BlazeDS” is a server component based on a Servlet. Here initially the test-setup was done similarly and we were having a similarly complex test setup. I then refactored the tests to directly instantiate a Jetty servlet container and to programmatically register the servlets. The cool thing with this, is the “server” module could contain the “servlets” content and there would be no need to find the Servlets by loading some external jars.

Have a look at my “TestServer” implementation to get a feeling what I’m talking about:
https://github.com/apache/flex-blazeds/blob/42ecd811bec2c7825da250c73b9d3c463f990320/remoting/src/test/java/flex/messaging/util/TestServer.java

Chris

Re: Changing the way the the servlets are loaded.

Posted by Christofer Dutz <ch...@c-ware.de>.

Hi,

Ok … what you write regarding the platform independence makes absolute sense. The original code was actualy using the same Jetty Server classes as I was in BlazeDS, so an initial attempt was to build servlets as normal jar archive, to depend on that from the server and to manually register the servlets. That worked nicely. Unfortunately, I see that servlets should be a normal “war” web application to be usable for others. So I made it a war again and simply changed the way the jars are discovered. Instead of relying on a relative path to another module, I made sure servlets is built before server and simply have the maven-dependency-plugin copy that into the target directory under a name I have control over. This simplified the code for finding and accessing the war archive greatly.

Another thing I did was to extract one TestApplications class from the testcode of one module and made a new module in “tests” containing that file. Now I could access the jar file of that in other applications testsuites. 

From my point of view the build should now be structurally untangled. I created a pull request, so please feel free to investigate my changes: 
https://github.com/apache/incubator-edgent/pull/309

Travis is no longer complaining and seems to be happy with it ;-)

Chris

Am 31.05.17, 20:53 schrieb "Susan Cline" <ho...@pacbell.net>:

    Hi, Chris,

    I thought I would answer based on what I recall to be the original purpose of splitting them into a ‘server’ and ‘servlet’ directory.

    It was written in a way to allow other servlet containers to run the ‘servlet’ code without making them dependent on each other.
    With that said, looking at your TestServer although it uses a jetty server, could it be rewritten to use other servlet containers?

    If so, then I think what you propose seems okay to me.  I’m not sure if some of the examples would have to be rewritten though?

    Cheers,

    Susan

    > On May 31, 2017, at 12:51 AM, Christofer Dutz <ch...@c-ware.de> wrote:
    > 
    > Hi guys,
    > 
    > While finishing the Maven migration of the last missing tests and finding a way to get rid of the one or the other monster while at it, I noticed the two modules console/server and console/servlets.
    > It seems as if “servlets” contain the real servlets for the server module and the reason the modules are split up, are to be able to create a war containing the servlets and to load that in an embedded jetty in the “server” module. I think we could simplify things greatly here.
    > 
    > In the Flex project the submodule “BlazeDS” is a server component based on a Servlet. Here initially the test-setup was done similarly and we were having a similarly complex test setup. I then refactored the tests to directly instantiate a Jetty servlet container and to programmatically register the servlets. The cool thing with this, is the “server” module could contain the “servlets” content and there would be no need to find the Servlets by loading some external jars.
    > 
    > Have a look at my “TestServer” implementation to get a feeling what I’m talking about:
    > https://github.com/apache/flex-blazeds/blob/42ecd811bec2c7825da250c73b9d3c463f990320/remoting/src/test/java/flex/messaging/util/TestServer.java
    > 
    > Chris

Re: Changing the way the the servlets are loaded.

Posted by Susan Cline <ho...@pacbell.net>.

Hi, Chris,

I thought I would answer based on what I recall to be the original purpose of splitting them into a ‘server’ and ‘servlet’ directory.

It was written in a way to allow other servlet containers to run the ‘servlet’ code without making them dependent on each other.
With that said, looking at your TestServer although it uses a jetty server, could it be rewritten to use other servlet containers?

If so, then I think what you propose seems okay to me.  I’m not sure if some of the examples would have to be rewritten though?

Cheers,

Susan

> On May 31, 2017, at 12:51 AM, Christofer Dutz <ch...@c-ware.de> wrote:
> 
> Hi guys,
> 
> While finishing the Maven migration of the last missing tests and finding a way to get rid of the one or the other monster while at it, I noticed the two modules console/server and console/servlets.
> It seems as if “servlets” contain the real servlets for the server module and the reason the modules are split up, are to be able to create a war containing the servlets and to load that in an embedded jetty in the “server” module. I think we could simplify things greatly here.
> 
> In the Flex project the submodule “BlazeDS” is a server component based on a Servlet. Here initially the test-setup was done similarly and we were having a similarly complex test setup. I then refactored the tests to directly instantiate a Jetty servlet container and to programmatically register the servlets. The cool thing with this, is the “server” module could contain the “servlets” content and there would be no need to find the Servlets by loading some external jars.
> 
> Have a look at my “TestServer” implementation to get a feeling what I’m talking about:
> https://github.com/apache/flex-blazeds/blob/42ecd811bec2c7825da250c73b9d3c463f990320/remoting/src/test/java/flex/messaging/util/TestServer.java
> 
> Chris

Re: Changing the way the the servlets are loaded.

Posted by Dale LaBossiere <dm...@gmail.com>.

I’m not really familiar with that part of Edgent.  I’m hoping Susan Cline will notice this and respond.
— Dale

> On May 31, 2017, at 3:51 AM, Christofer Dutz <ch...@c-ware.de> wrote:
> ...
> While finishing the Maven migration of the last missing tests and finding a way to get rid of the one or the other monster while at it, I noticed the two modules console/server and console/servlets.