Does Grails 3 run on any major servers?

504 views
Skip to first unread message

DAC

unread,
May 4, 2016, 6:10:27 PM5/4/16
to Grails Dev Discuss
I'm several months into a new project developed in Grails 3. Now we're starting to configure a production server, but we can't seem to find any of the major prod servers that we can deploy a Grails 3 application to. By major I mean JBoss EAP, WebLogic, etc... 

Is everyone else having these issues with Grails 3?

What major production servers are others having success on with Grails 3? 

ndn.n...@gmail.com

unread,
May 4, 2016, 6:29:38 PM5/4/16
to Grails Dev Discuss
Deploying Grials 3.1.16 to JBOSS EPA 6.4 failed with this error:
        java.lang.NoSuchMethodError: org.grails.orm.hibernate.cfg.CollectionType.<init>(Ljava/lang/Class;Lorg/grails/orm/hibernate/cfg/GrailsDomainBinder;)

Brad Booth

unread,
May 4, 2016, 11:03:13 PM5/4/16
to grails-de...@googlegroups.com
Grails 3 can produce a standard war, which can be deployed in any of the major servlet containers.  It can also produce a self executing jar.  Since Grails is based on Spring Boot it can be deployed how any other Spring Boot app can be deployed.  We use tomcat and have no issues (war) as well as cloud deployments on Cloud Foundry using an executable jar.  The error you are getting is usually a classpath problem.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-disc...@googlegroups.com.
To post to this group, send email to grails-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/380b9942-e949-445f-8e23-3d1a8ca6e72a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

DAC

unread,
May 5, 2016, 11:37:49 AM5/5/16
to Grails Dev Discuss
Yes, it's a war file but it's not that simple. As you said we have a classpath, or dependency issues. The one mentioned here is just an example, there are others, a seemingly never ending supply of them. Once we solve one, another comes up. We're starting to wonder if we'll ever get it to run. We're wondering if anyone else has.

Does anyone have a Grails 3 project actually running on any of the major supported scallable servers, such as JBoss, WebLogic, or WebSphear?

I'm starting to think they don't. I know it runs on Tomcat, that's great if you're organization has those skills internally. But many corporate IT shops want someone to call, someone to blame, if anything goes horribly wrong. For that segment of the market it has to run on the big ticket supported servers, and as far as I can tell, right now (Grails 3.1.6), it does not. 


On Wednesday, May 4, 2016 at 8:03:13 PM UTC-7, Brad Booth wrote:
Grails 3 can produce a standard war, which can be deployed in any of the major servlet containers.  It can also produce a self executing jar.  Since Grails is based on Spring Boot it can be deployed how any other Spring Boot app can be deployed.  We use tomcat and have no issues (war) as well as cloud deployments on Cloud Foundry using an executable jar.  The error you are getting is usually a classpath problem.
On Wed, May 4, 2016 at 3:29 PM, <ndn.n...@gmail.com> wrote:
Deploying Grials 3.1.16 to JBOSS EPA 6.4 failed with this error:
        java.lang.NoSuchMethodError: org.grails.orm.hibernate.cfg.CollectionType.<init>(Ljava/lang/Class;Lorg/grails/orm/hibernate/cfg/GrailsDomainBinder;)


On Wednesday, May 4, 2016 at 3:10:27 PM UTC-7, DAC wrote:
I'm several months into a new project developed in Grails 3. Now we're starting to configure a production server, but we can't seem to find any of the major prod servers that we can deploy a Grails 3 application to. By major I mean JBoss EAP, WebLogic, etc... 

Is everyone else having these issues with Grails 3?

What major production servers are others having success on with Grails 3? 

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-discuss+unsub...@googlegroups.com.

To post to this group, send email to grails-de...@googlegroups.com.

Graeme Rocher

unread,
May 5, 2016, 12:26:11 PM5/5/16
to DAC' via Grails Dev Discuss, Grails Dev Discuss
On Thu, May 5, 2016 at 5:37 PM, DAC' via Grails Dev Discuss <grails-de...@googlegroups.com> wrote:
Yes, it's a war file but it's not that simple. As you said we have a classpath, or dependency issues. The one mentioned here is just an example, there are others, a seemingly never ending supply of them. Once we solve one, another comes up. We're starting to wonder if we'll ever get it to run. We're wondering if anyone else has.

