Generator-jhipster: styling errors on Tomcat after upgrade to 5.4.2 when packaging for prod

[tibistibi]

updated it after bellow investigation:

Overview of the issue

After doing an upgrade from 5.3.1 to 5.4.2 all seemed to work fine when working from my developer machine, but after doing a package and deploy to tomcat the fonts are wrong and i noticed that the main.[hash].css is empty and in a different location.
there were also strange chars comming from javascript files like nbsp; had an A in front and euro sign was strange.

firefox can not find the man.*.css file which is empty

Besides moving from 5.3.1 to 5.4.2 i also switched from yarn to npm.

i have found end of pipeline solutions to my problems but did not find root cause.

1) the fonts were back when i added !important, this suggests the order is different than before i did the upgrade
2) i needed to add charset="UTF-8" to the script import tags in the index.html files. i do not know why this is needed now and not in the previous version.
Adding this by hand is not good is there a way to add this automatically or make it not needed any more?

JHipster Version(s)

5.4.2

JHipster configuration

jhipster info
Using JHipster version installed locally in current project's node_modules
Executing jhipster:info
Options:
Welcome to the JHipster Information Sub-Generator

JHipster Version(s)

[email protected] /home/tibi/git/standBystand
└── (empty)

##### **JHipster configuration, a `.yo-rc.json` file generated in the root folder**

.yo-rc.json file

Environment and Tools

openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-0ubuntu0.18.04.1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

git version 2.17.1

node: v8.11.3

npm: 6.2.0

yeoman: 2.0.5

yarn: 1.9.4

.yo-rc.json:

{
"generator-jhipster": {
"promptValues": {
"packageName": "nl.tibi.sbys",
"nativeLanguage": "en"
},
"jhipsterVersion": "5.4.2",
"baseName": "standBystand",
"packageName": "nl.tibi.sbys",
"packageFolder": "nl/tibi/sbys",
"serverPort": "8080",
"authenticationType": "session",
"cacheProvider": "ehcache",
"enableHibernateCache": true,
"websocket": false,
"databaseType": "sql",
"devDatabaseType": "mysql",
"prodDatabaseType": "mysql",
"searchEngine": false,
"messageBroker": false,
"serviceDiscoveryType": false,
"buildTool": "maven",
"enableSocialSignIn": true,
"enableSwaggerCodegen": false,
"rememberMeKey": "xxxxxxxxxx",
"clientFramework": "angularX",
"useSass": false,
"clientPackageManager": "npm",
"applicationType": "monolith",
"testFrameworks": [],
"jhiPrefix": "jhi",
"enableTranslation": true,
"nativeLanguage": "en",
"languages": [
"en",
"nl",
"de"
]
}
}

Browsers and Operating System

ubuntu 18.04

• [x] Checking this box is mandatory (this is just to show you read everything)

[tibistibi]

after going back to before the upgrade and doing a package build i noticed there is a
main.16cf598e4d24ff55b1e2.css file generated in target/www/content with the bootstrap css in there.

with the 5.4.2 code i get:
main.5a7876d2ad775f6b3a6b.css which is empty in
target/classes/public
and one in
myapp/WEB-INF/classes/public

[tibistibi]

ps this is the website: https://staging.standbystand.eu/sbys/#

not sure why my browser is complaining it can not open the css file and if it is the problem of the font not working.

[tibistibi]

and one more issue i noticed is that with the compression wired signes are added. like this:
×
is tranformed into this:
×

(on chrome)

[tibistibi]

so adding !important to the font-family helped, i guess the order is some where changed not sure if this is an issue but it makes it different on local machine to live/staging.

firefox seems to have an issue opening an empty css file complaining it can not be found. i do not think its a blocking issue but why is the main.*.css empty?

[tibistibi]

The × instead of spaces or x could be becasue of this:
https://stackoverflow.com/questions/1461907/html-encoding-issues-%C3%82-character-showing-up-instead-of-nbsp

[wmarques]

@tibistibi it's maybe related with https://github.com/jhipster/generator-jhipster/pull/8402/files
Can you try to change the chunk order ?

