gradle-tomcat-plugin icon indicating copy to clipboard operation
gradle-tomcat-plugin copied to clipboard

no web.xml, WebApplicationInitializer

Open staleks opened this issue 11 years ago • 15 comments

Hi Benjamin,

today I've tried to access You by Twitter, regarding this issue.

I've created the public repository @github: https://github.com/staleks/gradleTomcatPlugin

I've first tried with Jetty plugin for gradle, but I've red somewhere that Jetty plugin doesn't support this.(no web.xml) That is why I switched to tomcat plugin.

Please read README.md in provided repo, and if you are missing some pieces I will be glad to help you. Just want to solve this issue.

I'm preparing extensive Gradle POC for my company and would like to present some nice features of Gradle in NoviSad JUG. So it would be nice if this works by then.

Thank You

staleks avatar Oct 13 '14 20:10 staleks

Without looking deeper this is probably the same or a related issue as #104 and #64. If it doesn't work now it's a bug I guess.

bmuschko avatar Oct 14 '14 15:10 bmuschko

well it might be the case, but I guess providing web.xml and implementing WebInitializer is confronting one another.

In my case, I want to skip XML at all, if possible.

That is why I do not have web.xml, only implementation of WebInitializer.

staleks avatar Oct 14 '14 15:10 staleks

I've created another branch: https://github.com/staleks/gradleTomcatPlugin/tree/gretty-branch where is same project, except I'm now using gretty plugin, instead of tomcat plugin.

Now I have issue that classes from core project is not visible in web :(

I will try more.... Stay tuned.

staleks avatar Oct 14 '14 15:10 staleks

At the moment I do not have a lot of time to look into this issue for my plugin. I'd love for other people to contribute. If you feel you want to dig deeper, I'd appreciate your time and contribution.

bmuschko avatar Oct 14 '14 15:10 bmuschko

can you at least check am I using plugin as intend?

staleks avatar Oct 14 '14 20:10 staleks

The problem is solved by using additional package in ComponentScan annotation:

@Configuration
@ComponentScan(basePackages = {"rs.in.staleksit.foo.web.controller", "rs.in.staleksit.foo.service"})
@EnableWebMvc
public class FooWebMvcConfig extends WebMvcConfigurerAdapter {
  // ...
}

akhikhl avatar Oct 14 '14 21:10 akhikhl

@akhikhl Does that fix it for both plugins? Which one are you referring to?

bmuschko avatar Oct 14 '14 21:10 bmuschko

There was concrete bug: "org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'userController' defined in file...", which is spring-specific, not gradle-specific.

akhikhl avatar Oct 14 '14 21:10 akhikhl

So yes, fix is for both plugins in a sense, that the problem is not related to gradle plugins.

akhikhl avatar Oct 14 '14 21:10 akhikhl

Uhm... Sorry, it was more workaround, not an issue. Explanation: Adding package to the ComponentScan just forces spring "scan this, scan that". The real problem was with Profile annotation, not with scan. Proof: as soon as you disable Profile annotation, FooCoreConfig is automatically discovered and no error occurs. The real source of the problem was passing -Dspring.profiles.active=development to a running web-app. I don't know how gradle-tomcat-plugin does it, but Gretty does not pass JVM arguments to web-app automatically. As a consequence, the profile is not activated and FooCoreConfig is not visible to spring. Solution (Gretty):

gretty {
  jvmArg '-Dspring.profiles.active=development'
}

akhikhl avatar Oct 14 '14 22:10 akhikhl

So it was not spring problem but actually I was not aware of this property for gretty plugin. On Oct 15, 2014 12:19 AM, "Andrey Hihlovskiy" [email protected] wrote:

Uhm... Sorry, it was more workaround, not an issue. Explanation: Adding package to the ComponentScan just forces spring "scan this, scan that". The real problem was with Profile annotation, not with scan. Proof: as soon as you disable Profile annotation, FooCoreConfig is automatically discovered and no error occurs. The real source of the problem was passing -Dspring.profiles.active=development to a running web-app. I don't know how gradle-tomcat-plugin does it, but Gretty does not pass JVM arguments to web-app automatically. As a consequence, the profile is not activated and FooCoreConfig is not visible to spring. Solution (Gretty):

gretty { jvmArg '-Dspring.profiles.active=development'}

— Reply to this email directly or view it on GitHub https://github.com/bmuschko/gradle-tomcat-plugin/issues/110#issuecomment-59126843 .

staleks avatar Oct 14 '14 22:10 staleks

Yes, you are right. Sorry for too quick, too wrong first answer :smile_cat:

akhikhl avatar Oct 15 '14 07:10 akhikhl

Anyway, is it hard to make this working from command line? I'm wondering, now my build.gradle (in web project) MUST be changed if I want different profile active. It would be better if we don't need to change code itself. Do you agree with me?

staleks avatar Oct 15 '14 07:10 staleks

ok, minor update, I want to separate discussion of tomcat gradle plugin and gretty plugin. @benjamin:sorry that we overtook your github repository for this :)

Now: I have created two github repositories Tomcat Gradle Plugin https://github.com/staleks/gradleTomcatPlugin

Status: still not working

and Gretty Gradle Plugin https://github.com/staleks/gradle-gretty-plugin

Status: working, but possible improvements noticed

staleks avatar Oct 15 '14 07:10 staleks

I opened new issue: https://github.com/akhikhl/gretty/issues/99

akhikhl avatar Oct 15 '14 08:10 akhikhl