I have a strange behavior of Glassfish 3.1.2.2 (build 5) running on OpenIndiana 151.a3
Using oracle jdk 1.7.0_5.
When i deploy my web application which has a spring web dispatcher and stripes servlet
I get them initialized twice in a row e.g.
PWC1412: WebModule[null] ServletContext.log():Initializing Spring root WebApplicationContext|#]
INFO StripesFilter - Stripes Initialization Complete. Version: 1.5.6, Build: 1.5.6
PWC1412: WebModule[null] ServletContext.log():Initializing Spring root WebApplicationContext|#]
INFO StripesFilter - Stripes Initialization Complete. Version: 1.5.6,
Build: 1.5.6
WEB0671: Loading application [my-web] at [/my-web]|#]
That wouldn't be a much problem if not for an blazeds servlet that i initialize from spring which fails completely on second initialization. I tried disabling blazeds servlet but that doesn't solve double initialization problem because i still get messages of initialization twice in a log. And my application wouldn't work without blazeds so i'm in a pinch here.
UPDATE: I've confirmed it only happens on OpenIndiana host, same configuration on linux works without issues
We had a similar problem. We also tried to deploy to a particular virtual server, which did not work. To fix the issue I ended up having to manually delete the extra virtual-server from the domain.xml:
<virtual-server id="admin-server" network-listeners="http-listener-2"></virtual-server>
If you have more than one virtual server:
"If you deploy a web application and don't specify any assigned virtual servers, the web application is assigned to all currently defined virtual servers"
http://docs.oracle.com/cd/E18930_01/html/821-2416/ggncs.html
But this did not solve our problem.
We had to delete the extra virtual server for it to work. This also happens on 3.1.2 and it is not just a windows problem. We replicated the issue on Linux too.
Related
We've been getting errors occasionally from our test and production environments where ServiceLocatorImpl has shut down which causes it to fail to create stateless EJBs from any #Schedule methods.
javax.ejb.EJBException: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:399)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2607)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:2024)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:90)
...
Caused by: java.lang.IllegalStateException: ServiceLocatorImpl(__HK2_Generated_9,12,566324949) has been shut down
at org.jvnet.hk2.internal.ServiceLocatorImpl.checkState(ServiceLocatorImpl.java:2384)
at org.jvnet.hk2.internal.ServiceLocatorImpl.inject(ServiceLocatorImpl.java:997)
at org.glassfish.jersey.inject.hk2.AbstractHk2InjectionManager.inject(AbstractHk2InjectionManager.java:207)
at org.glassfish.jersey.inject.hk2.ImmediateHk2InjectionManager.inject(ImmediateHk2InjectionManager.java:30)
at org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider$InjectionManagerInjectedCdiTarget.inject(CdiComponentProvider.java:668)
at org.glassfish.weld.services.JCDIServiceImpl$JCDIInjectionContextImpl.inject(JCDIServiceImpl.java:581)
at org.glassfish.weld.services.JCDIServiceImpl.injectEJBInstance(JCDIServiceImpl.java:328)
at com.sun.ejb.containers.BaseContainer.injectEjbInstance(BaseContainer.java:1818)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:437)
... 88 more
Most of the application continues to work fine and and users can continue using it but background processes that are run from #Schedule all fail until we restart Payara.
We originally ran into this in our test environment after it had been running for multiple days under a fairly high load while we were on Payara 5.2021.4 (uses Jersey 2.30). We found servicelocator impl shutdown issue in jersey 2.22 talking about this issue and it seemed to indicate that Jersey 2.26 fixed the issue.
Since we were already on a later version we dug into the release notes and found that in hk2 2.6.1 there was a fix "Fix for child service locator shutdown" (https://github.com/eclipse-ee4j/glassfish-hk2/blob/master/CHANGELOG) and that Jersey 2.29.1 had updated the hk2 version from 5.1.0 to 6.2.1 (https://github.com/eclipse-ee4j/jersey/pull/4234) and that we had been listing Jersey 2.29 as a dependency. So we updated our versions to Payara 5.2021.8, Jersey 2.34 (hk2 2.6.1) and made our environment restart payara every night. After that we didn't seen the error for a while but since then we've still gotten it a couple times in production.
We haven't been able to reproduce the issue on demand or pin down any other errors that could be causing it. Has anyone else run into this issue on the current Payara and come up with a way to fix it, work around it or mitigate it short of restarting payara whenever it happens?
We are migrating from jboss Eap 6.4 to Wildfly. During migration, as part of our application installation, we will configure different xa-datasources in domain.xml. This configuration will be done through jboss-cli.sh.
After configuring the data sources, when deploying the ears, (particularly at *-ejb.jar) we are getting an error saying that the 'persistent unit' is not available and the deployment is rolled back.
Loggers are showing the below:
WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"xxyy.ear/xxyy-ejb.jar#xxyyDBUnit\" is missing [jboss.naming.context.java.jboss.datasources.xxyyDS]"]
Post restart of the jboss service, the same deployment works fine. So, we believe that the datasources configured in the domain.xml is not activated or enabled (although we have set the attribute 'enabled=true' for the xa-datasource. We could see the following warning while adding the xa-datasource in jboss.
2021-09-21 16:57:48,308 INFO [org.jboss.as.connector] (Host Controller Service Threads - 8) WFLYJCA0093: The 'enable' operation is deprecated. Use of the 'add' or 'remove' operations is preferred, or if required the 'write-attribute' operation can used to set the deprecated 'enabled' attribute
With this warning, we understood that the enable/disable operation has been removed in the jboss wildfly. Is there anyway we can make it enabled on the runtime without restart of the jboss service.
Below are the commands which we use to create the xa-datasource in wildfly.
/profile=full-ha/subsystem=datasources/xa-data-source=xxyyDS:add(use-java-context=true,use-ccm=false,driver-name=com.mysql,transaction-isolation=TRANSACTION_READ_COMMITTED,min-pool-size=15,max-pool-size=150,pool-prefill=true,flush-strategy=IdleConnections,valid-connection-checker-class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker",stale-connection-checker-class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker",exception-sorter-class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter",set-tx-query-timeout=true,blocking-timeout-wait-millis=5000,idle-timeout-minutes=1,query-timeout=300,prepared-statements-cache-size=100,share-prepared-statements=true,jndi-name="java:jboss/datasources/xxyyDS",user-name=jboss,password="${VAULT::ds_MySqlDS::password::1}")
/profile=full-ha/subsystem=datasources/xa-data-source=xxyyDS/xa-datasource-properties=DatabaseName:add(value=xxyy_db)
/profile=full-ha/subsystem=datasources/xa-data-source=xxyyDS/xa-datasource-properties=ServerName:add(value=xx-cluster)
/profile=full-ha/subsystem=datasources/xa-data-source=xxyyDS/xa-datasource-properties=AutoReconnectForPools:add(value=true)
/profile=full-ha/subsystem=datasources/xa-data-source=xxyyDS/xa-datasource-properties=AutoReconnect:add(value=true)
/profile=full-ha/subsystem=datasources/xa-data-source=xxyyDS/xa-datasource-properties=useSSL:add(value=false)
/profile=full-ha/subsystem=datasources/xa-data-source=xxyyDS:enable
Any inputs on how to enable the xa-datasource on runtime would help us.
You can enable the datasource via the CLI:
/subsystem=datasources/xa-data-source=xxyyDS:write-attribute(name=enabled,value=true)
It might be required to reload:
:reload
After running through many trial and error method, we found that when adding the datasources by default it will be in enabled state. So no need to do explicitly enable when adding a datasource.
So we removed the below line from the list of CLIs.
/profile=full-ha/subsystem=datasources/xa-data-source=xxyyDS:enable
Post removing the line, the configuration of datasources through CLI and the deployment of ears went fine without issues. Posting this solution as it will be helpful for others who are facing similar kind of issue.
Finally our datasource CLIs will be like the ones below.
/profile=full-ha/subsystem=datasources/xa-data-source=xxyyDS:add(use-java-context=true,use-ccm=false,driver-name=com.mysql,transaction-isolation=TRANSACTION_READ_COMMITTED,min-pool-size=15,max-pool-size=150,pool-prefill=true,flush-strategy=IdleConnections,valid-connection-checker-class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker",stale-connection-checker-class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker",exception-sorter-class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter",set-tx-query-timeout=true,blocking-timeout-wait-millis=5000,idle-timeout-minutes=1,query-timeout=300,prepared-statements-cache-size=100,share-prepared-statements=true,jndi-name="java:jboss/datasources/xxyyDS",user-name=jboss,password="${VAULT::ds_MySqlDS::password::1}")
/profile=full-ha/subsystem=datasources/xa-data-source=xxyyDS/xa-datasource-properties=DatabaseName:add(value=xxyy_db)
/profile=full-ha/subsystem=datasources/xa-data-source=xxyyDS/xa-datasource-properties=ServerName:add(value=xx-cluster)
/profile=full-ha/subsystem=datasources/xa-data-source=xxyyDS/xa-datasource-properties=AutoReconnectForPools:add(value=true)
/profile=full-ha/subsystem=datasources/xa-data-source=xxyyDS/xa-datasource-properties=AutoReconnect:add(value=true)
/profile=full-ha/subsystem=datasources/xa-data-source=xxyyDS/xa-datasource-properties=useSSL:add(value=false)
Let me give a little background to give context to this question. Over the course of time, the application I have been assigned to work on lost the ability to be built and deployed as a full application. By that I mean the previous developer compiled the code in his local IDE, and dropped single class files, as opposed to building out proper JARs and WARs to be deployed out to tomcat. So I have been tasked to clean up the project so it is a standard deployable app again. So to sum up the important part, the application exists in a working format on a windows tomcat environment, that hasn't had a clean deploy in a long time, my goal is to make the app buildable and deployable via a jenkins CI server to a tomcat instance running on a Linux server. Now on to the problem. I get the following toplink exception in one application module.
Local Exception Stack:
Exception [TOPLINK-6007] (OracleAS TopLink - 10g (9.0.4) (Build 031126)): oracle.toplink.exceptions.QueryException
Exception Description: Missing descriptor for [class edu.cornell.finsys.datamodel.AccountDTO].
Query: ReadObjectQuery(edu.cornell.finsys.datamodel.AccountDTO)
I have verified that the toplink mapping file has been loaded by tomcat, and the AccountDTO is mapped in the file. To double check that, I have moved the mapping file out, and I get a completly different error at load time. I know the file mapping is correct, as it worked correctly on the old server. I don't know what else could be causing the toplink exception.
For more information, I am on tomcat version 6.0.37, Java version 1.6.0_45, toplink version 9.0.4.031126
Any ideas?
This may be it; right from Metalink:
Cause:
This is an issue with loading the sessions.xml file, once when the application was first deployed using that application's classloader and then not reloading the session when the application was redeployed and a new XMLContext was created. The caused us to attempt to use a session that had been loaded with a different classloader than the current application.
Possible solution:
The issue occurs when TopLink is part of the main classpath (Eg: Applib directory rather than stored in the ear file). When this happens, the static SessionManager has trouble finding descriptors the second and subsequent times an application is deployed. Basically the descriptors are indexed by class. When the application is redeployed, the classes used for the indexing are unloaded and new versions of those classes appear. This causes "Descriptor not found" exceptions.
Potential Workarounds
Put the toplink.jar file in the ear.
Write some code to manually clean up when the toplink application is torn down.
For certain architectures they may be able to use the version sessionManager.getSession() that allows the session to be refreshed.
Workaround 3 is best and very feasible. The session has to be lazily
obtained from the SessionManager and held in an application code
variable. When the application is restarted its handle on the TopLink
session will be null. The session can then be obtained from the
SesssionManager using the getSession(XMLLoader xmlLoader, String
sessionName, ClassLoader objectClassLoader, boolean
shouldLoginSession, boolean shouldRefreshSession) API with
shouldRefreshSession set to true. This will ensure that the old
session (if any) is logged out and removed from the SessionManager
before a new one is created.
Did any of the workarounds help?
What is the MBeanServerFactory.findMBeanServer(null); exactly doing?
Returns a list of all registered MBeanServers? Registered where?
I am asking because I have the following problem.
I have a java web app deployed in Tomcat using a service wrapper.
I have custom connector implementations in my server.xml that use ManagedBeans (spring enabled).
If I start the app via the service wrapper all is ok.
If I start the web app through Tomcat directly it seems that the deployment breaks.
All I see in the logs is that the connector does a
MBeanServerFactory.findMBeanServer(null);
and then tries to invoke the bean beanServer.invoke(name, operationName, null, null);
The result is a InstanceNotFoundException.
It seems that the managed beans are not loaded in case I do not use a service wrapper? Is my understanding correct? Any input on how to debug this issue is
highly welcome!
The javadoc says that when you pass null, it returns the servers registered in the current JVM. If you are using JSW, then you cannot use null as JSW forks the VM as a separate process. This is why you see the InstanceNotFoundException.
I'm trying to develop a Java EE + gxt application. I have an rpc call which calls a session bean's method.
If I compile the project and run it in the browser, it works fine, but when I use
hosted mode I get an exception like this: (edited for readability)
Exception while dispatching incoming RPC call
...
Caused by: java.lang.NullPointerException: null at org.Pecc.server.services.AppServiceImpl.
getUserEmailByName(AppServiceImpl.java:53)
Line 53 is:
return appSessionBeanBean.getUserEmailByName(name);
It's like the session bean can't be reached. Note that I have GWT4NB plugin and use it's "GWT hosted mode (w/o a Java EE server)" command, but I have glassfish running and the ejb module deployed in it. Shouldn't it be enough to work? If I remember right, I was able to use my ejb module in hosted mode at some point.
Any thoughts?
I hate to ask this, but are you able to debug and confirm the appSessionBeanBean is indeed not null? And if not, with log statements...
I found a workaround by redirecting the hosted mode browser to the module deployed in glassfish. I simply write localhost:8080/EasyTicket-web into the address bar instead of localhost:8888 (jetty's port.). Of course, glassfish has to be started for that to work.