[tibistibi]

thanks!

could that also solve the × ??

[tibistibi]

i did not help :cry:

so adding !important is still needed to overwrite the font and more worrying is the strange signes in chrome (staging packaged):

instead of (dev)

both on the same chrome browser but one is dev environment and the other is on staging (packaged)

on firefox it looks fine on both dev and staging.

any help would be great!

(i added the PPP QQQ and DDD to make it easy to find them in source code)

[tibistibi]

firefox on ubuntu is working but on mac is also showing the strange a's

[tibistibi]

could it be possible that in the response header the content type is not set?
chrome gives this for the page:

Content-type: text/html;charset=ISO-8859-1

[tibistibi]

if i look at the source code of the main.*.js file in the browser i see the same chars there:

[tibistibi]

to investigate more i changed the file to html file and than it is loaded fine. so some how js files seem not to be loaded with utf-8 charset

[tibistibi]

i added this and seems to improve it on my env but not with colleague:

[tibistibi]

ok had to add the charset="UTF-8" for all js files and no strange chars are gone.

i added it by hand now. is there a way to do this automatically?

[deepu105]

@tibistibi I'm not sure we need to check the webpack plugin doing the injection. Can you confirm that the issue is only with Firefox on Ubuntu? I'm on Fedora and I have never seen anything like it.

[tibistibi]

it is in firefox and chrome on ubuntu and on mac

[deepu105]

@tibistibi thats weird, then how come none of the core dev team members are seeing this, most of them are on mac. There is something fishy here. Someone needs to reproduce this.

[deepu105]

@tibistibi I see that there is no info on your ticket for us to actually reproduce this, can you please follow our issue guidelines and post all the info

[deepu105]

@tibistibi also seems you are deploying to tomcat, thats not our default setup so please clearly provide steps to reproduce

[tibistibi]

i added them on staging home page interesting to see if your browser is show correct or wrong:
@deepu105 thanks for getting into this!

https://staging.standbystand.eu/sbys/#/freelancerHome
at the end of the page. i see this:

[tibistibi]

So to reproduce this i add signs like this: ' ' '€' '×' (ie like this:   € ×)

i build like this:
./mvnw -Pprod clean package

and deploy to tomact.

i did not have these problems a week ago when i was on 5.3.1 so i do not expect that tomcat part of it.

[deepu105]

I don't see any issues in my browsers(chrome/FF)
You are still not following the guidelines, please update the required details otherwise there is nothing we can do to help. You should also start looking at your browser/OS encoding/locale settings

[deepu105]

Oh wait ok I see the weird chars on the freelancerHome page, but we still dont have any details to reproduce this so please update them and give clear instructions please

[tibistibi]

ok cool so you see them too :+1:

if you would not there would be no point in reproducing it.

i'm trying a different project to see if the same happens but because it needs to be deployed it will take some time...

[tibistibi]

i'm not sure what information you need more than this:

So to reproduce this i add signs like this: ' ' '€' '×' (ie like this:   € ×)
for example to home.component.html

i build like this:
./mvnw -Pprod clean package

and deploy to tomcat.

i did not have these problems a week ago when i was on 5.3.1 so i do not expect that tomcat part of it.

[deepu105]

@tibistibi your .yo-rc.json for a start, entity config if applicable, basically everything that we ask in the issue template, may be you tried to follow it but ran the jhipster info command on the wrong folder?

[tibistibi]

ah ok, i removed my model because i do not expect it to be a part of the problem.

i will add my .you-rc.json file

[deepu105]

also please try to create a fresh app with the same yo-rc, and run it locally and see if the same issue is present

[tibistibi]

yes working on that

[tibistibi]

with a fresh install with the same yo-rc i do not have the problem, so i guess it is something with the upgrade going from 5.3.1 to 5.4.2 or before that...

is there an area i should look into?

[tibistibi]

i might have made a mistake the .yo-rc.json file i used is like above with verions 5.4.2
but the generated package.json has "generator-jhipster": "5.3.1",

i created a new dir added the .yo-rc.json file and ran jhipster no questions asked...

[tibistibi]