Does anyone have a Grails 3 project actually running on any of the major supported scallable servers, such as JBoss, WebLogic, or WebSphear?

I'm starting to think they don't. I know it runs on Tomcat, that's great if you're organization has those skills internally. But many corporate IT shops want someone to call, someone to blame, if anything goes horribly wrong. For that segment of the market it has to run on the big ticket supported servers, and as far as I can tell, right now (Grails 3.1.6), it does not.

On Wednesday, May 4, 2016 at 8:03:13 PM UTC-7, Brad Booth wrote:
Grails 3 can produce a standard war, which can be deployed in any of the major servlet containers. It can also produce a self executing jar. Since Grails is based on Spring Boot it can be deployed how any other Spring Boot app can be deployed. We use tomcat and have no issues (war) as well as cloud deployments on Cloud Foundry using an executable jar. The error you are getting is usually a classpath problem.
On Wed, May 4, 2016 at 3:29 PM, <ndn.n...@gmail.com> wrote:
Deploying Grials 3.1.16 to JBOSS EPA 6.4 failed with this error:
java.lang.NoSuchMethodError: org.grails.orm.hibernate.cfg.CollectionType.<init>(Ljava/lang/Class;Lorg/grails/orm/hibernate/cfg/GrailsDomainBinder;)


On Wednesday, May 4, 2016 at 3:10:27 PM UTC-7, DAC wrote:
I'm several months into a new project developed in Grails 3. Now we're starting to configure a production server, but we can't seem to find any of the major prod servers that we can deploy a Grails 3 application to. By major I mean JBoss EAP, WebLogic, etc...

Is everyone else having these issues with Grails 3?

What major production servers are others having success on with Grails 3?

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-disc...@googlegroups.com.

To post to this group, send email to grails-de...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-disc...@googlegroups.com.

To post to this group, send email to grails-de...@googlegroups.com.

DAC

unread,
May 5, 2016, 1:11:21 PM5/5/16
to Grails Dev Discuss
Thank you Graeme, I'll apply this and reply with the results.

Be aware however, that Wildfly 10 != JBoss EAP (commercially supported version), nore will it for a long time. 

WildFly code takes years to transition over to the JBoss EAP supported version. The latest commercially supported version of JBoss EAP is a Java EE 6 certified container. I think it is somewhere around  JBoss AS 7 and/or WildFly 8 code.

For the corporate IT world the big supported servers are WebLogic, WebSphear, and JBoss EAP, not WildFly. WildFly == The Wild West, as you saw in their documentation. Corporate IT isn't going anywhere near that for any business critical application.

But I'll review your post and see if this will get me closer to running on one of the supported servers that are options for us. 


On Thursday, May 5, 2016 at 9:26:11 AM UTC-7, Graeme Rocher wrote:
Cheers

Graeme

On Thu, May 5, 2016 at 5:37 PM, DAC' via Grails Dev Discuss <grails-de...@googlegroups.com> wrote:
Yes, it's a war file but it's not that simple. As you said we have a classpath, or dependency issues. The one mentioned here is just an example, there are others, a seemingly never ending supply of them. Once we solve one, another comes up. We're starting to wonder if we'll ever get it to run. We're wondering if anyone else has.

Does anyone have a Grails 3 project actually running on any of the major supported scallable servers, such as JBoss, WebLogic, or WebSphear?

I'm starting to think they don't. I know it runs on Tomcat, that's great if you're organization has those skills internally. But many corporate IT shops want someone to call, someone to blame, if anything goes horribly wrong. For that segment of the market it has to run on the big ticket supported servers, and as far as I can tell, right now (Grails 3.1.6), it does not.

On Wednesday, May 4, 2016 at 8:03:13 PM UTC-7, Brad Booth wrote:
Grails 3 can produce a standard war, which can be deployed in any of the major servlet containers. It can also produce a self executing jar. Since Grails is based on Spring Boot it can be deployed how any other Spring Boot app can be deployed. We use tomcat and have no issues (war) as well as cloud deployments on Cloud Foundry using an executable jar. The error you are getting is usually a classpath problem.
On Wed, May 4, 2016 at 3:29 PM, <ndn.n...@gmail.com> wrote:
Deploying Grials 3.1.16 to JBOSS EPA 6.4 failed with this error:
java.lang.NoSuchMethodError: org.grails.orm.hibernate.cfg.CollectionType.<init>(Ljava/lang/Class;Lorg/grails/orm/hibernate/cfg/GrailsDomainBinder;)


