We Keep Coding

Many versions on one IBM Websphere server

Is it possible to deploy different versions of single application on one IBM Websphere Application Server (WAS)?
For example I have:
App1 with url binding http://app/1.0/service/
App2 with url binding http://app/2.0/service/
Is it possible?
I think not due to port listening issue, but maybe there is some chance...

It should be possible, but with some restrictions (depending on your application). If you have WAS ND 8.5.5, then you have Application Edition management feature. Read more details on that page.
If you are on the older version, you will have to change several things during deployment, e.g.:
context-root of the application
JNDI EJB binding names
if other version is using different database - update the JDBC references
if other version is using additional resources (like queues, qcf) update them also.
Actually, port listening has nothing to do with it, as both application will use same port, but different context-roots.
This of course assumes that application doesn't have hard coded values in it (like context root, jndi names, etc).

Use Jolokia to monitor JMX endpoint of webapp on same Tomcat server

Jolokia is uncharted territory for me, and after having read the documentation, I'm still not sure if it'll work with the scenario I have in mind.
Setup:
Tomcat application server (version ranges from 6.x to 7.x), usually on a Windows platform, occasionally a flavour of Linux.
Deployed third-party Java web application (SAP BusinessObjects) with JMX monitoring enabled (accessible through RMI).
Possible gotcha's:
The Java web application to be monitored is commercial and closed source, so modifications are not possible. The only thing that can be changed is the JMX port number
The JMX endpoint is a custom one, thus not the default jmxrmi endpoint.
The JMX connection requires authentication.
Goal:
What I'd like to do is to deploy the Jolokia WAR file onto the Tomcat server and then configure it so that I can read the MBean attributes from the other web application.
I would code the client myself using Python (version 3) and the Requests HTTP library.
I've been reading through the Jolokia documentation (again, I'm a complete newbie at this point), but can't figure out if this would be possible or not (as I can't seem to find where to enter the JMX/RMI url or the authentication information).
Questions:
Can I use the WAR agent for this setup?
If not, can you please explain why (so I can understand, not because I don't believe you). Also, is there another agent that's more suited for this scenario?
If yes, can you point me in the right direction how to configure the Jolokia to the web application to connect to?

First of all, Jolokia by passes the JSR-160 connector stuff completely, so there is no need for any JMX/RMI authentication. The whole purpose of Jolokia is to provide a bridge over HTTP/JSON to the internal JMX subsystem. Depending on the agent, you can secure Jolokia quite easily. For the WAR agent, securing is the same as for any Java EE web app: Setup some roles and users for tomcat (e.g. in tomcat-users.xml) and reference the role in the security contstraints within the jolokia.war's /WEB-INF/web.xml.
To your questions:
Yes, you can. If you don't have any specific authentication needs, simply drop the jolokia.war into tomcat's /webapps directory. I suggest to try this first before adding security. For deinstalling the agent, simply remove the war.
As an alternative, you could also use the JVM agent, which opens an own HTTP server on an extra port (default: 8778). More on this in the reference manual
There is no need for a dedicated connection to the web app since MBeans are registered globally and are accesible from anywhere in the JVM. A webapp should of course select carefully the management information it exposes. So, there is no extra step needed and you can access the MBeans for the WEB app directly (except when it does something unusual with Java security, but I don't think so).
To test the installation, simply connect to the Tomcat with your browser and the context /jolokia (e.g. "http://localhost:8080/jolokia"). You should see the version information about the agent itself.
The next step would be to explore the JMX namespace, either with the browser (and operation "list" like in http://localhost:8080/jolokia/list , but that's tedious) or with a client like j4psh or hawt.io. Hopefully you will find the MBeans of your webapp you are looking for.

Create a vendor-neutral EJB3 client

Is it possible to create a client that accesses an EJB3 bean, with the client having no dependence on a vendor JAR or configuration? We currently need to support scenarios where our service is deployed on a WebSphere or JBoss server, and the client is deployed as an application either on a WAS or JBoss, or is running as a standalone app.
I used to be able to do to this with EJB2.x beans, I just needed to create stubs using RMIC.
But with EJB3, If I'm connecting to WebSphere I have to include thinclient JARs, plus I have to pre-generate the stubs using WAS tools. For JBoss I have to use jboss-client.jar.

No, this is not possible. This has been made explicit in section 10 of the EJB 3.2 specification:
This chapter describes the interoperability support for accessing an
enterprise bean through the EJB 2.1 remote client view from clients
distributed over a network, and the distributed interoperability
requirements for invocations on enterprise beans from remote clients
that are Java Platform, Enterprise Edition (Java EE) components.
Distributed Interoperability is not defined for the EJB 3.x remote client view.
Also note section 10.5.5:
System value classes are serializable value classes implementing the
javax.ejb.Handle, javax.ejb.HomeHandle, javax.ejb.EJBMetaData,
java.util.Enumeration,java.util.Collection, and java.util.Iterator
interfaces. These value classes are provided by the EJB container
vendor. They must be provided in the form of a JAR file by the
container hosting the referenced bean. For interoperability scenarios,
if a referencing component would use such system value classes at
runtime, the Deployer must ensure that these system value classes
provided by the container hosting the referenced bean are available to
the referencing component. This may be done, for example, by including
these system value classes in the classpath of the referencing
container, or by deploying the system value classes with the
referencing component’s application by providing them to the
deployment tool.
For WebSphere Application Server, the EJB thinclient contains these system value classes as well as the IBM JNDI implementation that uses CosNaming. In theory, this thinclient is not needed if you don't need the system value classes and your client JVM has its own ORB with an implementation of CosNaming.

Short answer: No, it's not possible, as a client needs three things:
The interface classes.
The client libraries of the server AS (yes, sadly)
A configuration telling the client the server address/jndi lookup path (qa, prod etc.)
If your client is running on the same product (let's say JBoss to JBoss communication), you will not be in need of client libraries and just be able to do a remote lookup. If you have a mix of client/server application servers this will make things complicated, as you will have to run client libraries of one product in another server product.
Speaking of standalone applications running as clients, I'd just build and provide 1 heavy client jar/lib containing not only the interface classes, but also the client libs of both servers. Then providing a small helper class that returns the correct InitialContext created and based either on JBoss or Websphere depending on a flag in the client configuration.
I know this last idea ain't a clean solution, though might even work in a different AS product running as "client".

List all JNDI ports

Is that possible to find all open ports on my machine that were registered with JNDI ?
It would be good to find out some util from Ubuntu but Java code also will be OK.
UPDATE: After JSP's clarification I have revised my question.

I would do the following:
A. Parse your application server configuration - for example, for standalone configuration of Jboss AS 7.x , you should parse the standalone/configuration/standalone.xml
B. Read the JNDI configuration from the XML, and understand what ports should be used.
C. Use
System.getRuntime().exec
In order to invoke netstat -na , filter out those ports who exist in the list obtained from A, and that are in ESTABLISHED state.
Some issues wiht my solution:
A. As far as I know, According to Java EE spec, you should not execute process from a Java enterprise application.
To overcome this, you can have some j2se application running as service, communication with the application server.
B. I assumed that the server and the code that needs to know about the JNDI ports exist on the same machine.
If the code that needs to know the ports should be run on a different machine, you should expose this information to the client (i.e - via web UI, REST, etc...)

Connect visualvm to websphere 7

I am trying to get visualvm and websphere 7 to work together on my local windows desktop. I try to connect through JMX but no luck. Has anybody managed to get visialvm and websphere 7 to work and ow did you do it?
Regards
FF

I got it to work with the help of the VisualVM team in Praha (Thanks Tomas!):
1) On the admin console (Click on Servers -> Server types -> WebSphere application servers -> server1 -> Java and Process Management -> Process definition -> Java Virtual Machine), add the following line into the field of
Generic JVM Argument (note that the first system property is equal to
nothing and no equal sign for the second system property):
-Djavax.management.builder.initial= -Dcom.sun.management.jmxremote
2) Add or uncomment the following three lines in file /opt/IBM/
WebSphere/AppServer/java/jre/lib/management/management.properties
(or / lib/management/management.properties):
com.sun.management.jmxremote.port=3333
com.sun.management.jmxremote.authenticate=false
com.sun.management.jmxremote.ssl=false
com.sun.management.jmxremote.local.only=false
3) Connect VisualVM!

It is possible to set these parameters port, authenticate and ssl as JVM Arguments like -Dcom.sun.management.jmxremote.port=1300
I have another issue: by using the mbean visualvm plugin I can not see any relevant Websphere mbean.

It depends on what you want to achieve and the constraints you have. What you need to know is that there are two MBean servers in WebSphere: in addition to the platform MBean server created automatically by the JRE, WebSphere also creates its own MBean server. Here are the two options you have:
Configure your WebSphere server as described in the answer given by user271858. This will allow you to connect to the platform MBean server. You will get access to the standard platform MBeans that provide process information (RAM, CPU, threads, etc.). On the other hand, you won't be able to access WebSphere's MBeans (implementing certain administrative actions, providing application metrics, etc.). You also need to be aware that by changing the configuration of the WebSphere server, you bypass WebSphere's security.
Connect to WebSphere's MBean server. WebSphere supports several protocols to do that (mainly SOAP and RMI), but none of them is completely standard. This means that you will need to add some of the WebSphere libraries (namely the admin thin client) to VisualVM. It is probably possible to do that (It works with JConsole, so in principle it should be possible with VisualVM as well), but it's tricky, especially it you need to connect to a WebSphere server that has security enabled.
A simpler option is to install the VisualWAS plugin into VisualVM. It relies on an Open Source implementation of one of the proprietary WebSphere protocols and therefore doesn't require any additional WebSphere library.
This will give you access to MBeans registered in WebSphere's MBean server, but not to the standard platform MBeans, i.e. the relevant parts (related to memory, CPU and threads) in VisualVM will be disabled. You can however cross-register the platform MBeans in WebSphere's MBean server, and the VisualWAS project provides a solution for this as well (in the form of a plugin to be installed into WebSphere). You will then have access to all features in VisualVM, and you don't need to bypass WebSphere's security.