i upgraded the app with jhipster now it is on 5.5.0.

i will upgrade my own application too maybe that will help and at least i can compare the apps than.

[tibistibi]

both are upgraded the new one works and my app has the strange chars.

what i do not understand is that the package.json is different for both applications. i would expect that upgrade would be the same on both

[tibistibi]

i copied the one from the working app over to my app but still same problem.

[pascalgrimaud]

Sorry, but we're not in a discussion room here. Plz try to be consistent each time you post a message, instead of X messages with 0 information we could use to reproduce.

It seems the problem comes from your upgrade, so it's your code.
Unless you can prove us there is a real bug, in that case, give ALL step to reproduce, or better, push a generated project on GitHub.

[deepu105]

@tibistibi to me it doesn't seem like a jHipster issue since you are unable to reproduce on a fresh app as well so I suggest you look into your customizations closely. I you still need help I suggest to take it to stack overflow as this is not a JH bug

[tibistibi]

@pascalgrimaud yes sorry about me puzzeling but it is because i do not know where to look for this and hope there is some information here in the community. I do not want to take more time than needed but working with jhipster makes me dependant on knowledge from this community. and i'm also trying to give time back in return.

@deepu105 maybe i'm unclear but when i talk about upgrades i'm referring to upgrades done with jhipster upgrade. i know you guy's will mostly work with fresh projects and in there this problem will not happen. but when people work with jhipster they will not start over again but upgrade it with jhipster upgrade and it could be that things go wrong there.
like the package.json i would expect it would be the same after upgrading compared to new projects.

what i would like to know is where to look. there obviously is a difference between the new project and my upgraded project but which files should be interested in this case? i hope someone has an idea.

[mraible]

I would suggest using a tool like SmartSynchronize to compare your upgraded project with a new one. It’ll show you which files are different.

On Oct 17, 2018, at 05:43, Tibor Strausz [e-mail] wrote:

@pascalgrimaud yes sorry about me puzzeling but it is because i do not know where to look for this and hope there is some information here in the community. I do not want to take more time than needed but working with jhipster makes me dependant on knowledge from this community. and i'm also trying to give time back in return.

@deepu105 maybe i'm unclear but when i talk about upgrades i'm referring to upgrades done with jhipster upgrade. i know you guy's will mostly work with fresh projects and in there this project will not happen. but when people work with jhipster they will not start over again but upgrade it with jhipster upgrade and it could be that things go wrong there.
like the package.json i would expect it would be the same after upgrading compared to new projects.

what i would like to know is where to look. there obviously is a difference between the new project and my upgraded project but which files should be interested in this case? i hope someone has an idea.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[deepu105]

@tibistibi I understand but the point is without something to reproduce there is not much we can do, and in your case, I'm pretty sure the issue comes from some customizations that you have done(since a fresh app seems fine with the same config) or from some specific environment issue, so I don't understand what more you expect us to do. You have to understand that we are doing this in our free time and we can't debug every user issue. The maximum we can do is to ensure fresh apps work without issue and the jhipster tooling works fine. I don't see how an upgrade can cause this issue as well as an upgrade just regenerates the app with a new version and does a merge back.

If you can find anything solid that points to an issue in jhipster, we will be happy to help, but I don't think we have the bandwidth to look at your project and debug issues that might have been from some customizations. Hope you can understand.

if you find something solid, let me know i'll reopen the issue.

Btw another comparison tool I use is Beyond Compare, similar to what Matt suggested

[tibistibi]

@deepu105 thanks for coming back to this. this:
''upgrade just regenerates the app with a new version and does a merge back''
is already valuable information.

i will look into it coming day's, just hoped someone would say 'he maybe this change could have something to do with it'

[tibistibi]

in search of the needle i have made the haystack smaller.
a fresh new 5.5.0 jhipster project.

when i build like this:
./mvnw -Pprod clean package
i get the strange char error

./mvnw clean package
i do not have the strange chars

[deepu105]

Great, now you have something that we can try to reproduce. Is this using the same yo-rc you pasted above?

[tibistibi]

yes it took my a while. yes same yo-rc. I have it down to this line from package.json