On Wednesday, May 4, 2016 at 3:10:27 PM UTC-7, DAC wrote:
I'm several months into a new project developed in Grails 3. Now we're starting to configure a production server, but we can't seem to find any of the major prod servers that we can deploy a Grails 3 application to. By major I mean JBoss EAP, WebLogic, etc...

Is everyone else having these issues with Grails 3?

What major production servers are others having success on with Grails 3?

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-discuss+unsub...@googlegroups.com.

To post to this group, send email to grails-de...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-discuss+unsub...@googlegroups.com.

Graeme Rocher

unread,
May 6, 2016, 4:37:51 AM5/6/16
to DAC' via Grails Dev Discuss, Grails Dev Discuss
When I say WildFly == JBoss the techniques used to configure Grails for deployment for both JBoss and Wildfly are the same.

99% of issues found with Grails on alternative containers is to do with classpath conflicts with JARs that the container ships with it.

So for example JBoss ships with its own version of Hibernate and JTA and so on. Once you have isolated Grails from all of the stuff that JBoss includes (which typically involves tweaking the jboss-web.xml) then it will run fine.

Regards,

Graeme

Cheers

Graeme

To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-disc...@googlegroups.com.

To post to this group, send email to grails-de...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-disc...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-disc...@googlegroups.com.

To post to this group, send email to grails-de...@googlegroups.com.

DAC

unread,
May 6, 2016, 4:34:01 PM5/6/16
to Grails Dev Discuss
OK, we have success with a basic demo app on JBoss EAP 6.4.0.GA, with Hibernate 4 talking to an Oracle 12c database, but using the Oracle10gDialect. Still no joy on Hibernate 5.

We're now going to try converting our project to Hibernate 4 to see if we can then get a full project deployed on a JBoss EAP domain. Will update again after that process.
Regards,

Graeme

Cheers

Graeme

To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-discuss+unsub...@googlegroups.com.

To post to this group, send email to grails-de...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-discuss+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-discuss+unsub...@googlegroups.com.

DAC

unread,
May 10, 2016, 3:54:58 PM5/10/16
to Grails Dev Discuss
OK, after having two senior people dedicated to this for over a week, we're giving up on getting Grails 3 to run on JBoss EAP 6.4.0.GA, and going back to Grails 2.5.1. We solved many issues, and we're very close to having it running but we're still seeing a lot of URL mapping issues with JSON and with GSON views. I'm sure we could get it to run one day, but at what cost. The schedule cost that we've already taken has been too great.

Graeme, I greatly appreciate your help on the issues we've had and I wish I could justify sticking with Grails 3.

I hope that the Grails team will consider additional testing on a wider selection of app servers in the future. Although I love Grails, and really want to use 3 not 2, I just cannot justify it to my stakeholders at this time for our situation. Again our situation is app server specific so just because we had this much trouble does not mean that other groups will if they are not constrained on server selection. 

Thanks again. 

Graeme Rocher

unread,
May 11, 2016, 12:38:21 PM5/11/16
to DAC' via Grails Dev Discuss, Grails Dev Discuss
You could always engage OCi, we’d be happy to help you get up and running.

Apart of that I have not seen any issue reports from yourself. If you provide us with a simple example in a github repo in an issue report that reproduces the issue you are seeing on JBoss we would be happy to take a look.

Regards,

Graeme

Regards,

Graeme

Cheers

Graeme

To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-disc...@googlegroups.com.

To post to this group, send email to grails-de...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-disc...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-disc...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-disc...@googlegroups.com.

To post to this group, send email to grails-de...@googlegroups.com.

DAC

unread,
May 12, 2016, 1:54:41 PM5/12/16
to Grails Dev Discuss
Thanks Graeme, but we have been posting, and you, Burt, and others have been helping us. The pattern is we track our problems to an existing open issue and then wait for a milestone release to fix it, try again, and repeat. We've been in that pattern for months. Even if we had OCi consultants here, I don't think that would change, the issues would still have to be resolved.

In Grails 3.1.1 Burt helped us with this Hibernate 5 question. After that, we identified existing open issues that had us waiting for 3.1.5, and then 3.1.6, I forget the exact issues, all opened by others, sometimes after our StackOverflow questions.

