Problem summary: we've upgraded our Java 17 monolith application with multiple modules from Vaadin 21.0.1 to 23.3.5 and now our application routes don't resolve anymore, instead resulting in 404 Whitelabel errorpages.
This not being our first Vaadin rodeo (originating from Vaadin 7), we followed the Vaadin upgrade guide generator and expanded accordingly upon that.
Steps we took, each having been validated seperately:
Upgraded our backend to use Spring 5.3.18 (coming from 5.3.10). No issue there
Upgraded our frontend to use Spring Boot 2.6.7 (coming from 2.5.4). No issue there
this step was project-specific and not in the guide Removed Vaadin-addons from pom.xml. Also removed those imports from our package.json. Naturally removed all addons-code from application (EnhancedDialog and MultiselectComboBox -> using v23's regular Dialog and MultiSelectComboBox)
Removed webpack.config.js, package-lock.json and the node_modules folder
Raised global (-g) npm version to 9.4.0 (coming from 8.3.3)
Cleared npm with commandline npm cache clear --force
Upgraded the Vaadin flow version to 23.3.5 (coming from 21.0.1)
added the following dependency and reloaded the pom.xml:
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>flow-maven-plugin</artifactId>
<version>23.3.3</version>
</dependency>
Invalidated and restarted IntelliJ
ran clean-install Maven command through IntelliJ (with Production flag on/off makes no difference)
-> This results in a 404 whitelabel errorpage.
Next, I made sure that all our views annotated with com.vaadin.flow.router.#Route contained at least the javax.annotation.security.#PermitAll annotation.
I added spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.web.servlet.error.ErrorMvcAutoConfiguration to our application.properties trying to get a more descriptive message.
-> This results in the Apache Tomcat errorpage with description: "The origin server did not find a current representation for the target resource or is not willing to disclose that one exists."
In both cases, the F12 DevTools are empty and showing nothing more than a 404 for the given URL.
So I continued debugging and validated that our custom security roles were validated correctly, a bit like this answer hinted at.
I'm getting into the breakpoints placed in the configure(HttpSecurity http) method from the WebSecurityConfigurerAdapter, but I'm unable to enter the serviceInit(ServiceInitEvent event) from the VaadinServiceInitListener.
I'm not a pro concerning servletRequests, but when hitting the isFrameworkInternalRequest(HttpServletRequest request) (called during the adapter's configuration), it seems only logical that for REQUEST_TYPE_PARAMETER a value of null is returned.
I was intrigued by these upgrade steps for an even higher Vaadin version, but nothing in there changed a bit for me.
When asked, I'd say that Spring isn't picking up on my views. Even the older #EnableVaadin() annotation did nothing. At this point I can't think straight anymore, even looking into the change of why Vaadin now uses vite.config.ts instead of webpack.config.js. Any pointers to where the issue might lay are immensely appreciated.
all credit to #Knoobie whose concise answer contained the correct solution.
Vaadin 23.3.x requires at least 2.7.x in order to work.
The Vaadin upgrade guide generator, when looking at the steps to migrate from v21 to v23, mistakenly referenced the minimum version of SpringBoot as 2.6.6. They will fix this in the immediate future.
Related
The application is failing during the startup with this error:
The bean 'requestDataValueProcessor', defined in class path resource [org/springframework/security/config/annotation/web/configuration/WebMvcSecurityConfiguration.class], could not be registered. A bean with that name has already been defined in class path resource [org/springframework/security/config/annotation/web/reactive/WebFluxSecurityConfiguration.class] and overriding is disabled.
All team members have the same problem and it seems that even if we're checking out an old git tag, the same problem persist. We've checked all the build files and dependencies, and nothing seemed to be changed in the last period of time. What's even more interesting is that the Bamboo seemed to run the build and the IT's pack with success with a day before, but today's morning it seem that the same issue is replicated there.
Not sure exactly why is complaining about WebMvcSecurityConfiguration, since we're using only reactive security in our project. So at this point we don't have any spring-mvc dependencies..
Does anyone have any clue ? Thx
So after we've enabled debug level logs on spring and force spring app to use only the reactive configurations like this:
spring:
main:
web-application-type: reactive
it seemed that the springfox dependencies were failing with:
java.lang.NoSuchMethodError: org.springframework.util.MultiValueMap.addIfAbsent(Ljava/lang/Object;Ljava/lang/Object;)V
at springfox.documentation.spring.web.scanners.ModelSpecificationRegistryBuilder.lambda$add$0(ModelSpecificationRegistryBuilder.java:37)
at java.base/java.util.Optional.ifPresent(Optional.java:183)
at springfox.documentation.spring.web.scanners.ModelSpecificationRegistryBuilder.add(ModelSpecificationRegistryBuilder.java:34)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
at
So that error ^^^ point us towards sprinfox dependencies which were:
compile ("io.springfox:springfox-swagger-ui:3.0.0-SNAPSHOT")
compile ("io.springfox:springfox-swagger2:3.0.0-SNAPSHOT")
compile ("io.springfox:springfox-spring-webflux:3.0.0-SNAPSHOT")
After furthermore investigation, it seemed that some of those contains the spring-mvc dependency and that interfere with the spring-webflux one, and the application got confused which beans to inject.
We've downgrade those dependencies to 2.10.0, and everything seems to work now. My guess is that they've made some releases with that snapshot version and that include spring mvc, but until now it was absent. Lesson learned, never use some external libraries snapshots versions, otherwise you could end up in a very bad situation.
X.X.X-SNAPSHOT Dependencies are not the stable ones.
we were using <springfox.version>3.0.0-SNAPSHOT</springfox.version> which suddenly stopped working.
So below solution worked for us.
<springfox.version>2.10.5</springfox.version>
Cheers!!
The spring.components file in not generated.
The problem is described in-depth in https://github.com/spring-projects/spring-framework/issues/22338.
As turns out, in Gradle 4.6+ (that includes Gradle 5.x - I have verified in Gradle 5.1.1 and 5.2), the correct declaration is annotationProcessor 'org.springframework:spring-context-indexer:5.1.4.RELEASE'.
More questions for the good folks from Spring Boot - should the spring.components file be created in ./BOOT-INF/classes/META-INF/spring.components? That's where is shows up for me, but I would expect it in ./META-INF/spring.components.
Also, how can I see that the file is indeed produced & used? Any flags to toggle? Any specific packages to turn verbose logging for? Any Actuator endpoint to look at?
I have an issue with the WAS Liberty classloader, nothing I do seem to fix it. The issue seems to be with log4j2, which I am using.
I'm running 16.0.0.4 (just upgraded from 8.5.5.9 where this issue also exist). I'm trying to create a webapp using Primefaces 6.0 which connects to Elasticsearch 5.1.1.
I have added the following dependency to maven:
<dependency>
<groupId>org.elasticsearch.client</groupId>
<artifactId>transport</artifactId>
<version>${library.elasticsearch.version}</version>
</dependency>
Somewhere along the road I need to do the following:
TransportClient client = new PreBuiltTransportClient(settings)
.addTransportAddress(new InetSocketTransportAddress(InetAddress.getByName(HOST), PORT));
Debugging this line hits the following method call in Elasticsearch (class: org.elasticsearch.threadpool.ThreadPool line 203):
logger.debug("created thread pool: {}", entry.getValue().formatInfo(executorHolder.info));
This throws an java.lang.NoSuchMethodError:
org/apache/logging/log4j/Logger.debug(java/lang/String;java/lang/Object;)
Normally we use log4j 2.2, but I have included log4j2 2.7 as described here (Elasticsearch v5.0 uses 2.6.2, v5.1 uses 2.7): https://discuss.elastic.co/t/issue-with-elastic-search-5-0-0-noclassdeffounderror-org-apache-logging-log4j-logger/64262/2
I have also tried to make it "provided". I'm currently building a war file, but I also tried to do it as an ear, same result.
I came accoss this issue on the Elasticsearch 5-alpha: https://github.com/elastic/elasticsearch/issues/19415 Here they note that they wanted to create a server and therefore did not see log4j2 as a consern, but they suggest that you use the REST API instead (although, at the time of writing, this was not usable for Java developers).
So the question is, what do I do? Should I use the REST API (e.g. Jest (https://github.com/searchbox-io/Jest/tree/master/jest)) or ?...
The code I have works fine when running standalone outside Liberty.
UPDATE:
It seems like parts of Liberty does contain log4j v2.2:
class load: org.apache.logging.log4j.core.appender.routing.Route from: file:/C:/deploy/liberty/workarea/org.eclipse.osgi/60/data/cache/com.ibm.ws.app.manager_0/.cache/lib/log4j-core-2.2.jar
...
It loads a lot of classes from this jar, but not the one that I'm having trouble with - this is loaded from an app we have. I tried to bump the version inside our own app, but same issue.
I'm having an issue with JSF rendering. Here's my setup:
CentOS
TomEE Plus 1.5.2
Icefaces
Spring Security 3
And my app is set up like this:
/opt/tomee/lib/[all the normal TomEE jars]
/opt/tomee/lib/[all the Spring Security jars]
/opt/tomee/lib/icefaces.jar
/opt/tomee/lib/icefaces-compat.jar
/opt/tomee/lib/icepush.jar
/opt/tomee/webapps/UI/index.xhtml
/opt/tomee/webapps/UI/WEB-INF/lib/icefaces-ace.jar
/opt/tomee/webapps/UI/[normal jsf 2 configuration]
There isn't anything obvious in the logs but when the JSF attempts to render I get the following error:
com/sun/crypto/provider/HmacCore
viewId=/index.xhtml
location=/opt/tomee/webapps/UI/index.xhtml
phaseId=RENDER_RESPONSE(6)
Caused by:
java.lang.LinkageError - com/sun/crypto/provider/HmacCore
at com.sun.crypto.provider.HmacSHA1.(DashA13*..)
The stack trace on the error page is massive, so I'm not going to dump a novel here, but here are the calls of note.
java.lang.LinkageError: com/sun/crypto/provider/HmacCore
at com.sun.crypto.provider.HmacSHA1.(DashA13*..)
{...}
at java.security.Provider$Service.newInstance(Provider.java:1221)
{...}
at org.apache.myfaces.shared.util.StateUtils.encrypt(StateUtils.java:328)
{...}
at org.icefaces.impl.renderkit.RenderWrapper.encodeEnd(RenderWrapper.java:53)
{...}
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:311)
I dumped the contents of all the jars in tomee/lib but com.sun.crypto isn't anywhere that I can find in the web server. Apps that don't use Spring Security work just fine.
Any thoughts?
OK. I got it to work so I'm going to be 'that guy' and answer my own question. I hope that it helps save someone else from the migraine it gave me. The problem went away after I did the following:
delete my war
let tomcat clean up the webapps dir
stop tomcat
delete the related directories from work
add the spring security taglibs jar to my app
remove the encoder declaration from my applicationSecurity.xml
rebuild the app
start tomcat
redeploy
drink heavily
profit
Step 10 wasn't actually a part of debugging process but I wouldn't have complained if it was. Share and enjoy.
I have a large desktop Java application that is being moved from JRE 1.6 to JRE 1.7. The application uses the NetBeans API for GUI and the SLF4J API with a Log4J backend. The application has two deployment methods, a standalone application (run either by Ant or a Launch4j exe) or a web start via a simple custom HTTP server (Jetty and JNLP servlet).
The application has several NetBeans ModuleInstall components that add property editors onto the Java PropertyEditorManager search path at startup. E.g.
ArrayList<String> editorPaths = new ArrayList<String>();
editorPaths.add(LocationEditor.class.getPackage().getName());
editorPaths.addAll(Arrays.asList(PropertyEditorManager.getEditorSearchPath()));
PropertyEditorManager.setEditorSearchPath(editorPaths.toArray(new String[editorPaths.size()]));
When I migrated to Java 1.7 (u9) these editors were no longer being found in the application, either standalone or web start deployment. The application started fine and the editors were accessable when started from Eclipse. Curious to see why the standalone failed I added some logging statements to report the search path and set the log4j.configuration property via the Ant startup script. The editors were now available. I then launched the .exe (which doesn't accept command line parameters so the log4j configuration wasn't set) and the editors were gone again.
So the differentiator appears to be setting the log4j.configuration parameter. I changed the build so the standlong Ant and .exe referenced this and they work. The web start though doesn't pass this value on (it is loaded internally in the code) and still fails to find the editors. I also removed the log4j setting from the Eclipse run command and the editors vanish again.
I tried registering against type specifically rather than using the search path but still had no success. I'm using the search path as one optional overrides another modules editors but I don't know the module startup order, so that one appends its path to the start of the lookup while the others append to the end.
I've also tried removing all SLF4J to Log4J mappings and using the SLF4J-Simple instead. This made no difference. Adding the parameter back in makes the code work again. The spring-aspects dependency is pulling in a single Log4J reference.
I have a working solution for standalone and I'm sure I can get the new trick working for the webstart, but this reeks of a bad hack to get things working. I rather figure out the cause for the editors going missing. No exceptions are reported and removing logging from all ModuleInstall objects does nothing. All the code still executes, and this includes other features the ModuleInstall executes so I know they are running.
I'm using NetBeans RELEASE72 and the other dependencies are:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.2</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.2</version>
</dependency>
Update 1
I've tracked the problem down to our custom logging setup. When this section was removed and the simple logger used the problem didn't occur. When this custom configuration was removed and the slf4j-log4j12 connected again I still got the property editors. However when I enabled the custom logging configuration again the editors failed.
The custom logging configuration ensures we have a logging setup even if nothing is specified by the user. There is also some weird statup process that other users activated where the logging can't be activated until after a weaving process. I suspect that maybe the custom logging setting doesn't work with Java 1.7, or something to do with replacement of default logging handlers redirecting to our custom logging.
In any case it looks like an internal mess, not much the internet can help with.
I'd left the problem and finally came back to it. The problem is that the PropertyEditorManager is now no longer a global singleton, but is a thread local singleton. The search path is registered in a ThreadLocalContext in JDK 1.7, presumably to prevent thread synchronisation issues. However the NetBeans ModuleInstall was being executed on the main thread, and then the property readers were being read on the AWT thread. This meant the AWT thread didn't find any of the property editors.
As a fix I just used the SwingUtilities.invokeLater() to register the property editor path.
I have no idea what caused the other symptons to show.
I have just been tracing a similiar problem;
when I run my NetBeans RCP 7.3 app under java 1.7.0_25
org.netbeans.beaninfo.editors.DateEditor is no longer available to my GUI Property Sheets.
As you suggest, I have worked around the problem by including this code into my GUI module's Installer
SwingUtilities.invokeLater(new Runnable()
{
#Override
public void run() {
NodeOp.registerPropertyEditors();
}
});
This solves the problem for now, but it feels kind of hacky ...