I was developing a website using Java EE in Eclipse and testing it locally using Glassfish, but after updating to OS X 10.10.3, the server started to timeout during launch. When trying to launch from Terminal, Glassfish failed to start, but when used with sudo, it started successfully. After looking around the web for a bit, I found that with 10.10.3 Glassfish required root privileges to run. Is there a way that I can make Eclipse start the server with root privileges or bypass the problem some other way?
EDIT: This is the log after using Siddharth's first option (the second one did not make any difference when running from Eclipse):
2015-05-16T16:30:39.877+1000|Info: Running GlassFish Version: GlassFish Server Open Source Edition 4.1 (build 13)
2015-05-16T16:30:39.879+1000|Info: Server log file is using Formatter class: com.sun.enterprise.server.logging.ODLLogFormatter
2015-05-16T16:30:39.980+1000|Info: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
2015-05-16T16:30:39.981+1000|Info: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
2015-05-16T16:30:39.984+1000|Info: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.
2015-05-16T16:30:40.104+1000|Info: Authorization Service has successfully initialized.
2015-05-16T16:30:40.130+1000|Info: Registered org.glassfish.ha.store.adapter.cache.ShoalBackingStoreProxy for persistence-type = replicated in BackingStoreFactoryRegistry
2015-05-16T16:30:40.375+1000|Info: Grizzly Framework 2.3.15 started in: 25ms - bound to [/0.0.0.0:8080]
2015-05-16T16:30:40.391+1000|Info: Grizzly Framework 2.3.15 started in: 1ms - bound to [/0.0.0.0:8181]
2015-05-16T16:30:40.397+1000|Info: Grizzly Framework 2.3.15 started in: 1ms - bound to [/0.0.0.0:4848]
2015-05-16T16:30:40.427+1000|Info: Grizzly Framework 2.3.15 started in: 0ms - bound to [/0.0.0.0:3700]
2015-05-16T16:30:40.428+1000|Info: GlassFish Server Open Source Edition 4.1 (13) startup time : Felix (1,426ms), startup services(619ms), total(2,045ms)
2015-05-16T16:30:40.602+1000|Info: JMXStartupService has started JMXConnector on JMXService URL service:jmx:rmi://olivers-imac.gateway:8686/jndi/rmi://olivers-imac.gateway:8686/jmxrmi
Sometimes it only reaches here.
2015-05-16T16:30:40.602+1000|Info: Grizzly Framework 2.3.15 started in: 0ms - bound to [/0.0.0.0:7676]
2015-05-16T16:30:40.670+1000|Info: Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl#ae372b9 as OSGi service registration: org.apache.felix.framework.ServiceRegistrationImpl#67403656.
Sometimes it only reaches here.
2015-05-16T16:30:40.904+1000|Info: visiting unvisited references
2015-05-16T16:30:41.444+1000|Info: Created HTTP listener http-listener-1 on host/port 0.0.0.0:8080
2015-05-16T16:30:41.450+1000|Info: Created HTTP listener http-listener-2 on host/port 0.0.0.0:8181
2015-05-16T16:30:41.453+1000|Info: Created HTTP listener admin-listener on host/port 0.0.0.0:4848
2015-05-16T16:30:41.471+1000|Info: Created virtual server server
2015-05-16T16:30:41.473+1000|Info: Created virtual server __asadmin
2015-05-16T16:30:41.638+1000|Info: Setting JAAS app name glassfish-web
2015-05-16T16:30:41.639+1000|Info: Virtual server server loaded default web module
2015-05-16T16:30:41.927+1000|Info: Java security manager is disabled.
2015-05-16T16:30:41.928+1000|Info: Entering Security Startup Service.
2015-05-16T16:30:41.930+1000|Info: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.
2015-05-16T16:30:41.969+1000|Info: Security Service(s) started successfully.
2015-05-16T16:30:42.155+1000|Info: visiting unvisited references
2015-05-16T16:30:42.170+1000|Info: visiting unvisited references
2015-05-16T16:30:42.172+1000|Info: visiting unvisited references
2015-05-16T16:30:43.060+1000|Info: Initializing Mojarra 2.2.7 ( 20140610-1547 https://svn.java.net/svn/mojarra~svn/tags/2.2.7#13362) for context ''
2015-05-16T16:30:43.655+1000|Info: HV000001: Hibernate Validator 5.0.0.Final
2015-05-16T16:30:43.965+1000|Info: Loading application [__admingui] at [/]
2015-05-16T16:30:43.966+1000|Info: Loading application __admingui done in 3,296 ms
EDIT: I have marked Siddharth's answer correct, as it helped me the most, however the problem solved itself completely only after updating to El Capitan.
It is a known issue and has now been fixed (see this). If you want to continue with the current version of Glassfish then may be you can consider a solution published here.
Quoting the same solution below :-
It turns out that the Glassfish team made an assumption that they
could use launchctl bsexec in their
nucleus/admin/launcher/src/main/java/com/sun/enterprise/admin/launcher/GFLauncher.java
file.
This sub-command now requires root privileges.
Someone has submitted a patch to Glassfish trunk, but if you want to
continue using Glassfish immediately, you can create this script
somewhere e.g. ~/bin/launchctl.
#!/bin/bash
# A little hack to wrap launchctl in order to
# successfully start Glassfish on Yosemite 10.10.3+
if [[ ${1} == "bsexec" ]]; then
nohup ${#:3}
else
/bin/launchctl ${#}
fi
Remember to ‘chmod 755 ~/bin/launchctl’ so that it is executable.
Also remember that your ~/.profile or ~/.bash_profile must have
something like this:
export PATH="$HOME/bin:$PATH"
The idea here is that this script is a wrapper for launchctl. As a
user in Yosemite 10.10.3, you cannot run bsexec, but you may want to
use launchctl for other things.
I had the same problem with eclipse luna Glassfish tools that I had installed from Eclipse MarketPlace, under OSX 10.9.
I ran across the post below on stack overflow and I guess, after the issue of the root access being resolved in 10.10, I believe that the proposed solution there should work for your case too, as it did for me.
Don't forget to uninstall the Glassfish Tools that you installed previously from the Marketplace!
Installing Glassfish tools in eclipse luna
Related
Where can I find current instructions for how to set up Remote Debugging of Wildfly 20 from Eclipse 2020-06? My searches have found posts going back to 2014 they don't work. My most recent attempt is to follow https://tools.jboss.org/documentation/howto/configure_remote_server.html. This has no date on it and it is for connection to EAP 6.1 instead of Wildfly 20 but at least it is from tools.jboss.org and the instructions matched Eclipse 2020-06.
The problem is that when I right click on on the new Server just created with these instructions and select Debug I get the following error:
failed to copy to /opt/wildfly-20.0.1.Final/standalone/deployments/MyApp.war/META-INF/MANIFEST.MF on host 192.168.1.19
The requested path is not found on the remote system.
Here are what I think are important facts:
The path /opt/wildfly-20.0.1.Final/standalone/deployments DOES exist on the Wildfly 20 server # 192.168.1.19.
The Wildfly 20 server is started with /opt/wildfly-20.0.1.Final/standalone/deployments/MyApp.war in place. The Management console shows that MyApp is Deployed and I can access the app from a remote machine so Wildfly and the server are running.
I can connect from Eclipse to the Wildfly server using the Remote Systems item that creating the new Server created. In particular, I can use the root item to "roam around" the file system on the Wildfly server so that suggest to me that Eclipse can establish a connection to the Wildfly server.
The instructions in the URL above did not include this but in the Server's Properties the Web and Management ports were both 0. I manually set them to 8080 and 9990 respectively.
Thank you in advance.
Since your installation is on /opt I guess it was done with root privileges. I'm not sure your user has sufficient rights to be able to access those paths.
As far as I can tell /opt is the recommended installation location but I finally got the server to at least deploy so that problem is solved. See updated question at Attempt to debug a remote Wildfly 20 server failing.
I'm running on Win 7 using Eclipse 4.2 starting a web app on a Tomcat 7 server and using Derby database. I have tried many approaches but run consistently into a common problem:
Everything works just fine the first time I start up and run.
When I redeploy my application after a change, all database connections hang (any kind of restart).
If I stop Eclipse and restart Eclipse, that clears up the problem and the next run works fine again.
Having done some investigation, it appears that the problem is that the Derby port (1527) is not released from one execution of the server to the next. That seems very strange to me since Derby is started by the Tomcat instance which is a separate javaw process.
I've tried:
Configuring the Derby connection as a Tomcat resource
Establishing the connection within my code (rather than via Tomcat resource)
Both the embedded and the network driver
Starting / stopping the network driver from a servlet on startup and shutdown of the Tomcat server
Shutting down the embedded driver via servlet on shutdown of Tomcat
Again, every approach works fine to connect the first time.
One other symptom that doesn't appear to be related (except for as a possible indicator of whether or not shutdown completes correctly) is that the db.lck file for my database never gets deleted. However, whether or not it exists has no bearing on whether or not I can reconnect (only stopping/starting eclipse has an impact).
Any insight would be appreciated.
Thanks!
After some further investigation I'm going to call this a duplicate of: Cannot create JDBC driver of class ' ' for connect URL 'null' : I do not understand this exception. It's not quite the same thing, but that solution (creating META-INF/context.xml) allows it to proceed to failing calls rather than hangs, which is a significant improvement and suggests it's largely related.
I did finally figure this out. It turns out I had the derby jars in the Tomcat lib folder (for Tomcat) and in the deployment assembly for my application in Eclipse (rather than just in the build path). So Tomcat was using the built-in libs, while my app was using the embedded libs, and this resulted in conflicts. Leaving the libs as part of Tomcat and removing them from my war file solved the problem completely.
My setup is as following:
Production web server with Glassfish 3.1.1 wrapped into a windows service.
Developing environment with Netbeans 7.1 with the included Glassfish server.
I thought a valid way to deploy updates to production server was to copy the content of the Netbeans /build directory and it worked well many times.
Unfortunately I experienced a major problem, described in the link below, where new roles were not recognized because glassfish had cached data somewhere else.
Glassfish: how to investigate roles/groups problems
I checked the Glassfish configuration a lot but couldn't find any parameters like 'rebuild cached data at the server start'. So my question is how can I deploy updates in my production server being sure that my changes will not be invalidated by pre-compiled cached data ?
Thanks
Filippo
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.