In version 3.1.6, my coworker (ndn2016) gave you feedback on issue 9783, which prompted you to open issue 9915 and assign it to Grails milestone 3.1.7. So the pattern continues, and we've got customers getting worried because we have no path to production and no ability to predict when the pattern will end.

Thanks Graeme, and to Burt also, you guys have been very helpful and I'm sure you're doing everything you can. I really wish I could stick with Grails 3, and I look forward to upgrading our projects to version 3 one day in the future. I'm just sorry that it can't be now.


Regards,

Graeme

Regards,

Graeme

Cheers

Graeme

To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-discuss+unsub...@googlegroups.com.

To post to this group, send email to grails-de...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-discuss+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-discuss+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-discuss+unsub...@googlegroups.com.

Frédéric Henri

unread,
May 12, 2016, 2:12:13 PM5/12/16
to grails-de...@googlegroups.com
hey ‘DAC’,

I am not affiliate with OCI in any case.

There’s a big difference between getting support through mailing list, Stack Overflow, github issues and a commercial engagement from a company that support the framework (and in this case you get THE company with the guys that made the product) - up to you to review your issue and define the engagement if they can commit.

No one will commit on anything through the open-source channel, thats the basic idea - some people dont like it at all and go for commercial product.

It seems in your company you believe in non-open source product, or take the commercial product for support when there’s one (your example with wildly) so just act the same for the  framework you use and get a commercial support for it.

Thanks,
Fred

To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-disc...@googlegroups.com.

To post to this group, send email to grails-de...@googlegroups.com.

DAC

unread,
May 12, 2016, 3:39:16 PM5/12/16
to Grails Dev Discuss
Hi Frederic,

I don't think commercial Grails support would help. It's not that we don't know what's wrong, we know exactly what is wrong, at the moment (3.1.6) it is issue 9915 which has been added the the 3.1.7 milestone. What would be the point of paid support, they'd just tell me what I already know and encourage me to wait for the next milestone, which is what we've been doing for the last several milestones.

I agree with you that our server team is different than our software development team in the fact that the server team requires paid support and our software team does not, but in my experience (corporate IT) that is not that unusual. When the end product must be highly available, scalable, and is business or mission critical, you do not normally find middle level managers who are willing to shoulder all of that risk on their own internal human resources. For whatever reasons, this is not usually the case with the software development branch of the organization. No one ever expects new software developed in the next few minutes, but they do expect down servers to be back on-line in the next few minutes. 



Jeff Scott Brown

unread,
May 12, 2016, 4:23:02 PM5/12/16
to grails-de...@googlegroups.com

> On May 12, 2016, at 12:39 PM, 'DAC' via Grails Dev Discuss <grails-de...@googlegroups.com> wrote:
>
> Hi Frederic,
>
> I don't think commercial Grails support would help. It's not that we don't know what's wrong, we know exactly what is wrong, at the moment (3.1.6) it is issue 9915 which has been added the the 3.1.7 milestone.

You said “...but we're still seeing a lot of URL mapping issues with JSON and with GSON views.”.

Has that since been resolved?



JSB


Jeff Scott Brown
Principal Software Engineer
Grails Development Team
Object Computing Inc.
http://www.ociweb.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

DAC

unread,
May 12, 2016, 7:40:45 PM5/12/16
to Grails Dev Discuss
No, I do not believe the URL mapping issues we were seeing have been resolved. We were using the web profile with the assetPipeline, jsonViews, and hibernate features. It ran fine on localhost but on the latest version of JBoss EAP we had multiple .gson view files that did not get the correct URL mapping. I'll try to find time to checkout back to that version and get a URL mapping report and post it. 

Jeff Scott Brown

unread,
May 12, 2016, 8:28:58 PM5/12/16
to grails-de...@googlegroups.com

> On May 12, 2016, at 12:39 PM, 'DAC' via Grails Dev Discuss <grails-de...@googlegroups.com> wrote:
>
> What would be the point of paid support, they'd just tell me what I already know and encourage me to wait for the next milestone, which is what we've been doing for the last several milestones.

I don’t know where that information came from but it isn’t correct. That is not how our support requests are handled. I don’t think we have ever handled a support request that way. Paid support requests are prioritized, someone is assigned to the issue until it is resolved, we work with the client to help validate the fix, then we ship it. As part of the diagnostic process, if a workaround is identified we relay that in the meantime.

Jeff Scott Brown