"webpack:prod:main":  "npm run webpack -- --config webpack/webpack.prod.js --profile",
"webpack:prod": "npm run cleanup && npm run webpack:build:main && npm run clean-www",

if i change it to use webpack:build:main there is nothing wrong. there were some changes to webpack.prod.js these since 5.3.1

[tibistibi]

is there an option to try out different jhipster versions?

[deepu105]

Downgrade using npm

On Fri, 19 Oct 2018, 1:49 pm Tibor Strausz, [e-mail]
wrote:

is there an option to try out different jhipster versions?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/8586#issuecomment-431337119,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlFxJE2Zkapc7yxq3Vso225eUwndm8ks5umbw_gaJpZM4XdzRl
.

[ruddell]

@tibistibi What I do is create a directory for the app, install a specific version of jhipster with npm install [email protected], then generate a project. It prints the version it uses when generating so you know if it worked. That way I don't mess with my global installation

[pascalgrimaud]

I tried to reproduce the issue, but didn't manage. See my screenshots in dev and in prod.
As already asked, we could have a look with a generated project with start.jhipster.tech (easy to generate in 2min, and add your custom char in 2min -> less than 5min to have it) or at least, ALL steps to reproduce.

I'm closing this, because of lack of information to reproduce.

[tibistibi]

@pascalgrimaud what container did you use to test it? also tomcat?

(ps i was on vacation back now)

[tibistibi]

with the help of @ruddell i found the problem appears in version 5.4.0 before that version 5.3.4 it was still ok

[pascalgrimaud]

no, didn't test with Tomcat, only with launching the war directly, and with docker container.

I'm a bit confused here, as the title said the problem comes from upgrade, some posts said the browser, other the OS, and maybe Tomcat too

[tibistibi]

@pascalgrimaud yes sorry about that for me to it is very hard to pinpoint what the problem is (that's why i'm searching help and am very grateful for any help i have gotten).

ok so what do i know now is that it happens from version 5.4.0, before it was not there.
it happens not local but only from tomcat (i have no other containers setup so not sure if it happens else where).
from ubuntu i can see it using chrome other systems both chrome and firefox have the problem.
it happens only with production profile.

[tibistibi]

i compared the webpack.prod.js between version 5.4.0 and 5.3.4 and the diff is this part:
5.3.4

    output: {
        path: utils.root('target/www'),
        filename: 'app/[name].[hash].bundle.js',
        chunkFilename: 'app/[id].[hash].chunk.js'
    },

5.4.0

output: {
        path: utils.root('target/classes/public'),
        filename: 'app/[name].[hash].bundle.js',
        chunkFilename: 'app/[id].[hash].chunk.js'
    },

when change the path to target/www there is no problem when it is target/classes/public the strange char are there

anyone knows why?

[deepu105]

Thats weird. I have no idea why.

On Mon, 29 Oct 2018, 7:56 pm Tibor Strausz, [e-mail]
wrote:

i compared the webpack.prod.js between version 5.4.0 and 5.3.4 and the
diff is this part:
5.3.4

output: {
    path: utils.root('target/www'),
    filename: 'app/[name].[hash].bundle.js',
    chunkFilename: 'app/[id].[hash].chunk.js'
},

5.4.0

output: {
path: utils.root('target/classes/public'),
filename: 'app/[name].[hash].bundle.js',
chunkFilename: 'app/[id].[hash].chunk.js'
},

when change the path to target/www there is no problem when it is
target/classes/public the strange char are there

anyone knows why?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/8586#issuecomment-434035455,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF9cPgVKahRbVBnDwFbkKX3-LjYyfks5up09DgaJpZM4XdzRl
.

[pascalgrimaud]

it looks like this change was introduced when adding Jib support

What version of Tomcat do you use ? Do you copy war.original ?
I will retry to reproduce your issue when I have time

[tibistibi]

yes i copy war original
i will check my tomcat version.

could it be that tomcat has a slightly different encoding with different locations?

[tibistibi]

tomcat version:

Apache Tomcat/8.5.14 (Debian) | 1.8.0_162-8u162-b12-1~deb9u1-b12

