grails 1.2.2 and glassfish

[Cyric]

I just installed grails 1.2.2, created a war file of my application after an upgrade and tried to put in on my glassfish. I'm getting this error message (and rather fast):

An error has occurred
There is no installed container capable of handling this application com.sun.enterprise.deploy.shared.FileArchive@1e46947

Anyone else getting this or anyone able to upload to glassfish with the new grails release?

greetings
cy

[Sebastian Hohns]

just tried it with Glassfishv3. Same problem and the same error message. Looks like a general problem.

I created a JIRA for this http://jira.codehaus.org/browse/GRAILS-6096 

[Kedare]

Hello,
Same problem here with :
Java 1.6.0_18-b07 (on Windows)
Glassfish 3 (build 10)
Grails 1.2.2

The same .war works fine on Tomcat.

Thank you

[rsaddey]

Cyric wrote

I just installed grails 1.2.2, created a war file of my application after an upgrade and tried to put in on my glassfish. I'm getting this error message (and rather fast):

An error has occurred
There is no installed container capable of handling this application com.sun.enterprise.deploy.shared.FileArchive@1e46947
[...]

Hi Cyric,

GlassFish appears to choke on the OSGI Bundle declarations inserted by version 1.2.2 _GrailsWar.groovy when creating the META-INF/MANIFEST.MF.

It's way beyond my head to tell who's the culprit, but either...

* manually removing all and everything from Bundle-ManifestVersion: 2 up to and including the blank line that precedes Name: Grails Application within MANIFEST.MF, or

* commenting the section that follows // OSGi bundle headers within _GrailsWar.groovy
will allow the war to be deployed.

Regards,
Reiner

BTW: There is a post of mine explaining how to have Grails use native GlassFish logging at http://bit.ly/cgJEap

[Cyric]

Yup, that was the problem!

Thx for the quick solution, Reiner! Great job!

[Graeme Rocher-3]

Looks like we'll need to make this  configurable. Please would one of you create a JIRA to add an option to enable/disable the OSGi bundle headers

Thanks

On 29 Mar 2010, at 08:50, Cyric wrote:

>
> Yup, that was the problem!
>
> Thx for the quick solution, Reiner! Great job!
> --
> View this message in context: http://n4.nabble.com/grails-1-2-2-and-glassfish-tp1691815p1694765.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Sebastian Hohns]

https://cvs.codehaus.org/browse/GRAILS-6108

what about a more general approach to solve all these troubles with different appservers? (see FAQ http://www.grails.org/FAQ#Application Servers and more). I think it would be a good idea to introduce a environment specific option to set the targeted appserver (defaults to tomcat of course) to resolve these issues during war build. You can do a lot with maven but this would be much cleaner.

[David Castro-2]

http://jira.codehaus.org/browse/GRAILS-6096

Fix is documented there and a link to the git pull request currently submitted for review.  In short I do:

mvn clean grails:war -Dgrails.project.war.osgi.headers=false

and the war has no OSGi headers for glassfish to complain about.

On Mon, Mar 29, 2010 at 6:09 AM, Sebastian Hohns <[hidden email]> wrote:

https://cvs.codehaus.org/browse/GRAILS-6108

what about a more general approach to solve all these troubles with
different appservers? (see FAQ http://www.grails.org/FAQ#Application Servers
and more). I think it would be a good idea to introduce a environment
specific option to set the targeted appserver (defaults to tomcat of course)
to resolve these issues during war build.
--
View this message in context: http://n4.nabble.com/grails-1-2-2-and-glassfish-tp1691815p1695082.html

Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[jsherlock]

Hi,

I'm both a Grails and Glassfish newbie and I'm getting a similar problem to this using GlassfishV3 and Grails 1.3.1. Even the simplest of Grails applications (i.e. grails create-app) won't deploy on Glassfish for me. I just get this error msg in the glassfish admin console:

There is no installed container capable of handling this application com.sun.enterprise.deploy.shared.FileArchive@2e06180f

I have looked at the manifest.mf file that is generated when i run grails>war and there is no reference to OSGI anywhere.

Can't seem to get much more info about the error than that. Glassfish logs just says:

[#|2010-06-30T16:15:42.823+0100|SEVERE|glassfish3.0.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=29;_ThreadName=Thread-1;|Module type not recognized|#]
[#|2010-06-30T16:15:42.823+0100|SEVERE|glassfish3.0.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=29;_ThreadName=Thread-1;|There is no installed container capable of handling this application com.sun.enterprise.deploy.shared.FileArchive@25c3b70f|#]


I should this issue have been fixed in Grails 1.3.1?

Cheers,

J :)

[jsherlock]

Quick update in case anyone is having similar problems to me...

For some reason, any arguments I pass in to the grails scripts on the command line using -D are being ignored which would explain why this solution wasn't working for me. Same happens when running scripts in STS. Very strange...

Anyway, to get around this I added the osgi headers param to BuildConfig.groovy instead and now I can build a war without the OSGI headers by adding this to BuildConfig.groovy:

grails.project.war.osgi.headers=false

J :)

Grails version: 1.3.1
Glassfish: V3

[Jeremy Flowers]

This is still not working with Glassfish 3.0.1 and Grails 1.3.6 snapshot..
Have come to this thread in roundabout fashion via GRAILS-6096 JIRA.
Good to see idea about Bootstrap was same thinking as mine. But it needs to be fixed again for 1.3.6. I guess it got reversed out of code base..