unread,
May 12, 2016, 8:30:53 PM5/12/16
to grails-de...@googlegroups.com

> On May 12, 2016, at 4:40 PM, 'DAC' via Grails Dev Discuss <grails-de...@googlegroups.com> wrote:
>
> It ran fine on localhost but on the latest version of JBoss EAP we had multiple .gson view files that did not get the correct URL mapping. I'll try to find time to checkout back to that version and get a URL mapping report and post it.

That would be helpful.

I don’t know what "we had multiple .gson view files that did not get the correct URL mapping” means. .gson view files generally don’t get URL mappings. If you can provide an app that demonstrates the problem, or describe it in a way that we can recreate it, we will take a look.

Thanks for the feedback.

DAC

unread,
May 13, 2016, 11:08:07 AM5/13/16
to Grails Dev Discuss
Hi Jeff,

Sounds like we're saying about the same thing, ok, so they would prioritize the fix and we'd wait a little less time for the fix, but we'd still be waiting for fixes. My point is we needed it to work back in late 2015, not mid 2016, and certainly not late 2016. We've been waiting for one fix after another. Each fix just gets us a step closer and a chance to see what else needs to get fixed. There is no way for us to predict when that cycle of fixes is going to end. We're at 3.1.6 now, and I don't believe any of the Grails 3 versions to date are compatible with the latest version of JBoss Enterprise App Server. That's a serious problem. I don't think prioritizing our issues is going to change that enough. 

DAC

unread,
May 13, 2016, 11:12:40 AM5/13/16
to Grails Dev Discuss
Hi Jeff,

Sorry, I guess I worded it poorly. I'm going from memory. I'll deploy it again and try to be more specific. Making something that I can post is very time consuming. I can't post our application, obviously. So each time I find the problem, I have to recreate the problem in a demo app and then post that. It's a tedious process. But I will go through one more iteration for the sake of the community and since you're asking. 

I do very much appreciate your interest and everyone's help.

DAC

unread,
May 13, 2016, 4:11:33 PM5/13/16
to Grails Dev Discuss
Hi Jeff,

OK, more specific information on our mapping issues. Maybe these are not actually mapping issues, but whatever the case JBoss cannot find the files.

Grails 3.1.6 profile = web, features = asset-pipeline, hibernate, and jsonViews. We have Hibernate4 configured. Works on localhost. JBoss EAP 6.4.0.GA has following issues:

1. If we have a main controller but no main directory in our view folder and instead we put index.gsp in the view root, and then in MainController.groovy we have the following: 
render view:"../index", model:[user:[id:"default"]]
This works on localhost, but on JBoss EAP it results in this error:
2016-05-13 10:11:30,148 ERROR [org.springframework.boot.context.web.ErrorPageFilter] (http-/[redacted]) Forwarding to error page from request [/] due to exception [Could not resolve view with name '/main/../index' in servlet with name 'grailsDispatcherServlet']: javax.servlet.ServletException: Could not resolve view with name '/main/../index' in servlet with name 'grailsDispatcherServlet'
The above also works in Grails 2 when deployed to JBoss EAP, but not the Grails 3 project that I specified above. In fact anything that we try to render using the ".." notation to go up one in the relative path fails. This breaks all global templates or _template.gson files that are supposed to be shared by multiple controllers/views. 

2. All json views that use a json view template from a different controller/view fail. On localhost we have to do the following relative paths or we get a template not found error. As I remember the json view documentation says that specifying the relative path to a .gson template file is not necessary, and that the it will be found by name alone, but that is not what we've found, we have to specify the relative path even on localhost. The following works on localhost but breaks on JBoss EAP.

DayTypeController.groovy:
            render view: 'dayTypeList', model: [dayTypes: dayTypeService.getDayTypesByDistrictNbr(cmd.districtNbr)]

dayTypeList.gson:
        model{
            ArrayList<DayType> dayTypes
        }
        json{
            rows g.render(template:"dayType", collection:dayTypes, var:'dayType')
        }

_dayType.gson:
        import Color
        import DayType
        
        model {
            DayType dayType
        }
        json{
            id dayType.id
            version dayType.version
            description dayType.description
            code dayType.code
            workingFlag dayType.workdayFlag
            activeFlag dayType.activeFlag
            district g.render(template:"../districtList", model:[district:dayType.district])
            color g.render(template:"../system/color", model:[color:(Color) dayType.color])
            category g.render(template:"../dayType/dayTypeCategory", model:[dayTypeCategory:dayType.category])
        }