[tibistibi]

yes issue #8352 introduced this change. i would expect some others to use tomcat or am i the only one?

@pascalgrimaud thanks for testing it in tomcat!

[tibistibi]

or it is with packaging that maven handles different dirs different?

[tibistibi]

i checked the files in the war file and they are the same (according to linux diff command).
i have setup two same wars in tomcat, one with the target/www and one with target/classes/public.
one will have the strang A ( just after: You don't have an account yet? )

when open de js files in chrome they both have the strange A in there (search on yet second one):

 ["You don't have an account yet?"])),(l()(),e.vb(-1,null,["Â  "]))

https://staging.standbystand.eu/sbys1/app/main.908fe75607a78700ef50.bundle.js
https://staging.standbystand.eu/sbys2/app/main.30a414d98f13fcfdcec8.bundle.js

the only diff i can find is the location of the files on the filesystem.
so my conclusion is tomcat is handling files differently if it comes from locations.

but maybe someone else can think of a logical explanation.

[LucaBernstein]

i compared the webpack.prod.js between version 5.4.0 and 5.3.4 and the diff is this part:
5.3.4

    output: {
        path: utils.root('target/www'),
        filename: 'app/[name].[hash].bundle.js',
        chunkFilename: 'app/[id].[hash].chunk.js'
    },

5.4.0

output: {
        path: utils.root('target/classes/public'),
        filename: 'app/[name].[hash].bundle.js',
        chunkFilename: 'app/[id].[hash].chunk.js'
    },

when change the path to target/www there is no problem when it is target/classes/public the strange char are there

anyone knows why?

Though I do not know why, I wanted to provide everyone else having this issue this solution: For me the strange characters, just as you have them, came after upgrading from 5.1.0 to 5.5.0.
Running locally or standalone with java -jar command I did not have this issue. Only when deploying the war file built with gradlew -Pprod bootWar to a Tomcat server (v8.5.24 e.g.) the characters appeared.

Changed the line path: utils.root('target/www'), from your snipped, which in fact was path: utils.root('build/resources/main/public'), for me to path: utils.root('build/www'),. This solved my issues (temporarily).

[tibistibi]

@LucaBernstein thanks for the update! and good to know it is reproducible.

[jdubois]

I just tested and I totally have this issue - in fact it's even worse, it can't load my front-end as there is a script error caused by a broken character.

I'm pinging @danielpetisme as he did that change, and I don't understand why:

• We've had code in the "target/www" folder for years and that was working fine
• Putting it in "target/classes/public" causes the side effect: I'm not sure, but I'm guessing this causes Spring MVC to treat them differently (src/main/resources/public is a specific folder where files are exposed through Spring MVC)

-> anybody knows a good reason for this change? Otherwise let's switch back to target/www

[tibistibi]

@jdubois super thanks for taking the time!
thanks for the info about Spring MVC and the location.

i have changed the location to the old location more than a week ago and have already released it to my live (and staging) server(s) and there seems no negative side effects.

if agreed on switching back i would be glad to make a PR

[jdubois]

Thanks @tibistibi ! Let's wait to have some feedback, in particular from @danielpetisme , and if that's OK let's switch back. This has been working for years, without a good reason I don't think we should change this.

[deepu105]

@jdubois I thought the switch was done to make jar packages work if i'm not wrong

[bnts43]

I have the same styling problems (characters display oddly on tomcat server while display normally on dev computer). I am trying to migrate from 5.0 to 5.5.

I have tried to change the webpack.prod.js file with @LucaBernstein solution but front can't even launch as @jdubois mentions

@tibistibi could you be more precise on which changes you have made to restore the right behavior?

[update]
As I'm using Maven, I have to use path: utils.root('target/www')
and it worked!
So using Maven, Tomcat as production server and JHipster 5.5, characters display correctly now.
As @LucaBernstein mentioned, solution for me was to replace:
output: { path: utils.root('target/classes/public'), filename: 'app/[name].[hash].bundle.js', chunkFilename: 'app/[id].[hash].chunk.js' },
with:
output: { path: utils.root(**'target/www'**), filename: 'app/[name].[hash].bundle.js', chunkFilename: 'app/[id].[hash].chunk.js' },

