I have my web services jar file deployed under webapps\nyx\WEB-INF\services in my tomcat server. Now I am trying to get no of active sessions using below code inside a web service method.
MBeanServer mBeanServer = ManagementFactory.getPlatformMBeanServer();
ObjectName objectName = new ObjectName("Catalina:type=Manager,context=/nyx/services,host=localhost");
Object activeSessions =mBeanServer.getAttribute(objectName,"activeSessions");
But this gives me Instance not found exception.
Can someone help me with the value for the context attribute?
Try to refer to this SO question, reading your code the first thing that i think is try using JMX (Java Management eXtension)
Something like this:
JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:9999/jmxrmi");
try(JMXConnector jmxc = JMXConnectorFactory.connect(url)) {
MBeanServerConnection mbsc = jmxc.getMBeanServerConnection();
ObjectName mbeanName = new ObjectName("Catalina:type=Manager,context=/,host=localhost");
Object value = mbsc.getAttribute(mbeanName, "activeSessions");
}
EDIT
If you need to retrieve the number of session locally your code should be fine, try with your code but getting the context at runtime.
Override the init method:
#Override
public void init(final ServletConfig config) throws ServletException {
context = config.getServletContext().getContextPath();
}
Then pass it as ObjectName parameter:
ObjectName objectName = new ObjectName("Catalina:type=Manager,context="+context+",host=localhost");
Related
In the internals of an ContextListener how can I find out the port the Web App is running on
I have a Java Web app project with JSP pages as frontend. The project implements a ServletContextListener to connect to the backend. This ContextListener accesses the database by instantiating an access class DBQuery in its contextInitialized method:
ServletContext ctx = contextEvent.getServletContext();
dbQuery = new DBQuery();
ctx.setAttribute("dbQuery", dbQuery);
The JSP pages then refer to this DBQuery object via
getServletContext().getAttribute("dbQuery");
and call the methods of DBQuery as they desire.
Now the problem: In the DBQuery class I need to do different things depending on which host and on which port the web app runs.
I found a way to determine the host name in DBQuery:
import java.net.InetAddress;
String hostName = InetAddress.getLocalHost().getHostName();
Strangely InetAddress does not seem to have a method to get the port number. How can I find out in the DBQuery class on which the port the web app runs on?
Following Steve's comment to look at a GitHub gist, I came up with the following adapted code which does exactly what was asked for:
String port = "80";
try {
MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
Set<ObjectName> objs = mbs.queryNames( new ObjectName( "*:type=Connector,*" ),
Query.match( Query.attr( "protocol" ), Query.value( "HTTP/1.1" ) ) );
for ( ObjectName obj : objs ) {
String scheme = mbs.getAttribute( obj, "scheme" ).toString();
port = obj.getKeyProperty( "port" );
break;
}
} catch ( MalformedObjectNameException | UnknownHostException | MBeanException | AttributeNotFoundException | InstanceNotFoundException | ReflectionException ex ) {
ex.printStackTrace();
}
So the main thing is to instantiate a MBeanServer and utilise its attributes.
The following code works fine in JBoss, but when deployed in Apache Tomcat it gives
javax.naming.NameNotFoundException: Name [SPConnectorClient] is not bound in this Context. Unable to find [SPConnectorClient].
Code:
logger.info("SPConnectorClientEJB::callSubmitRequest");
SPResponse response = new SPResponse();
Object responseObj = null;
try
{
InitialContext ctx = null;
ctx = new InitialContext();
logger.info("Got InitialContext");
SPConnectorClientHome home = (SPConnectorClientHome)ctx.lookup("SPConnectorClient");
SPConnectorClientRemote remote = null;
remote = home.create();
logger.info("Got Remote Object!");
Code in Setenv.sh file:
JAVA_OPTS="$JAVA_OPTS -DSPAppspecificJNDI=java:global/SP/sp_app_specific/SPConnectorClient!com.cdac.sp.SPConnectorClientRemote"
I'm working with weblogic Server. I was wondering if after binding an object in the JNDI context it would be possible to make remote call on this object (executing it inside the remote JVM).
In my local JVM:
Context ctx = null;
Hashtable<String, String> env = new Hashtable<String, String>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
env.put(Context.PROVIDER_URL,"t3://remoteServer:7001/);
env.put(Context.SECURITY_PRINCIPAL,"");
env.put(Context.SECURITY_CREDENTIALS,"");
try {
ctx = new InitialContext(env);
MyObjectImpl obj1 = new MyObjectImpl();
ctx.bind("jndi_name", obj1);
//Now my object can be retrieve from the JNDI context under "jndi_name"
MyObjectImpl obj2 = (MyObjectImpl)ctx.lookup("jndi_name"); //lookup of object
System.out.println(obj2.method(1,2)); //call
}catch (Exception e) {
// a failure occurred
}
But the call is done locally in the client JVM and not the remote JVM.
Is there any way to counter this problem?
Regards,
Make sure you have a remote interface(using annotation #Remote) for jndi lookup.
You can see this example: http://middlewaremagic.com/weblogic/?p=5532 (search for the class “CalculatorBean.java”).
Does anyone now a way to obtain server Context using Embeddable API (using org.glassfish.embeddable.GlassFish, not javax.ejb.embeddable.EJBContainer)?
It would be possible if there's a way to obtain EJBContainer from a running Glassfish, but I can't find even the list of services available for lookup.
Here's a workaround - we can obtain InitialContext as an external client.
For the full explanation check EJB_FAQ . This way at least remote EJBs could be tested:
So the full example will look like:
//Start GF
GlassFishRuntime gfRuntime = GlassFishRuntime.bootstrap();
GlassFish gf = gfRuntime.newGlassFish();
gf.start();
//Deploy application with EJBs
Deployer deployer = gf.getService(Deployer.class);
String deployedApp = deployer.deploy(new File(...), "--force=true");
//Create InitialContext
Properties props = new Properties();
props.setProperty("java.naming.factory.initial",
"com.sun.enterprise.naming.SerialInitContextFactory");
props.setProperty("java.naming.factory.url.pkgs",
"com.sun.enterprise.naming");
props.setProperty("java.naming.factory.state",
"com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
props.setProperty("org.omg.CORBA.ORBInitialHost", "localhost");
props.setProperty("org.omg.CORBA.ORBInitialPort", "3700");
InitialContext ic = new InitialContext(props);
//Lookup EJBs
ic.lookup(...)
//Stop GF
gf.stop();
gfRuntime.shutdown();
//CORBA stuck thread, have to kill it manually
System.exit(0);
Note there's a System.exit(0) at the end - com.sun.corba.ee.impl.javax.rmi.CORBA.Util.KeepAlive thread is running even after the server stop preventing JVM from stopping...
As far as I know, you can initialize the InitialContext class to obtain a context, that can further be used to perform the lookup. This was tested, and found to work in the context of looking up an EJB, deployed in the embedded container. The EJB was not configured to allow access to specific roles, in which case the com.sun.appserv.security.ProgrammaticLogin class (not exposed via the Embeddable EJB API) might help; this was not tested, but is the recommended way to initialize the Principal for the thread accessing an EJB.
A more or less complete example that runs from Maven and uses the embedded Glassfish dependency in a POM (not reproduced here, for brevity) follows:
The EJB interface:
public interface EchoManager
{
String echo(String message);
}
The Session Bean:
#Local(EchoManager.class)
#Stateless
#EJB(name="java:global/glassfish-ejb-validation/EchoManager",beanInterface=EchoManager.class)
public class EchoManagerBean implements EchoManager
{
public String echo(String message)
{
return message;
}
}
The unit test:
public class EchoManagerTest
{
#Rule
public TestName testMethod = new TestName();
private static final Logger logger = Logger.getLogger(EchoManagerTest.class.getName());
#Test
public void testEchoWithGlassfishRuntime() throws Exception
{
logger.info("Starting execution of test" + testMethod.getMethodName());
GlassFish glassFish = null;
Deployer deployer = null;
String appName = null;
try
{
//Setup
BootstrapProperties bootstrapProps = new BootstrapProperties();
GlassFishRuntime glassFishRuntime = GlassFishRuntime.bootstrap(bootstrapProps);
GlassFishProperties gfProps = new GlassFishProperties();
glassFish = glassFishRuntime.newGlassFish(gfProps);
glassFish.start();
deployer = glassFish.getDeployer();
ScatteredArchive archive = new ScatteredArchive("glassfish-ejb-validation", Type.JAR);
archive.addClassPath(new File("target", "classes"));
archive.addClassPath(new File("target", "test-classes"));
appName = deployer.deploy(archive.toURI(), "--force=true");
// Setup the context
InitialContext context = new InitialContext();
//Execute (after lookup the EJB from the context)
EchoManager manager = (EchoManager) context.lookup("java:global/glassfish-ejb-validation/EchoManager");
String echo = manager.echo("Hello World");
//Verify
assertEquals("Hello World", echo);
}
finally
{
if(deployer != null && appName != null)
{
deployer.undeploy(appName);
}
if(glassFish != null)
{
glassFish.stop();
glassFish.dispose();
}
logger.info("Ending execution of test" + testMethod.getMethodName());
}
}
}
Note that the EJB is deployed with a explicit portable JNDI name (via the #EJB annotation), as I have other tests that use the public embeddable EJB API in other tests, and it is more or less difficult to specify an application name in such tests; each test execution might result in a different JNDI name for the EJB, thus necessitating an explicit JNDI name to be specified.
I am using Tomcat server in java and wanted to be able to access the ServletContext from the restlet Resource in order to access my cached DataSource object (to pool mysql connections). org.restlet.resource.Resource comes with a Context object but that is not in any way related to the ServletContext. So after some googling around, I found the following:
final String contextKey = "org.restlet.ext.servlet.ServletContext";
final String poolKey = "MyCachedDBPool";
final Map<String, Object> attrs = getContext().getAttributes();
final ServletContext ctx = (ServletContext) attrs.get(contextKey);
if (ctx == null) {
throw new Exception("Cannot find ServletContext: " + contextKey);
}
final DataSource ds = (DataSource) ctx.getAttribute(poolKey);
if (ds == null) {
throw new DetourQAException("DataSource not stored in context"
+ poolKey + "attr");
}
But it returns null for the ServletContext. Has anybody successfully accessed the ServletContext from within the restlet resource and how did you do it?
If this is not the recommended way to do connection pooling, what is the best way to do connection pooling in the restlet?
This was the way to do it before Restlet 2.0 (actually I think they changed it around 2.0-M5, or so). Anyway, the way you'd do it now is:
ServletContext sc = (ServletContext) getContext().getServerDispatcher().getContext().getAttributes().get( "org.restlet.ext.servlet.ServletContext" );
Hope that helps.