Wildfly 14 JNDI http-remoting request to port 8080 not working with ear and more than 61 jars in it - jar

We are currently migrating from JBoss AS 7 to Wildfly 14. Now we have the strange behavior that our JNDI http-remtoing requests do not work if we have more than 61 jars in our ear (Needed for Authetification and Permissions-Lookup). We can remove any jar (that do not have any dependencies to other artifacts) and if we start our Wildfly it works. It just has to be less than 61 jars in our ear-File (I'm referencing to the modules in the ear, not the libs). No Error-Message on Wildfly appears, it seams that the request never arrives to wildfly, but the client still waits. I tried also with different ports, but nothing.
Our code is compiled with Maven src 1.6 to target 1.7. Running JRE on Wildfly is 1.8.
Do anyone has experienced same problems with migrating from JBoss AS 7 to Wildfly?
We also tried with a older version of Wildfly (Wildfly 11) and had the same Problem. I really don't want to have to debug the server, so if somebody has a clue, experienced the same or any idea why this behaviour can behave, then please help me :-)
At the moment we are trying to set up the Wildfly in Standalone-Mode, target is to let it run in Domain-Mode as a Cluster-Server. When this will work, we want to update our project first to Java 8 and after that to a higher version like Java 10 or 11.
This is the Test-Lookup and -Call that I fire
final Hashtable<String, String> jndiProperties = new Hashtable<>();
//jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
jndiProperties.put(Context.PROVIDER_URL, "http-remoting://localhost:8080");
jndiProperties.put(Context.SECURITY_PRINCIPAL, "user-name");
jndiProperties.put(Context.SECURITY_CREDENTIALS, "xxxxxxxxxxx");
jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
final Context ctx = new InitialContext(jndiProperties);
final DistServer ds = (DistServer) ctx.lookup(
"ejb:our-server/distribution-server/DistServerBean!com.someenterprise.common.DistServer");
System.out.println("Calling canIAccess returns " + ds.canIAccess());

Related

Getting error can not access disposed object for builder.build() on visual studio update

I am getting error on debug session start on my dot net core API project; since I updated visual studio to latest version 17.1.1. Following is the exception detail, it is showing on console. I tried by deleting temp, bin, obj folders but nothing worked. Has somebody faced such an issue or know how to fix?
Unhandled exception. System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'ConfigurationManager'.
at Microsoft.Extensions.Configuration.ReferenceCountedProviderManager.AddProvider(IConfigurationProvider provider)
at Microsoft.Extensions.Configuration.ConfigurationManager.AddSource(IConfigurationSource source)
at Microsoft.Extensions.Configuration.ConfigurationManager.Microsoft.Extensions.Configuration.IConfigurationBuilder.Add(IConfigurationSource source)
at Microsoft.AspNetCore.Builder.WebApplicationBuilder.<>c__DisplayClass25_0.b__2(HostBuilderContext context, IServiceCollection services)
at Microsoft.Extensions.Hosting.HostBuilder.CreateServiceProvider()
at Microsoft.Extensions.Hosting.HostBuilder.Build()
at Microsoft.AspNetCore.Builder.WebApplicationBuilder.Build()
at Program.$(String[] args) in Program.cs:line 40
It is because you use the old way of getting the settings from the configuration manager, like:
using (var serviceProvider = services.BuildServiceProvider())
{
...
}
If you remove these lines and just use the configuration as-is with
options = configuration.GetOptions<Object>("xxx");
it will work
we also had this issue since march 8.
is was introduced with the release of 6.0.3, see a github post about the issue : https://github.com/dotnet/aspnetcore/issues/40614
for now what we did is revert to the 6.0.2 version (this is a temporary work around, i will hope to figure out what was wrong asap)
for docker images:
FROM mcr.microsoft.com/dotnet/aspnet:6.0.2 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/sdk:6.0.200 AS build
WORKDIR /src
if you are using it in yml also probably
use dotnetversion
DotNetVersion: "6.0.200" instead of "6.0.x"
6.0.200 is the sdk version of 6.0.2 framework https://dotnet.microsoft.com/en-us/download/dotnet/6.0
11/03/2022
see also this https://github.com/dotnet/core/issues/7259 were i have pinpointed the issue in our code and added a sample app to reproduce
if we look into that repo https://github.com/microsoft/ApplicationInsights-Kubernetes/blob/69f44c6ec3fda26d76a01836b851402e3f8a02ad/src/ApplicationInsights.Kubernetes/Extensions/ApplicationInsightsExtensions.cs
we indeed find the same piece of code on the other answers
i faced to this problem when i update my SDK both in docker and my window 11
my sdk is : 6.0.3
but i cant understand why this problem is happend

Tomcat 8 - No Spring WebApplicationInitializer types detected on classpath

I use maven plugin for eclipse and tomcat plugin for maven. When I use it to "clean tomcat7:deploy" my hello.war to the Tomcat 8 server on localhost it works fine. I can go to localhost:8080/hello/hello and see "Hello!" page.
But when I deploy to Ubuntu server 15.10 in my local network and go to 192.168.1.2:8080/hello/hello I get Apache Tomcat 404 error. Though tomcat manager shows that deployment went fine and my app is working.
My thoughts were that something wrong with tomcat server on ubuntu, but when I deploy other apps to the same tomcat server on ubuntu, they work as they should. Then I thought the problem is inside my "hello" app. But if it was so, I wouldn't be able to successfully run it on my localhost tomcat server!
When I read logs on Tomcat on Ubuntu server they say:
06-Mar-2016 10:00:00.369 INFO [http-nio-8080-exec-5] org.apache.catalina.core.ApplicationContext.log Manager: deploy: Deploying web application '/hello'
06-Mar-2016 10:00:00.370 INFO [http-nio-8080-exec-5] org.apache.catalina.core.ApplicationContext.log Manager: Uploading WAR file to /var/lib/tomcat8/webapps/hello.war.tmp
06-Mar-2016 10:00:18.022 INFO [localhost-startStop-3] org.apache.catalina.core.ApplicationContext.log No Spring WebApplicationInitializer types detected on classpath
So it seems like it can't find my Bootstrap.class class that implements Spring WebApplicationInitializer interface. Though when I check folder /var/lib/tomcat8/webapps/hello/WEB-INF/classes it contains all classes it should.
I checked logs on localhost, and they do not complain about this.
So at the end it seems that Tomcat 8 on Ubuntu server can not find mentioned WebApplicationInitializer.
I've read answers to similar questions here on stackoverflow and tried, but most of them are dealing with eclipse server settings, my problem here is different I think.
What to do and where to look?
EDIT:
When I manually deploy hello.war via /manager on localhost, everything is ok. Inside localhost.2016-03-06.log I have:
06-Mar-2016 11:34:33.081 INFO [http-nio-8080-exec-51] org.apache.catalina.core.ApplicationContext.log Spring WebApplicationInitializers detected on classpath: [by.hello.configuration.Bootstrap#19087f1e]
06-Mar-2016 11:34:33.544 INFO [http-nio-8080-exec-51] org.apache.catalina.core.ApplicationContext.log Initializing Spring root WebApplicationContext
06-Mar-2016 11:34:34.026 INFO [http-nio-8080-exec-51] org.apache.catalina.core.ApplicationContext.log Initializing Spring FrameworkServlet 'springDispatcher'
I can go to localhost:8080/hello/hello and see "Hello!" greeting.
When I do the same with Ubuntu server's tomcat /manager inside logs I have:
06-Mar-2016 11:36:06.555 INFO [http-nio-8080-exec-14] org.apache.catalina.core.ApplicationContext.log No Spring WebApplicationInitializer types detected on classpath
06-Mar-2016 11:36:06.559 INFO [http-nio-8080-exec-14] org.apache.catalina.core.ApplicationContext.log HTMLManager: list: Listing contexts for virtual host 'localhost'
I used to compile project using JDK1.8 environment.
Now I recompiled project using JDK1.7, my Ubuntu server's Tomcat8 started to recognize Bootstrap.class which implements WebApplicationInitializer interface.
So, the answer for me was:
Check your tomcat's JVM version at the bottom of Tomcat /manager/html page.
Recompile your project using appropriate JDK version.

Configuration files are ignored after migrating to Servicemix 5

We use a .cfg file in ./etc directory to configure our bundle in ServiceMix. Everything worked fine in SMX 4.5.3, but when migrating to the 5th version the file is not picked up. When the bundle encounters a property the following exception is thrown:
java.lang.IllegalArgumentException: Property with key [xslt.dir] not found in properties from text: {{xslt.dir}}, StackTrace: org.apache.camel.RuntimeCamelException: java.lang.IllegalArgumentException: Property with key [xslt.dir] not found in properties from text: {{xslt.dir}}
However, if I put the properties in default-properties section in my blueprint configuration, it works.
Also, the console command config:list actually shows the properties for the bundle in spite of the exception:
Pid: misrouter
BundleLocation: mvn:ru.mig/mis-router/1.0-SNAPSHOT
Properties:
service.pid = misrouter
felix.fileinstall.filename = file:/home/petr/programs/5.0.0-apache-servicemix/etc/misrouter.cfg
xslt.dir = /home/petr/programs/5.0.0-apache-servicemix/xslt
So was something changed in SMX 5 configuration mechanism or is there a bug in it?
What version of the JDK/JRE are you using? When I was trying this out a few minutes ago to answer your question, I also had some problems using the 1.7.0_15 version I had installed and upgrading to the latest 1.7.0_51 fixed those for me.
Actually it's related to Camel vm component, a bug was created for SMX

Flyway SQL directory not found while migrating from within a war

Environment
Jboss 6
flyway 1.5
spring core 2.5.6
structure of the war
ei-web-1.0.1-SNAPSHOT.war
|WEB-INF
|classes
|db
|migrations
|ei
|V5.7.0.sql
|V5.7.1.sql
|V5.7.2.sql
The problem
When I try to execute the Flyway migrations inside a MBean loaded at the startup of my JBoss I get the following stack trace.
java.io.FileNotFoundException: URL [vfs:/C:/jboss-6.1.0.Final/server/ei/deploy/ei-web-1.0.1-SNAPSHOT.war/WEB-INF/classes/db/migrations/ei/] cannot be resolved to absolute file path because it does not reside in the file system: vfs:/C:/jboss-6.1.0.Final/server/ei/deploy/ei-web-1.0.1-SNAPSHOT.war/WEB-INF/classes/db/migrations/ei/
Clues
The flyway base dir is db/migrations/ei
The flyway initial version is 5.7.0
When launched in a standalone way, migrations are OK
IMHO, the problem is the consequence of the unsuccessful scan of the classpath directory.
See com.googlecode.flyway.core.migration.sql.SqlMigrationResolver (L.99)
final String searchPattern = "**/" + sqlMigrationPrefix + "?*" + sqlMigrationSuffix;
Resource[] resources = new PathMatchingResourcePatternResolver(classLoader)
.getResources("classpath:" + searchRoot + searchPattern);
In my case, resources returns an empty array.
This sounds like the same issue as https://github.com/flyway/flyway/issues/91
Feel free to cast your vote :-)

Liferay 6 on Glassfish 3.1 - issue using liferay-ui tags in portlet jsp files

We are seeing this issue on our current Glassfish 3.1 cluster setup. Below are details of issue
- We are running Glassfish version 3.1
We are running liferay 6.0.6
The liferay war is deployed on the Glassfish cluster and working fine on both the nodes.
The same liferay war works fine one Tomcat server as well.
When we deploy our custom portlets on Glassfish cluster it starts working immediately after deployment. (before doing a restart of glassfish cluster)
Once we do a restart of the cluster nodes the same portlet application stops working and Complains and give attached error.
My research till now shows that the java.lang.NoClassDefFoundError: com/liferay/portal/util/PropsValues is part of portal-impl.jar file which is part of liferay portal and should be made available to our portlet. Somehow after the restart the jar files are loaded in a different manner and the same jar file is not available to portlet.
We have also tried the Glassfish 3.1 Bundled liferay 6.1 setup and see the same issue on it as well.
As suggested by liferay forums we have placed the portal-service.jar and portlet.jar in [glassfish home]/lib directory.
when we do a lsof -p pid on the glassfish node instance process it shows the required jar file is open by this process. Not sure why is this not available to our application.
I would appreciate any help or pointers to resolve/investigate this issue.
java.lang.NoClassDefFoundError: com/liferay/portal/util/PropsValues
at org.apache.jsp.html.taglib.ui.search_005fiterator.page_jsp._jspService(page_jsp.java from :500)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:492)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:378)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:72) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:113)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilter.doFilter(InvokerFilter.java:68)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:785)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:604)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:534) at com.liferay.taglib.util.IncludeTag.include(IncludeTag.java:323)
at com.liferay.taglib.util.IncludeTag._doInclude(IncludeTag.java:418)
at com.liferay.taglib.util.IncludeTag.doEndTag(IncludeTag.java:92)
This is a related thread on liferay forum by me but I have not really got any response on it from anyone. [Same issue posted on liferay Forum]
i have also tried placing portal-impl.jar in my portlet/WEB-INF/lib dir (which is not recommended way) and I failed since it requires me to bring all other dependent jars in it too.
I am now running out of options and thinking about implementing the pagination feature using some other third party library instead of using liferay tags.
Here is the specific tag which is giving us error
<liferay-ui:search-iterator />
List of jars in my portlet WEB-INF/lib folder
SiebelClientWS-0.0.1-SNAPSHOT.jar
spring-asm-3.0.5.RELEASE.jar
XmlSchema-1.4.7.jar
spring-aspects-3.0.5.RELEASE.jar
aspectjrt-1.6.11.jar
spring-beans-3.0.5.RELEASE.jar
aspectjweaver-1.6.11.jar
spring-context-3.0.5.RELEASE.jar
axiom-api-1.2.11.jar
spring-context-support-3.0.5.RELEASE.jar
axiom-impl-1.2.11.jar
spring-core-3.0.5.RELEASE.jar
axis2-1.5.4.jar
spring-expression-3.0.5.RELEASE.jar
axis2-kernel-1.5.4.jar
spring-jdbc-3.0.5.RELEASE.jar
axis2-transport-http-1.5.4.jar
spring-tx-3.0.5.RELEASE.jar
axis2-transport-local-1.5.4.jar
spring-web-3.0.5.RELEASE.jar
c3p0-0.9.1.2.jar
spring-webmvc-3.0.5.RELEASE.jar
commons-codec-1.4.jar
spring-webmvc-portlet-3.0.5.RELEASE.jar
commons-httpclient-3.1.jar
util-bridges.jar
commons-logging.jar
util-java.jar
flexjson-2.1.jar
util-taglib.jar
httpcore-4.0.jar
woden-api-1.0M9.jar
httpcore-nio-4.0-beta1.jar
woden-impl-commons-1.0M9.jar
log4j.jar
woden-impl-dom-1.0M9.jar
neethi-2.0.2.jar
wsdl4j-1.6.2.jar
spring-aop-3.0.5.RELEASE.jar
wss4j-1.6.2.jar
I changed
/html/taglib/ui/search_paginator/page.jsp
/html/taglib/ui/search_iterator/page.jsp
/html/taglib/ui/page_iterator/start.jsp
and removed the calls to PropsValues and replaced them with calls to the com.liferay.portal.kernel.util.PropsUtil and PropsKeys instead and that go the rid of the error for me.
I made an improvement request
http://issues.liferay.com/browse/LPS-30660
com/liferay/portal/util/PropsValues is part of portal-impl.jar file which is part of liferay portal and should be made available to our portlet.
That is not true, portal-impl.jar is not available to your portlets and it is not meant to. You MUST NOT put it in your WEB-INF/lib. That jar is only available, and should be that way, to Liferay (liferay application).
Can you show contents (list of jars) of your (deployed) portlets WEB-INF/lib?

Resources