[/update]

[tibistibi]

you have two options revert to this:
webpack.prod.js

    output: {
        path: utils.root('target/www'),
        filename: 'app/[name].[hash].bundle.js',
        chunkFilename: 'app/[id].[hash].chunk.js'
    },

or open the generated code and change in the index.html the js imports like this:
add this: * charset="UTF-8" *

<script type="text/javascript" charset="UTF-8" src="app/main.22f54a2828dfd15ea9ee.bundle.js"></script> 

[bnts43]

thanks for your clarifications @tibistibi

[danielpetisme]

Sorry for this delayed answer....

For jib introduction I tried to used Spring Boot static file conventions.
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-spring-mvc-static-content
With jib introduction, the web app files are copied to src/main/resources/public.
Since some of you guys succeed to fix the issue by rollbacking the webpack config to target/www I guessed there is a configuration made somewhere using a hardcoded value target/www or www.

Can't go further right now, I'll look deeper in the coming days.

[ruddell]

There is a hardcoded target/www in WebConfigurer, it looks like servletWebServer.setDocumentRoot(root); is no longer called in production.

[danielpetisme]

@ruddell Thanks for spotting that, it looks we are close!
Do you think we can use the default values of this property:
spring.resources.static-locations=classpath:/META-INF/resources/,classpath:/resources/,classpath:/static/,classpath:/public/ # Locations of static resources.

[danielpetisme]

TL;DR
The actual config can't work, jib introduction encouraged to use a SpringMVC folder and the Servlet 3.0+ WebServers configuration (which is created before) use a document root at the WAR root. That's why the servlet engine can't find the static resources.

Long Version
The WebConfigurer config is used for Servlet 3.0+ init and IDE/maven/gradle application starting. During startup, the setLocationForStaticAssets will try to resolve target/www for IDE/maven/gradle otherwise the static assets will be resolve against the WAR root.
If you expand wars generated with the webpack configpath: utils.root('target/www'), you see that all the static file are at the top level

~/workspace/apache-tomcat-9.0.13/webapps/stand-bystand-0.0.1-SNAPSHOT-5.4.1  tree -L 1
.
├── 0.css
├── META-INF
├── WEB-INF
├── app
├── content
├── favicon.ico
├── global.b78cffba303614b4889a.css
├── i18n
├── index.html
├── main.ab469085de15d83f1422.css
├── manifest.webapp
├── precache-manifest.eee91a98f2ca90c8418cc3ccb8956c2c.js
├── robots.txt
├── service-worker.js
└── swagger-ui

That's why everything works properly.
@tibistibi could you try to build q docker image and run it, it should not work (the asssets shouldn't be served).

During Jib introduction, to take advantage of the out of the box config of Spring MVC. The static files should be in the classpath, that's why I update the generation to be on a Spring Boot MVC default location (classpath:/public). But as explained here Spring MVC is configured after the Servlets.

~/workspace/apache-tomcat-9.0.13/webapps/stand-bystand-0.0.1-SNAPSHOT-5.4.2  tree -L 4
.
├── META-INF
│   ├── MANIFEST.MF
│   ├── maven
│   │   └── nl.tibi.sbys
│   │       └── stand-bystand
│   └── war-tracker
└── WEB-INF
    ├── classes
    │   ├── META-INF
    │   │   └── build-info.properties
    │   ├── banner.txt
    │   ├── config
    │   │   ├── application-dev.yml
    │   │   ├── application-prod.yml
    │   │   ├── application-tls.yml
    │   │   ├── application.yml
    │   │   ├── liquibase
    │   │   └── tls
    │   ├── git.properties
    │   ├── i18n
    │   │   ├── messages.properties
    │   │   ├── messages_de.properties
    │   │   ├── messages_en.properties
    │   │   └── messages_nl.properties
    │   ├── logback-spring.xml
    │   ├── nl
    │   │   └── tibi
    │   ├── public
    │   │   ├── 0.css
    │   │   ├── app
    │   │   ├── content
    │   │   ├── favicon.ico
    │   │   ├── global.b78cffba303614b4889a.css
    │   │   ├── i18n
    │   │   ├── index.html
    │   │   ├── main.ab469085de15d83f1422.css
    │   │   ├── manifest.webapp
    │   │   ├── precache-manifest.1f5c2f43ef9916131892d74de65ccb66.js
    │   │   ├── precache-manifest.30544572a8005393e4c1f17bc4dff655.js
    │   │   ├── precache-manifest.32cbe9ba1f8bdc144e58ec22dfe0cb73.js
    │   │   ├── precache-manifest.6d30f90bcf4473906b6392234836c0c3.js
    │   │   ├── precache-manifest.7edc115741c4a7247afb0d29438a220c.js
    │   │   ├── robots.txt
    │   │   ├── service-worker.js
    │   │   └── swagger-ui
    │   ├── stats.html
    │   └── templates
    │       ├── error.html
    │       └── mail
    └── lib

If you want to test the above statements quickly, update webpack.dev.js with eitherpath: utils.root('target/www')orpath: utils.root('target/classes/public'),and run./mvnw clean spring-boot:run`

Solutions
1- Use a Spring MVC default location as documented root for Servlets means clean the target/www occurrences and defined choose a convention between all Spring MVC possibility. The benefit of this solution is to rely on a Spring default value/config but in the other side the www folders is working fine since long time ago. Please feel free to complete this solution since I'm not an expert of Jhipster/Spring working on a web server

2- Update jib integration to copy www into the resources location and fallback to the default behavior. This solution is not impacting the former www logic but force us to have more code (thus more code to maintain) vs an out of the box convention.

WDYT?

Note: The bug couldn't been seen in a fatjar or Docker context, funny to have wait so long to have this bug ;-). This almost means the JHipster test suites should completed with WebServers tests (using embedded versions?)

[tibistibi]

@danielpetisme 'could you try to build q docker image and run it, it should not work'
i could if i knew what to do ;)

[jdubois]

I'm sorry I didn't follow this closely enough: I'm putting a $100 bug bounty on this, in this hope that this helps solve the issue quicker.

[danielpetisme]

@tibistibi can you test the fix?

How to:

• Clone my git clone jhipster fork https://github.com/danielpetisme/generator-jhipster generator-jhipster-fix
• Switch to the git checkout fix/jib-www
• Create a folder for the app generation somewhere and move to it
• Generate an application node <YOUR_PATH>/generator-jhipster-fix/cli/cli.js

[tibistibi]

@danielpetisme i would if i understood what to do:

git clone https://github.com/danielpetisme/generator-jhipster generator-jhipster-fix.

and than 'git checkout fix/jib-www' gave me an error

[danielpetisme]

What's the error?

[tibistibi]

tibi@tibi:~/git/tmpJhipsterTest$ git checkout fix/jib-www
fatal: not a git repository (or any of the parent directories): .git

[danielpetisme]

git clone https://github.com/danielpetisme/generator-jhipster generator-jhipster-fix && cd generator-jhipster-fix && git checkout fix/jib-www && cd .. && mkdir test-app && cd test-app && node ../generator-jhipster-fix/cli/cli.js

[tibistibi]

tibi@tibi:~/git/tmpJhipsterTest/test-app$ node ../generator-jhipster-fix/cli/cli.js
module.js:549
    throw err;
    ^

Error: Cannot find module 'commander'
    at Function.Module._resolveFilename (module.js:547:15)
    at Function.Module._load (module.js:474:25)
    at Module.require (module.js:596:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/home/tibi/git/tmpJhipsterTest/generator-jhipster-fix/cli/cli.js:20:17)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)

[ruddell]

You'll also have to run npm install in the cloned generator-jhipster-fix directory if you do the above command.

You can also do the following:

mkdir test-app
cd test-app
npm install git://github.com/danielpetisme/generator-jhipster.git#fix/jib-ww

# running jhipster will use the locally installed generator from the last step (from node_modules)
jhipster

[tibistibi]

if this is closed do i still need to test this?