Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Hi All,

My Issue was seen when I was only trying to deploy a simple 'Hello World' servlet endpoint, it was a very simply war and contained one dependency servlet-api 3.1.0 which is provided on the jetty classpath. So, I wasn't trying to include anythin in my war. It was a an empty war essentially in terms of dependencies. Hence, I had to clashes or conflicts with the existing jars the gigaspaces docmentation mentions to add to the jetty directory. Also, for the record I was able to deploy this war in the standalone Jetty 9.3.7.v20160115, but not the same Jetty 9.3.7.v20160115 wrapped up in Gigaspaces.

But, if anyone ever runs into a problem similar to what I've written above. The Issue was directly related to the Native Java way to do dependency injection (JSR-330 if I remember correctly). The directions outlined here in the Xap documentation:

https://docs.gigaspaces.com/xap/12.1/dev-java/web-jetty-processing-unit-container.html#jetty-version

never actually adds any of the Java dependencies to do dependency injection using the JSR-330 spec. However, the reason why Jetty was looking for these missing dependencies was to do with a jar added to the jetty lib directory called cdi-websocket.jar (The Gigaspaces documentation says to add this jar). This jar tries to load a CDI Provider in order to wire up beans that are required and it fails as there is no CDI implementation in the jetty container to do the dependency injection. So in short the Gigaspaces documentation needs to be updated.

Regards, Adrian.

Hi All,

My Issue was seen when I was only trying to deploy a simple 'Hello World' servlet endpoint, it was a very simply war and contained one dependency servlet-api 3.1.0 which is provided on the jetty classpath. So, I wasn't trying to include anythin anything in my war. It was a an empty war essentially in terms of dependencies. Hence, I had to clashes or conflicts with the existing jars the gigaspaces docmentation mentions to add to the jetty directory. Also, for the record I was able to deploy this war in the standalone Jetty 9.3.7.v20160115, but not the same Jetty 9.3.7.v20160115 wrapped up in Gigaspaces.

But, if anyone ever runs into a problem similar to what I've written above. The Issue was directly related to the Native Java way to do dependency injection (JSR-330 if I remember correctly). The directions outlined here in the Xap documentation:

https://docs.gigaspaces.com/xap/12.1/dev-java/web-jetty-processing-unit-container.html#jetty-version

never actually adds any of the Java dependencies to do dependency injection using the JSR-330 spec. However, the reason why Jetty was looking for these missing dependencies was to do with a jar added to the jetty lib directory called cdi-websocket.jar (The Gigaspaces documentation says to add this jar). This jar tries to load a CDI Provider in order to wire up beans that are required and it fails as there is no CDI implementation in the jetty container to do the dependency injection. So in short the Gigaspaces documentation needs to be updated.

Regards, Adrian.

Hi All,

My Issue was seen when I was only trying to deploy a simple 'Hello World' servlet endpoint, it was a very simply war and contained one dependency servlet-api 3.1.0 which is provided on the jetty classpath. So, I wasn't trying to include anything in my war. It was an empty war essentially in terms of dependencies. Hence, I had to no clashes or conflicts with the existing jars the gigaspaces docmentation mentions to add to the jetty directory. Also, for the record I was able to deploy this war in the standalone Jetty 9.3.7.v20160115, but not the same Jetty 9.3.7.v20160115 wrapped up in Gigaspaces.

But, if anyone ever runs into a problem similar to what I've written above. The Issue was directly related to the Native Java way to do dependency injection (JSR-330 if I remember correctly). The directions outlined here in the Xap documentation:

https://docs.gigaspaces.com/xap/12.1/dev-java/web-jetty-processing-unit-container.html#jetty-version

never actually adds any of the Java dependencies to do dependency injection using the JSR-330 spec. However, the reason why Jetty was looking for these missing dependencies was to do with a jar added to the jetty lib directory called cdi-websocket.jar (The Gigaspaces documentation says to add this jar). This jar tries to load a CDI Provider in order to wire up beans that are required and it fails as there is no CDI implementation in the jetty container to do the dependency injection. So in short the Gigaspaces documentation needs to be updated.

Regards, Adrian.

Hi All,

My Issue was seen when I was only trying to deploy a simple 'Hello World' servlet endpoint, it was a very simply war and contained one dependency servlet-api 3.1.0 which is provided on the jetty classpath. So, I wasn't trying to include anything in my war. It was an empty war essentially in terms of dependencies. Hence, I had no clashes or conflicts with the existing jars the gigaspaces docmentation mentions to add to the jetty directory. Also, for the record I was able to deploy this war in the standalone Jetty 9.3.7.v20160115, but not the same Jetty 9.3.7.v20160115 wrapped up in Gigaspaces.Gigaspaces 12.1.1-17121.

But, if anyone ever runs into a problem similar to what I've written above. The Issue was directly related to the Native Java way to do dependency injection (JSR-330 if I remember correctly). The directions outlined here in the Xap documentation:

https://docs.gigaspaces.com/xap/12.1/dev-java/web-jetty-processing-unit-container.html#jetty-version

never actually adds any of the Java dependencies to do dependency injection using the JSR-330 spec. However, the reason why Jetty was looking for these missing dependencies was to do with a jar added to the jetty lib directory called cdi-websocket.jar (The Gigaspaces documentation says to add this jar). This jar tries to load a CDI Provider in order to wire up beans that are required and it fails as there is no CDI implementation in the jetty container to do the dependency injection. So in short the Gigaspaces documentation needs to be updated.

Regards, Adrian.

Hi All,

My Issue was seen when I was only trying to deploy a simple 'Hello World' servlet endpoint, it was a very simply simple war and contained one dependency servlet-api 3.1.0 which is provided on the jetty classpath. So, I wasn't trying to include anything in my war. It was an empty war essentially in terms of dependencies. Hence, I had no clashes or conflicts with the existing jars the gigaspaces docmentation mentions to add to the jetty directory. Also, for the record I was able to deploy this war in the standalone Jetty 9.3.7.v20160115, but not the same Jetty 9.3.7.v20160115 wrapped up in Gigaspaces 12.1.1-17121.

But, if anyone ever runs into a problem similar to what I've written above. The Issue was directly related to the Native Java way to do dependency injection (JSR-330 if I remember correctly). The directions outlined here in the Xap documentation:

https://docs.gigaspaces.com/xap/12.1/dev-java/web-jetty-processing-unit-container.html#jetty-version

never actually adds any of the Java dependencies to do dependency injection using the JSR-330 spec. However, the reason why Jetty was looking for these missing dependencies was to do with a jar added to the jetty lib directory called cdi-websocket.jar (The Gigaspaces documentation says to add this jar). This jar tries to load a CDI Provider in order to wire up beans that are required and it fails as there is no CDI implementation in the jetty container to do the dependency injection. So in short the Gigaspaces documentation needs to be updated.

Regards, Adrian.