But when we get to JBoss EAP these all break, presumably because of the .. in the relative path.

We get the following error message in the JBoss EAP log file:
2016-05-13 12:52:28,027 ERROR [org.springframework.boot.context.web.ErrorPageFilter] ([redacted]) Forwarding to error page from request [/dayType/getDayTypesByDistrictNbr] due to exception [javax/servlet/http/HttpUpgradeHandler]: java.lang.NoClassDefFoundError: javax/servlet/http/HttpUpgradeHandler
at java.lang.Class.getDeclaredMethods0(Native Method) [rt.jar:1.8.0_60]
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) [rt.jar:1.8.0_60]
at java.lang.Class.privateGetPublicMethods(Class.java:2902) [rt.jar:1.8.0_60]
at java.lang.Class.getMethods(Class.java:1615) [rt.jar:1.8.0_60]
at java.beans.Introspector.getPublicDeclaredMethods(Introspector.java:1336) [rt.jar:1.8.0_60]
at java.beans.Introspector.getTargetMethodInfo(Introspector.java:1197) [rt.jar:1.8.0_60]
at java.beans.Introspector.getBeanInfo(Introspector.java:426) [rt.jar:1.8.0_60]
at java.beans.Introspector.getBeanInfo(Introspector.java:173) [rt.jar:1.8.0_60]
at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:3289) [groovy-2.4.6.jar:2.4.6]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_60]
at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:3287) [groovy-2.4.6.jar:2.4.6]
at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:3263) [groovy-2.4.6.jar:2.4.6]
at org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:254) [groovy-2.4.6.jar:2.4.6]
at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:285) [groovy-2.4.6.jar:2.4.6]
at grails.views.mvc.GenericGroovyTemplateView$HttpViewRequest.$getStaticMetaClass(GenericGroovyTemplateView.groovy) [views-core-1.0.9.jar:]
at grails.views.mvc.GenericGroovyTemplateView$HttpViewRequest.<init>(GenericGroovyTemplateView.groovy) [views-core-1.0.9.jar:]
at grails.views.mvc.GenericGroovyTemplateView.prepareWritable(GenericGroovyTemplateView.groovy:96) [views-core-1.0.9.jar:]
at grails.views.mvc.GenericGroovyTemplateView.renderMergedOutputModel(GenericGroovyTemplateView.groovy:59) [views-core-1.0.9.jar:]
at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:303) [spring-webmvc-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1243) [spring-webmvc-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.springframework.web.servlet.DispatcherServlet.processDispatchResult(DispatcherServlet.java:1027) [spring-webmvc-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:971) [spring-webmvc-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:893) [spring-webmvc-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:968) [spring-webmvc-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:870) [spring-webmvc-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:844) [spring-webmvc-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.springframework.boot.actuate.autoconfigure.EndpointWebMvcAutoConfiguration$ApplicationContextHeaderFilter.doFilterInternal(EndpointWebMvcAutoConfiguration.java:237) [spring-boot-actuator-1.3.3.RELEASE.jar:1.3.3.RELEASE]
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.springframework.boot.actuate.trace.WebRequestTraceFilter.doFilterInternal(WebRequestTraceFilter.java:112) [spring-boot-actuator-1.3.3.RELEASE.jar:1.3.3.RELEASE]
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.grails.web.servlet.mvc.GrailsWebRequestFilter.doFilterInternal(GrailsWebRequestFilter.java:75) [grails-web-mvc-3.1.6.jar:3.1.6]
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.grails.web.filters.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:67) [grails-web-mvc-3.1.6.jar:3.1.6]
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:121) [spring-web-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.springframework.boot.actuate.autoconfigure.MetricsFilter.doFilterInternal(MetricsFilter.java:103) [spring-boot-actuator-1.3.3.RELEASE.jar:1.3.3.RELEASE]
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.springframework.boot.context.web.ErrorPageFilter.doFilter(ErrorPageFilter.java:120) [spring-boot-1.3.3.RELEASE.jar:1.3.3.RELEASE]
at org.springframework.boot.context.web.ErrorPageFilter.access$000(ErrorPageFilter.java:61) [spring-boot-1.3.3.RELEASE.jar:1.3.3.RELEASE]
at org.springframework.boot.context.web.ErrorPageFilter$1.doFilterInternal(ErrorPageFilter.java:95) [spring-boot-1.3.3.RELEASE.jar:1.3.3.RELEASE]
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.springframework.boot.context.web.ErrorPageFilter.doFilter(ErrorPageFilter.java:113) [spring-boot-1.3.3.RELEASE.jar:1.3.3.RELEASE]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
Caused by: java.lang.ClassNotFoundException: javax.servlet.http.HttpUpgradeHandler from [Module "deployment.GalaxyEta.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.6.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.6.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.6.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.6.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.6.Final-redhat-1]
... 72 more

Here's our mappings-report, but as you said, I don't think this is related:

        Dynamic Mappings
         |    *     | ERROR: 500                                        | View:   /error           |
         |    *     | /${controller}/${action}?/${id}?(.${format)?      | Action: (default action) |
        
        Controller: main
         |    *     | /                                                 | Action: index            |
        
        
Hope this helps. Thanks again for everyone's help.

DAC

unread,
May 13, 2016, 4:33:22 PM5/13/16
to Grails Dev Discuss
I have a process to duplicate this in a new app. I will create an issue for it. 

DAC

unread,
May 13, 2016, 5:24:45 PM5/13/16
to Grails Dev Discuss
I have created issue 9931 and pushed an example project to github.

Jeff Scott Brown

unread,
May 14, 2016, 11:13:00 AM5/14/16
to grails-de...@googlegroups.com
I am not setup to test it right now but the problem might be related to specifying a path relative to a directory that doesn't exist. Do you know if it works after replacing "render view: '../index'" with "render view: '/index'"?

Thanks for the feedback. 



JSB

Sent from my iPhone
--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-disc...@googlegroups.com.

To post to this group, send email to grails-de...@googlegroups.com.

DAC

unread,
May 16, 2016, 4:58:40 PM5/16/16
to Grails Dev Discuss
Hi Jeff,

Thank you. OK, so it was not just the /main/index view but every view in the application that attempted to use the "../" path. So if I removed all of those across the entire application, now, my index page will come up on JBoss EAP. So thanks very much for that. However, now that I got that far, now I can see that none of the Jason Views will render at all. I get the below stacktrace when attempting to render a Jason View (.gson file).

So I guess I need to upload a demo app for that to GitHub and open an issue for that also. I will try to find time to do that. 


2016-05-16 13:29:34,103 ERROR [org.springframework.boot.context.web.ErrorPageFilter] ([redacted]) Forwarding to error page from request [/calendar/getCalendar] due to exception [javax/servlet/http/HttpUpgradeHandler]: java.lang.NoClassDefFoundError: javax/servlet/http/HttpUpgradeHandler
at java.lang.Class.getDeclaredMethods0(Native Method) [rt.jar:1.8.0_60]
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) [rt.jar:1.8.0_60]
at java.lang.Class.privateGetPublicMethods(Class.java:2902) [rt.jar:1.8.0_60]
at java.lang.Class.getMethods(Class.java:1615) [rt.jar:1.8.0_60]
at java.beans.Introspector.getPublicDeclaredMethods(Introspector.java:1336) [rt.jar:1.8.0_60]
at java.beans.Introspector.getTargetMethodInfo(Introspector.java:1197) [rt.jar:1.8.0_60]
at java.beans.Introspector.getBeanInfo(Introspector.java:426) [rt.jar:1.8.0_60]
at java.beans.Introspector.getBeanInfo(Introspector.java:173) [rt.jar:1.8.0_60]
at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:3289) [groovy-2.4.6.jar:2.4.6]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_60]
at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:3287) [groovy-2.4.6.jar:2.4.6]
at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:3263) [groovy-2.4.6.jar:2.4.6]
at org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:254) [groovy-2.4.6.jar:2.4.6]
at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:285) [groovy-2.4.6.jar:2.4.6]
at grails.views.mvc.GenericGroovyTemplateView$HttpViewRequest.$getStaticMetaClass(GenericGroovyTemplateView.groovy) [views-core-1.0.9.jar:]
at grails.views.mvc.GenericGroovyTemplateView$HttpViewRequest.<init>(GenericGroovyTemplateView.groovy) [views-core-1.0.9.jar:]
at grails.views.mvc.GenericGroovyTemplateView.prepareWritable(GenericGroovyTemplateView.groovy:96) [views-core-1.0.9.jar:]
at grails.views.mvc.GenericGroovyTemplateView.renderMergedOutputModel(GenericGroovyTemplateView.groovy:59) [views-core-1.0.9.jar:]
at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:303) [spring-webmvc-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1243) [spring-webmvc-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.springframework.web.servlet.DispatcherServlet.processDispatchResult(DispatcherServlet.java:1027) [spring-webmvc-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:971) [spring-webmvc-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:893) [spring-webmvc-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:968) [spring-webmvc-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:859) [spring-webmvc-4.2.5.RELEASE.jar:4.2.5.RELEASE]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
Caused by: java.lang.ClassNotFoundException: javax.servlet.http.HttpUpgradeHandler from [Module "deployment.[redacted].war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.6.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.6.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.6.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.6.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.6.Final-redhat-1]
... 72 more


Caused by: java.lang.ClassNotFoundException: javax.servlet.http.HttpUpgradeHandler from [Module "deployment.[redacted]war:main" from Service Module Loader]
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-discuss+unsub...@googlegroups.com.

Jeff Scott Brown

unread,
May 16, 2016, 6:36:06 PM5/16/16
to grails-de...@googlegroups.com

> On May 16, 2016, at 3:58 PM, 'DAC' via Grails Dev Discuss <grails-de...@googlegroups.com> wrote:
>
> Hi Jeff,
>
> Thank you. OK, so it was not just the /main/index view but every view in the application that attempted to use the "../" path. So if I removed all of those across the entire application, now, my index page will come up on JBoss EAP. So thanks very much for that.

No problem. I saw your comment earlier in the thread…

“...after having two senior people dedicated to this for over a week, we're giving up…”

I am sorry that we didn’t have the details sooner. As soon as I saw your description of the problem, that relative path issue jumped out at me. In any case, I am glad that issue is worked out now.



> However, now that I got that far, now I can see that none of the Jason Views will render at all. I get the below stacktrace when attempting to render a Jason View (.gson file).
>
> So I guess I need to upload a demo app for that to GitHub and open an issue for that also. I will try to find time to do that.
>
>
> 2016-05-16 13:29:34,103 ERROR [org.springframework.boot.context.web.ErrorPageFilter] ([redacted]) Forwarding to error page from request [/calendar/getCalendar] due to exception [javax/servlet/http/HttpUpgradeHandler]: java.lang.NoClassDefFoundError: javax/servlet/http/HttpUpgradeHandler

This is usually because of a dependency version incompatibility. Which version of the servlet api are you using?

DAC

unread,
May 17, 2016, 11:34:29 AM5/17/16
to Grails Dev Discuss
Hi Jeff,

Thanks again. 

JBoss EAP 6 uses Java Servlet 3.0

In a side note, while checking that I just noticed that JBoss EAP 7 is in release now. 

Jeff Scott Brown

unread,
May 17, 2016, 11:49:08 AM5/17/16
to grails-de...@googlegroups.com

> On May 17, 2016, at 10:34 AM, 'DAC' via Grails Dev Discuss <grails-de...@googlegroups.com> wrote:
>
> Hi Jeff,
>
> Thanks again.
>
> JBoss EAP 6 uses Java Servlet 3.0
> https://access.redhat.com/articles/113373
>

The HttpUpgradeHandler issue is likely because you are compiling your GSON views against Servlet 3.1 but deploying against a container that supports only Servlet 3.0. If you correct the project dependencies, I expect that will solve the issue.

DAC

unread,
May 18, 2016, 1:44:18 PM5/18/16
to Grails Dev Discuss
I tried this: gspCompile "javax.servlet:javax.servlet-api:3.0.1" but got other errors. The dependency-report only lists the servlet-api in the gspCompile configuration, so I assumed that was only place to change it. I also tried compile "javax.servlet:javax.servlet-api:3.0.1", but did not succeed with that either. Am I configuring it wrong?

Jasen Jacobsen

unread,
Oct 18, 2016, 12:59:54 PM10/18/16
to Grails Dev Discuss
Grails 3.1.9 doesn't work with EAP 7. I have a 3.1.9 app I'd like to deploy to EAP and can't get it to work. I've Googled and found Graeme's blog posts about deploying to Wildfly, and other tips, but nothing has worked.

- Jasen.
Reply all
Reply to author
Forward
0 new messages