Skip to content
This repository has been archived by the owner on Oct 12, 2023. It is now read-only.

no web.xml, WebApplicationInitializer #110

Open
staleks opened this issue Oct 13, 2014 · 15 comments
Open

no web.xml, WebApplicationInitializer #110

staleks opened this issue Oct 13, 2014 · 15 comments

Comments

@staleks
Copy link

staleks commented Oct 13, 2014

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

@bmuschko
Copy link
Owner

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.

@staleks
Copy link
Author

staleks commented Oct 14, 2014

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
Copy link
Author

staleks commented Oct 14, 2014

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.

@bmuschko
Copy link
Owner

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.

@staleks
Copy link
Author

staleks commented Oct 14, 2014

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

@akhikhl
Copy link

akhikhl commented Oct 14, 2014

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 {
  // ...
}

@bmuschko
Copy link
Owner

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

@akhikhl
Copy link

akhikhl commented Oct 14, 2014

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
Copy link

akhikhl commented Oct 14, 2014

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

@akhikhl
Copy link

akhikhl commented Oct 14, 2014

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'
}

@staleks
Copy link
Author

staleks commented Oct 14, 2014

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
#110 (comment)
.

@akhikhl
Copy link

akhikhl commented Oct 15, 2014

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

@staleks
Copy link
Author

staleks commented Oct 15, 2014

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
Copy link
Author

staleks commented Oct 15, 2014

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

@akhikhl
Copy link

akhikhl commented Oct 15, 2014

I opened new issue: akhikhl/gretty#99

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants