In de.agilecoders.wicket.webjars.collectors.AssetsMap.listAssets(String), matching is done with a asset.startsWith(prefix) condition.

If folderPath := "bootstrap" and asset := "META-INF/resources/webjars/bootstrap4/4.6.1/..." then resource will match.

Does wicket-webjars need a fix ? This behavior (matching with a startsWith without a path separator does not seem to be intended; we need to check wicket-webjars expected behavior and/or unit tests).

Encountered on ft-deploy-bs5, but this issue may be present on released versions.

• To include main Bootstrap scss file in our own final scss file, we need to rename bootstrap.scss to _bootstrap.scss (to import partial file). FYI, we need a single css files to ensure the order of imports and overrides.
• To use Bootstrap js files, we need to remove import and export lines since we don't bundle it.

In both cases, when updating, we have to do this manually to make it work.

See https://github.com/ning/maven-dependency-versions-check-plugin

hibernate.xml_mapping_enabled must be linked to isXmlMappingEnabled()

truezip is in maintenance mode ; it is working fine, but we should consider migrating on another solution.

Candidates:

• trueVFS: http://truevfs.net/

Note about truezip sources:

hg clone https://bitbucket.org/christian-schlichtherle/truezip7
hg checkout 6247:a92842c1275b

When SCSS are generated at build-time, generated filename is FILE-ver-9223372036854775807.scss. This filename is constant and cached by the browser. So when a new application is delivered, new CSS file may not be retrieved by browser.

Affected application may apply one of this workaround:

• scss.static.enabled=false so that pregenerated scss are ignored
• scss pregeneration can be skipped in pom.xml : <configuration>...<skip>true</skip></configuration

First delivery will be longer (as scss must be generated). Subsequent deliveries use caffeine cache.

It would be a good practice to check if ROLE_SYSTEM gives at least one effective business-oriented role.

Where? BasicApplicationCoreSecurityConfig?
When? Server start?

In Igloo 5.0.0 / bootstrap 4 tooltip default configuration lost boundary("window") default configuration.

When tooltip are linked to tiny dom nodes, tooltip display can be erratic (tooltip blink at high speed as it is displayed/hidden continuously at a wrong place).

We should bring back default configuration.

Igloo < 5.0.0 : https://github.com/igloo-project/igloo-parent/blob/v4.4.1/igloo/igloo-components/igloo-component-wicket-bootstrap4/src/main/java/org/iglooproject/wicket/bootstrap4/markup/html/template/js/bootstrap/tooltip/BootstrapTooltip.java#L52

Igloo 5.0.0 :

This a two-fold feature:

• migrate existing tests to junit5+assertj+mockito
• keep junit4 utilities for third party project (with deprecation notice)

Current behavior

If a notification is sent to n recipients, each recipient receive its own mail (3 mails sent).

Expected behavior

One mail must be sent to the 3 recipients.

Mail sending can be splitted if recipients do not share the same locale (see INotificationRecipient and implementations), or other recipient-based mechanisms. See INotificationContentDescriptor#withContext that allows to choose INotificationContentDescriptor recipient by recipient (and so to use a common value, or a different for each recipient).

ManifestPropertySource allow to inject MANIFEST.MF into property placeholders. But it is a bit hard to use in development environment:

• maven generate MANIFEST.MF only in the archive plugin. So it is available only in JAR file.
• at least an empty MANIFEST.MF file is needed at runtime; if properties bound to MANIFEST.MF values are needed, MANIFEST.MF and the needed values must be available.

MANIFEST.MF handling was added to reuse standard mechanisms in place of doing resource filtering.

Contingency plan

• maven test does not work, as it does not use jar files to perform operations.
• a fake MANIFEST.MF is added in src/main/resources; it is replaced by the build, but there is no test to ensure this.
• Note that Eclipse build generate MANIFEST.MF in target (contrary to maven)

What can be done

• find a way to generate MANIFEST.MF earlier (maven-bundle-plugin:manifest from apache felix, but it is targetted to osgi packaging)
• reuse a targetted filtering on separated resource
• keep fake MANIFEST.MF and add an integration test

Update from 5.0.7 to 5.1.4 (fccc8db) breaks Flywaydb. The way FlywayConfiguration is managed in 5.1 prevents us to inject spring context on our Java migration.

Rollback to 5.0.7 for 1.0-SNAPSHOT. More work are needed to use 5.1.

Use a juice WS in place of phloc inliner. It allows us to generate fancy mails compatible with a larger set of user mail agent.

• juice ws: https://github.com/igloo-project/juice-ws
• wip branch: dev...ft-mail-inliner

Scenario where both hbm2ddl=update/validate and flyway initialization are used is broken if AutoConfig is used.

With this scenario, hbm2ddl can be triggered before flyway migration, so hbm2ddl=validate may fail (missing tables/fields) and hbm2ddl=update may prevent correct flyway execution.

The expected order is flyway migration, then hibernate entityManagerFactory and hbm2ddl start.

This issue is likely caused by IglooJpaMoreAutoConfig#entityManagerFactory() that replaces IglooJpaAutoConfig#entityManagerFactory(...) bean definition, but without @DependsOn("databaseInitialization"). This bean databaseInitialization triggers flyway migration.

This issue may be fixed in 2.2.0 and 2.2.1 as IglooJpaMoreAutoConfig#entityManagerFactory() now uses @ConditionalOnMissingBean.

basic-application has no default for notification.mail.sender. It triggers an INFO log:

[2018-09-06 16:13:22,037] INFO  - PropertyServiceImpl        - /console/notifications/?14-1.-sendExample - Property 'org.iglooproject.spring.property.model.ImmutablePropertyId@260a2905[declared by=Properties declared in class org.iglooproject.spring.property.SpringPropertyIds,template=<null>,key=notification.mail.sender]' has no value and default value is undefined.

Maybe we should put ${notification.mail.from} as a default value. Sender parsing code seems to be compatible with Label <address> format, so using it should be fine (only address part is used for email sending).

DataUpgrade shall no longer use Parameter entity to keep track of their execution. Parameter table must only be used for mutable properties storage.

We need a decidated entity with the following information:

• String name
• boolean done (or any better attribut name)
• Date date (or any better attribut name) - Useful in flyway context to order DataUpgrade to execute.
• boolean auto (or any better attribut name) - To label DataUpgrade executed by flyway.

It will likely be necessary to update ConsoleMaintenanceDonneesPage (both BS4 and BS3 version), it would be nice to have both manual and auto perform DataUpgrade lists (with data fetch from DB).

Query in storage-unit-split.sql is broken for split on StorageUnit size. JOIN condition is missing, so split is done on total size.

JOIN condition must be fixed, and a test must be added to ensure correct behavior.

ScssServiceImpl with a jar resource fails with a NPE. For resource accessible as a classic filesystem path, there is no issue.

java.lang.IllegalStateException: Error generating org.iglooproject.sass.cli.ScssMain:test.scss
	at org.iglooproject.sass.cli.ScssMain.processScss(ScssMain.java:116)
	at org.iglooproject.sass.cli.ScssMain.call(ScssMain.java:81)
	at org.iglooproject.sass.cli.ScssMain.call(ScssMain.java:25)
	at picocli.CommandLine.executeUserObject(CommandLine.java:2041)
	at picocli.CommandLine.access$1500(CommandLine.java:148)
	at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2461)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2453)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2415)
	at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2273)
	at picocli.CommandLine$RunLast.execute(CommandLine.java:2417)
	at picocli.CommandLine.execute(CommandLine.java:2170)
	at org.iglooproject.sass.cli.ScssMain.main(ScssMain.java:57)
	at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:279)
	at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.IllegalStateException: Error compiling jar:file:/home/lalmeras/.m2/repository/org/iglooproject/components/igloo-component-sass/5.11.0-SNAPSHOT/igloo-component-sass-5.11.0-SNAPSHOT.jar!/org/iglooproject/sass/cli/test.scss
	at org.iglooproject.sass.service.ScssServiceImpl.getCompiledDartClasspath(ScssServiceImpl.java:117)
	at org.iglooproject.sass.service.ScssServiceImpl.getCompiledStylesheet(ScssServiceImpl.java:64)
	at org.iglooproject.sass.cli.ScssMain.processScss(ScssMain.java:106)
	... 13 more
Caused by: java.lang.NullPointerException
	at java.base/java.io.File.<init>(File.java:278)
	at org.iglooproject.sass.service.ScssServiceImpl.getCompiledDartClasspath(ScssServiceImpl.java:101)
	... 15 more
One or more scss files cannot be generated. Generation failure.

Statement

In igloo-parent-maven-configuration-core/pom.xml:

• version of igloo-dependency-hibernate-search dependency uses ${project.version} which:
  • seems to be logical
  • BUT is badly interpreted while processing build of a client project
• version of igloo-dependency-test and igloo-dependency-elasticsearch-test dependencies use Igloo's version as a static string (currently 1.1.0) which:
  • doesn't seem to be a good practice
  • BUT seems to be correctly updated while performing Igloo releases

Additionally, we can find other inconsistencies in igloo-dependency-* modules:

• igloo-dependency-core-spring/pom.xml -> ${project.version} used for igloo-dependency-core-logging
• igloo-dependency-core-spring-security/pom.xml -> ${project.version} used for igloo-dependency-core-spring
• igloo-dependency-hibernate-core/pom.xml -> static string (1.1.0) used for igloo-dependency-core-logging
• igloo-dependency-hibernate-search/pom.xml
  • static string (1.1.0) used for igloo-dependency-hibernate-core
  • ${project.version} used for igloo-dependency-core-logging
• igloo-dependency-less4j/pom.xml -> ${project.version} used for igloo-dependency-core-logging

In igloo-component-* and igloo-package-* modules, ${project.version} is mostly used, except (search for "1.1.0" in "pom.xml" files to reproduce, few false positives):

• igloo-component-jpa-externallinkchecker/pom.xml -> static string (1.1.0) used for igloo-component-jpa-test
• igloo-component-jpa-security/pom.xml -> static string (1.1.0) used for igloo-component-jpa-test
• igloo-component-rest-jersey2/pom.xml -> static string (1.1.0) used for igloo-component-jpa-test
• igloo-component-wicket-more/pom.xml -> static string (1.1.0) used for igloo-component-jpa-test

Issue on client project

The version of igloo-dependency-hibernate-search dependency, using ${project.version}, is badly interpreted while processing build of a client project. The version number used in this case is the client project's version instead of Igloo's version.

But, with a kind of magic, dependencies are not broken and the build run correctly...

Current status about cache / distributed caching:

• ehcache 2.x used as hibernate second level cache backend and spring cache backend
• infinispan integration (configuration) and a home-made wrapper to manage locks and message communication over infinispan

We already use hibernate + ehcache + jgroups to manage distributed cache eviction, but it is not integrated in igloo.

We may choose a strategy for the future:

• drop ehcache and use infinispan

  • infinispan provides hibernate caching module
  • infinispan is a JSR-107 (JCache) provider and spring can wrap JSR-107 providers
  • our current ehcache's usage are basics and may not be impacted by this move
  • we need to implement again cache management interface for hibernate and web-caches

• no changes:

  • ehcache as second level cache and spring backend and if we need distributed behavior:
    • switch caches to spring + infinispan JSR-107
    • configure ehcache + jgroups
  • infinispan triggered only for distributed behaviors

With Igloo 4.0.0, we step into a jgtiflow issue. In basic-application-{core-webapp}/pom.xml, we use ${igloo.version} for igloo dependencies. It allow us to manage igloo and basic-application together, and when we create a new project from basic-application, we just add a <igloo.version>...</igloo.version> property in project's root pom to target the right Igloo version.

When jgitflow encounter an internal dependency (like igloo-component-spring), it detects that it is handled by a property. If there is no properties node in current pom.xml, it then ignores this artifact silently (this is the previous behavior, when we have no property definition in both core/webapp). But if there is any properties node, jgitflow throws an error if the version property is not in this node.

For 4.0.0, we rework basic-application-{core,webapp}/pom.xml so that it does not contain properties node.

We must find a way to use correctly properties node in basic-application project.

It is not an issue for a igloo-based project as jgtiflow ignore non-internal dependencies.

Problem in jgtitflow is here : https://bitbucket.org/atlassian/jgit-flow/src/6a57ef1ec9c490b4633d46640df637df16774a62/jgitflow-maven-plugin/src/main/java/com/atlassian/maven/plugins/jgitflow/rewrite/ArtifactReleaseVersionChange.java#lines-232 ; if properties is null, there is no exception. If properties is not null, then version property must be resolvable else it throws an error.

In

Test fix with a storage and supervision-enabled application and check /monitoring/storage/failures/ and /monitoring/storage/size/pages.

While trying to use Reload4j in replacement for Log4j 1.2 I ran into an IllegalStateException while starting the application.

java.lang.IllegalStateException: Unknown LoggerFactory implementation org.slf4j.impl.Reload4jLoggerFactory

It is caused by a missing case while definying the LoggerImplementation in AbstractExtendedApplicationContextInitializer. Reload4J should have a specific LoggerImplementation.

I propose the following fixup :

• Add RELOAD4J value in LoggerImplementation :

public static enum LoggerImplementation {
        LOG4J("org.slf4j.impl.Log4jLoggerFactory", "org.iglooproject.config.bootstrap.spring.log4j1.Log4J1Configuration"),
        RELOAD4J("org.slf4j.impl.Reload4jLoggerFactory", "org.iglooproject.config.bootstrap.spring.log4j1.Log4J1Configuration"),
        LOG4J2("org.apache.logging.slf4j.Log4jLoggerFactory", "org.iglooproject.config.bootstrap.spring.log4j2.Log4J2Configuration");
[...]
}

• Add the case in AbstractExtendedApplicationContextInitializer#getLoggerImplementation :

private LoggerImplementation getLoggerImplementation() {
  String loggerFactoryClassName = LoggerFactory.getILoggerFactory().getClass().getName();
  if (loggerFactoryClassName.equals(LoggerImplementation.LOG4J.slf4jLoggerFactoryClass)) {
	  return LoggerImplementation.LOG4J;
  } else if (loggerFactoryClassName.equals(LoggerImplementation.RELOAD4J.slf4jLoggerFactoryClass)) {
	  return LoggerImplementation.RELOAD4J;
  } else if (loggerFactoryClassName.equals(LoggerImplementation.LOG4J2.slf4jLoggerFactoryClass)) {
	  return LoggerImplementation.LOG4J2;
  } else {
	  throw new IllegalStateException(String.format("Unknown LoggerFactory implementation %s", loggerFactoryClassName));
  }
}

@lalmeras Issue to track and discuss about webjars open files leak on development.

• /etc/systemd/user.conf: DefaultLimitNOFILE set to 4096

[flacreuse@desktop ~]$ ulimit -n
4096

• Stack:

Exception in thread "Wicket-AsyncDataStore-PageSavingThread" java.lang.IllegalStateException: java.io.FileNotFoundException: /home/rjoly/projets/balisage-cms/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/balisage-webapp/WEB-INF/lib/httpclient-4.5.6.jar (Trop de fichiers ouverts)
    at org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.getArchiveEntry(AbstractSingleArchiveResourceSet.java:101)
    at org.apache.catalina.webresources.AbstractArchiveResourceSet.getResource(AbstractArchiveResourceSet.java:256)
    at org.apache.catalina.webresources.StandardRoot.getResourceInternal(StandardRoot.java:281)
    at org.apache.catalina.webresources.Cache.getResource(Cache.java:62)
    at org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:216)
    at org.apache.catalina.webresources.StandardRoot.getClassLoaderResource(StandardRoot.java:225)
    at org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2209)
    at org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:816)
    at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1261)
    at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1121)
    at org.apache.log4j.spi.LoggingEvent.<init>(LoggingEvent.java:165)
    at org.apache.log4j.Category.forcedLog(Category.java:391)
    at org.apache.log4j.Category.log(Category.java:856)
    at org.slf4j.impl.Log4jLoggerAdapter.error(Log4jLoggerAdapter.java:576)
    at org.apache.wicket.pageStore.DiskDataStore$SessionEntry.getFileChannel(DiskDataStore.java:434)
    at org.apache.wicket.pageStore.DiskDataStore$SessionEntry.savePage(DiskDataStore.java:346)
    at org.apache.wicket.pageStore.DiskDataStore.storeData(DiskDataStore.java:185)
    at org.apache.wicket.pageStore.AsynchronousDataStore$PageSavingRunnable.run(AsynchronousDataStore.java:340)
    at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.FileNotFoundException: /home/rjoly/projets/balisage-cms/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/balisage-webapp/WEB-INF/lib/httpclient-4.5.6.jar (Trop de fichiers ouverts)
    at java.util.zip.ZipFile.open(Native Method)
    at java.util.zip.ZipFile.<init>(ZipFile.java:225)
    at java.util.zip.ZipFile.<init>(ZipFile.java:155)
    at java.util.jar.JarFile.<init>(JarFile.java:166)
    at java.util.jar.JarFile.<init>(JarFile.java:130)
    at org.apache.tomcat.util.compat.JreCompat.jarFileNewInstance(JreCompat.java:164)
    at org.apache.tomcat.util.compat.JreCompat.jarFileNewInstance(JreCompat.java:149)
    at org.apache.catalina.webresources.AbstractArchiveResourceSet.openJarFile(AbstractArchiveResourceSet.java:307)
    at org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.getArchiveEntry(AbstractSingleArchiveResourceSet.java:97)
    ... 18 more

• Bootstrap webjar seems to be involved:

[flacreuse@desktop ~]$ lsof -p <pid tomcat> > ulimit_files.txt
[flacreuse@desktop ~]$ grep -o "bootstrap-4.1.2.jar" ulimit_files.txt | wc -l
2462
[flacreuse@desktop ~]$ grep -o "igloo-component-wicket-bootstrap4-1.2-SNAPSHOT.jar" ulimit_files.txt | wc -l
721

• igloo-component-commons:

  • split code into several modules
  • (*) use a pom dependency module for truezip; get rid of truezip dependency as it is unused in this module

• igloo-component-spring:

  • split lucene utilities in a new module, and remove lucene dependency
  • consider if we remove freemarker - decide if we want to keep a way to do text emails (wicket does not fit this need) ; if yes, find a replacement for mail subject templating (only use of freemarker).
  • move ehcache dependency to a pom module
  • see if notification-related code can be moved to another module
  • consider if igloo-component-commons needed as dependency

• igloo-component-jpa:

  • consider splitting pure jpa and spring integration
  • consider a better way to handle or not elasticsearch backend for hibernate-search, and consider a splitted module for hibernate-search related utilities
  • consider flyway integration a separate module
  • consider basic entities (GenericEntity, services, ...) in a separate module
  • fix FlywayConfiguration package name !

(*) prefer pom dependency module to build set of dependencies to reuse

Entity field StorageConsistencyCheck#checkType is not set when storage consistency is computed.

Missing setCheckType call is surely here : org.igloo.storage.impl.StorageService.checkConsistency(StorageUnit, boolean)

Rework TestConsistency to check that setCheckType is called with the expected value, then fix the issue.

Impact analysis:

• checkType is null on performed analysis
• so unit is always considered as not checked, and so is eligible for a check
• if checksum check is enabled, then checksum check is performed at each run

When fixed, new consistency checks will be correctly set, and consistency check normal behavior must be restored.

Currently, an error in a autoPerform DataUpgrade do not stop application of subsequent upgrade. We mark upgrade as failed and we continue with next upgrades.

We need to allow a DataUpgrade to stop upgrades and to stop application startup.

DataUpgradeManagerImpl should be moved from basic-application to igloo.

See https://github.com/igloo-project/igloo-parent/blob/dev/basic-application/basic-application-core/src/main/java/org/iglooproject/basicapp/core/business/upgrade/service/DataUpgradeManagerImpl.java#L49

If AbstractOfflinePanelRendererServiceImpl is used to render a component tree, rendering fails with a null pointer exception, triggered by BootstrapRequestCycle#findVersion()

It seems it affects igloo 4.x+ versions. We need to check which versions are affected.

log4j2-*.properties are not loaded. Only log4j2.properties is loaded.