I am trying to use Install4j's Service Launcher to deploy a bundled JBoss EAP 6.1 with our application. JBoss is refusing to start because:
java.lang.RuntimeException: JBAS014670: Failed initializing module org.jboss.as.logging
...
Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
I already have this java.util.logging.manager system property set but I believe Install4j's wrapper is somehow initializing a JRE-wide logging facility prior to JBoss getting a chance. So JBoss just refuses to run.
Please see this JBoss issue where users with the TanukiSoftware wrapper face a similar problem. Is there any way of disabling this earlier initialization in the Install4j service launcher so that JBoss will run?
In install4j 5.1.8, there will be a system property "install4j.noLoggingFix" that prevents the initialization of the logging system. Please contact support#ej-technologies.com to get an interim build with this feature.
Related
I have been trying to create my first RESTful execrcise using. But I am unable to deploy module due to error "com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Invalid resource : jdbc/playerDB__pm"
I checked and I have JNDI, daata source created.
Unlike specified in link. I am using:
-Netbeans 8.0.3, Java EE 7, GlassFish Server 4.
Also I have checked GlassFish is running fine.
Edit 1:
I have re-checked my 'Services' tab, and I could not find jdbc/__playedDB ,even though I have created it.
Its a bug, the JDBC resource file is not being created (atleast with versions I am using: GlassFish 4.1, Netbeans 8.0.2). Using GlassFish manually create.
There could still be different error untill you set following connectins:
database(data source) <- connection pool <- JNDI.
im trying to migrate JBoss AS7.1 to Wildfly 10, i just followed some threads and i came upon this AS7 to Wildfly 10 guide. Basically it just tells how to migrate server configuration as well as application configuration.
But the problem is, it says to execute ":migrate" function "/subsystem=jacorb:migrate" on jboss cli (Jboss AS7.1 because it says execute on legacy subsystem) but it always throws an error, see below
No handler for migrate at address
Anyone familiar in executing migrate on jboss cli please point me to the right direction
UPDATES
I opted to migrate to wildfly10 from jboss-as7.1 manually (labor intensive, hassle), maybe if i have time to investigate about this i could feedback it there but as of know i time is of the essence and i need to migrate immediately.
JBoss startup and Server logs are not getting updated completely like started in XXXX ms. But all the services are being deployed successfully. Is there any way to debug why the logs are not printing?
Thanks,
Kusuma
Just check on your the logging subsystem configuration in your standalone.xml.
If that's not the issue, this is probably a problem with your application configuration and not JBoss, probably you just have to exclude some logging libraries in your jboss-deployment-structure.xml, to use the provided and not the jboss instance libs.
I have disabled the HDScanner bean (by removing JBOSS_HOME/deploy/hdscanner-jboss-beans.xml) in JBoss 5.1.0 so that I must do all deployments to running instances through Twiddle (applications found in the deployment directory are automatically deployed on startup).
After I have done this I can deploy and undeploy a war by using the following commands:
twiddle.sh -s localhost invoke "jboss.system:service=MainDeployer" deploy "file:/path/to/my.war"
twiddle.sh -s localhost invoke "jboss.system:service=MainDeployer" undeploy "file:/path/to/my.war"
This works fine.
However, if I restart JBoss between the deploy and the undeploy, when I try to undeploy the app using twiddle, the app remains deployed and the JBoss logs display :
2011-04-18 14:30:41,318 WARN [org.jboss.deployment.MainDeployer] (WorkerThread#0[10.21.4.61:43700]) undeploy 'file:/path/to/my.war' : package not deployed
Am I doing something wrong, expecting something that's not possible, or is this a bug in JBoss?
If I am doing something wrong, what is the correct way to undeploy an app that has been deployed using twiddle on an instance of JBoss that has been subsequently restarted?
Edit
Without looking at the source code of JBoss, it seems to me that apps that are deployed on startup are managed in a different place from those deployed through Twiddle. Ie if an app is deployed at startup it is not known of by the mechanism accessed through Twiddle, hence the "package not deployed" error.
So, is there a way to access this other deployment manager through Twiddle such that apps that are present at startup can still be undeployed?
I have done a lot of testing on this, and basically apps that are found at startup are (rightly) considered to be part of the JBoss 'core' and are therefore deployed automatically as part of the startup process. This applies for things such as the jmx-console, and therefore applies for other .wars too. Whether through design or through consequence, these resources that have been automatically deployed during startup cannot be managed by twiddle invokations.
I'm trying to combine Eclipse RCP with RMI. For that purpose I created six bundles:
(In parenthesis are dependencies)
Core: Interfaces for client and server
Server(Core): Server implementation and Registry start class
ServerApp(Server): GUI client which basically just instantiates the registry starter (and starts it on Activation)
Client(Core): Client implementation
ClientApp(Client): GUI client
Now I started the serverapp, but I got a
Caused by: java.lang.ClassNotFoundException: core.rmi.CallbackServerInterface (no security manager: RMI class loader disabled)
Now I started the server with
-consoleLog -Djava.security.policy=java.policy -Djava.rmi.server.codebase=file:${workspace_loc}/core/
(My java.policy file is in the core plugin).
I thought the problem was the classpath. So I made core and server buddies:
Eclipse-BuddyPolicy: registered
in the core bundle manifest file and
Eclipse-RegisterBuddy: core
In the server bundle manifest file.
Which didn't help, since I got the exact same error.
Does anyone know where I could have gone wrong on this one?
So apparently the problem was, that OSGI uses its own Classloader. So before we do the Naming bind we need:
Thread.currentThread().setContextClassLoader(
this.getClass().getClassLoader());
After this, the server works like a charm, and the client can connect.