I have application running on Weblogic. And I have another application which connects to one deployed on Weblogic and uses EJB of it. I am successfully connecting to EJB using JNDI, even my debugger shows that this class is currently launched (but the name is changed - WL added something to end of class name(like if class was AEjb, it shows that launched class is AEjb_krtm_pfff ...)). But I can't see nor variables, nor lines executed. So are there any ways to see what's happening with this EJB class?
It's no different than the way you are debugging the client side application. Add your EJB source code also in the debugger path and add a break point on EJB source code which you want to debug.
If your EJB is deployed on different Weblogic server, then you may want to use remote debugging option.
Looks like you need to debug the EJB code deployed on the WebLogic server, you can do the debugging using any of the following options:
Use remote debugging as suggested by Yogendra
If you can control the deployment of the Application containing EJB, then deploy it in exploded directory mode on Administration Server and use JDeveloper Integrated WebLogic Server to debug the source whenever client pings the EJB code deployed on the server.
If you are using standalone client to call EJB, and have been facing an issue on client side, the same can be debugged using system property on client side.
-Dweblogic.ejb.enhancement.debug=true (post WLS 10.3.1.0)
-Dweblogic.ejb.proxy.debug=true (src branch)
Related
an ear is deployed in a Jboss server (wildfly 11). while deployment is on going if client tries to call any EJB , call will hit the LoginModule.this makes some problem due to the internal design in the application.
what is the best reliable way to detect the deployment status of a given ear (or the status of the server) programmatically from a class which is a part of that ear(run in the same JVM , in the same ear).
JBoss is providing a CLI API to access management with a Java API (org.wildfly:wildfly-cli). CLI offers commands for deployment, undeployment and checking deplyoment status. You can call the HTTP management API directly, if you want to.
Doing this from your EAR while it is deployed might be interesting. Perhaps you can install a server side container interceptor with your EJBs. I never tried ...
this may be two questions in one, so...Sorry, please correct me if I'm wrong.
I have to deploy a web service developed with JPA, JSP and Glassfish 3.1.2, in a machine which only has apache Tomcat 7 as server installed on Windows 7.
I don't really know how apache can connect to the database externally, or if that is really possible if you don't use TomEE.
I know in Glassfish you can have a connection pool and a jdbc resource, and if you're using JPA, that's how the connection to database works(kindof), so you can deploy the .war file. But, if you only have a Tomcat and the app is using JPA, so it does not connect itself to the database(It does not have a class with a connection credentials), How can I achieve this?
Or, Can I deploy the .war of the web service on Glassfish and then be consumed by an application that only works with apache Tomcat on client side? Am I mixing concepts which should not be mixed?
Any enlightenment is highly appreciated.
You can use Tomcat with JPA, you can even use it in a standalone java application. Define a persistence unit name in persistence.xml, make sure the transaction type is RESOURCE_LOCAL (you can't use JTA in Tomcat, make sure to check this), and get a reference to the EM using the following
EntityManagerFactory emf = Persistence.createEntityManagerFactory("persistenceUnitName");
em = emf.createEntityManager();
Finally, add the jpa provider jars to Tomcat, there are examples for that (I've never done it, but I'm sure some Tomcat expert could lend a hand)
The other option could also work, that is consume your webservice using a client deployed on another server
Good luck!
If your application uses advanced Java EE functionality (JTA, CDI), it won't work on Tomcat. If it uses JSTL, you will have to add a JSTL library to the tomcat installation. Read the docs, it should be stated somewhere, but I would not simply deploy the war to a tomcat.
If you just want to develop a relay webapp that consumes a webservice and displays the results, it will run on tomcat independantly of where the webservice runs.
After fighting passwords on Glassfish 4.x remotely on Ubuntu 14.04 Tahr, I'm ready to proceed to installing my first remote EJB module -- just want make sure I'm on the right path. Going from the Netbeans example Creating and Running an Application Client on the GlassFish Server, How would I make a client for the EJB module which is deployed remotely?
The Netbeans example assumes that Glassfish is running on the localhost. The exact mechanics are unclear to me, as it's not explicitly configured for localhost. Presumably it's implicitly configured for localhost...
I would like to use the ACC to connect to, not a local, but rather a remote Glassfish server. For context, the ACC is:
Introducing the Application Client Container
The Application Client Container (ACC) includes a set of Java classes,
libraries, and other files that are required for and distributed with
Java client programs that execute in their own Java Virtual Machine
(JVM). The ACC manages the execution of Java EE application client
components (application clients), which are used to access a variety
of Java EE services (such as JMS resources, EJB components, web
services, security, and so on.) from a JVM outside the Oracle
GlassFish Server. The ACC communicates with the GlassFish Server using
RMI-IIOP protocol and manages the details of RMI-IIOP communication
using the client ORB that is bundled with it. Compared to other Java
EE containers, the ACC is lightweight. For information about debugging
application clients, see Application Client Debugging.
GlassFish Server Open Source Edition Application Development Guide Release 4.0
see also:
https://stackoverflow.com/questions/25830149/how-to-package-a-stand-alone-remote-ejb-application-client
From a client application, how does the ACC remotely invoke the EJB module?
There must be a configuration. Does the ACC pick this up from jndi.properties? I can't find much documentation or examples on ACC usage. If the ACC is unsuitable, then, of course, I'll use a different approach. Presumably there's a way to specify a remote Glassfish server for the ACC.
How do you intend to deploy your application?
In my days when i use to develop application clients for the ACC, i used to bundle everything in an EAR (I will still do that, cause it is easier).
Glassfish deploys the artifacts, generates required configurations (You can override configurations in application.xml anyway).
One thing that the ACC takes care is the CORBA properties needed for remote connection.
When you download the client jar from the glassfish admin, you download a java webstart application, that downloads all required libraries as appropriate and a configuration is automatically set from which host (paramount that you set glassfish domain host properly, or this will be an internal IP or localhost) it was downloaded from.
I am currently writing a web application which uses JBoss6.x as the application server, for load sharing what I have decided is to write some EJB's which can be either run locally on the same machine as the web application on the Jboss or in a separate machine which will be remotely connected which will have Jboss running on it.
Now the question here is, I would be needing only 1 JBoss server to serve the web application, all other Jboss in question should be running with only the EJB Containers. Is it possible to run only the EJB Container and the naming services so that I can remotely connect to the same? Pointers or specific links as to how to go about doing this would be much appreciated.
I am currently developing an application for some researchers in my university.It's a small java program that you can use by command line. The next step is to package that program and deploy it to an application server. Some clients program will submit requests to the server who will call the tool that I wrote. Lately, we will add more tools to the server and he has to dispatch the requests to the right tool.
Which application server fits my needs ? I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Is it possible to use those servers in some context different from web context? Which package archive should i use (jar, war) ?
Any advice?
Some clients program will submit requests to the server who will call the tool that I wrote.
The big question is what server-side technology and what communication protocol can you use between the clients and the server. You basically have two major options: HTTP and web services (in that case, consider using either JAX-WS or JAX-RS) or RMI-IIOP and EJBs (in that case, you'll have to use a Java EE compliant server like GlassFish).
I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Not really. As I said, they can also be used for web services oriented applications. And GlassFish can be used for EJBs applications.
Which package archive should i use (jar, war)
The packaging will depend on the type of application you'll write, it's not something that you choose upfront, it's just a consequence. EJBs are packaged in an EJB JAR and typically deployed inside an EAR; Servlet based web services are deployed inside a WAR.
You really need to think about what technology to use first (with the current level of detail, I can't provide more guidance).
Do you even need an application server? There's nothing stopping you from adding the necessary network bindings and deploying it on its own.
Of the servers you mention, you've got 2 different categories: servlet containers and full-stack Java EE servers
Tomcat and Jetty are servlet containers. That doesn't mean that you can only do web stuff with them and you could manually add the required libraries to get a full Java EE server.
Glassfish is a full-stack Java EE server and can be compared with JBoss (both are open source) or the commercial rivals Weblogic and Websphere.
Sometimes this question is simple as the environment you are working in mandates a particular flavour of app server. You should check this first.
If you're not forced to use an app server, I'd ask why you think you need to use an app server?
I don't see why you would want to use tomcat, glassfish or jetty for a command line program.
If it's command-line based, and you want it to run server-side, you could write a little program that allows users to, for instance, telnet to your server, which in turn starts the CLI-application in question, and relays input / output to the client.
You may also want to look into Java Webstart, which makes deployment of new versions a breeze.
Actually we can't answer with so few elements.
- What are you planning to do
- With what technologies
- Where are you planning to host your application (have you got budget?)
- In which language are written the clients (even the future ones)?
- Could clients be on mobile phones (add some technlogy constraints...)
....
It would also be great to know what kind of request the clients will do, and what kind of response the server will provide...
Actually with what you tell us, all those application servers can do what you want...
I have looked for Tomcat, Jetty and
Glassfish but it seems that they are
only used for web application
You could even make a webapplication (servlet) and on the clientside use a httpclient to call that servlet... there are so many options :)
vive Paris!