I have an application written in pure/basic Java without GUI. I have three classes with main methods, so each of them can run for themselves. Now I run them with ant in specific order.
In glassfish I deployed Web application only with RESTful service.
What I want to do now is to transfer the three classes into glassfish, so I will call them in exact same order as before from RESTful service.
I watched series of videos on youtube on Java EE 6 APIs, but I didn't find anything that would help transfer pure Java application to glassfish. Should I use EJB API for this?
There is nothing special to do. Just package the three classes into the .war file with your web service. When the web service method is called, create an instance of each class and call the appropriate method.
Of course you could also create EJBs for each class and inject an instance of each class into the web service class.
I would image that in the simplest form you can create servlet for each class that you normally call on the command line. Then, indeed you can pack them into a war file and deploy into glassfish. You do not have to use glassfish, by the way. You can use tomcat, jetty or any other servlet containers.
I assume you want the applications to run without user interaction like a human being clicking on a page. Create a singleton ejb which will be created as soon as the application is uploaded to the webserver, in the singleton create instances of your classes and call a method which should replicate the behaviour of the main method in each class.
`#Startup
#Singleton
public class StartupBean {
private MyClass obj;
private MyClass2 obj2;
#PostConstruct
initializeMyClasses(){
obj = new MyClass();
obj.start();//the start method contains code copy pasted from main
obj2 = new MyClass2();
obj2.start();`
Related
I was trying to understand how the Web Services work and I came across this tutorial.
Now, I've seen Spring being used in enterprise applications and always wondered where the main method was and how everything worked? And whenever I would go to a Spring tutorial they'll start with beanFactory and Contexts and what not, all in a main Java method and from there just keep getting beans as required. This is totally different from what I see in the applications.
How exactly does Spring work in this case? What is the sequence of calls? I guess there will be some hidden main method somewhere, but I am not sure of that.
Normally if I were to run a simple Java project from command line, I'd do java mainClass. Now how would it happen in this case?
There is still a main method. It's just not written by the developer of the application, but by the developer of the container.
You can still see the main method being called by using the debugger like this:
Put a breakpoint in some initialization method, such as the init method of some servlet Servlet.init()
When the breakpoint hits, scroll down the call trace and the main method should be at the bottom.
This is an example with Jetty:
To see this we need to put the breakpoint in an initialization method so that we get the main thread of the application.
Putting the breakpoint in the processing of a request instead of an initialization method would show Thread.run() at the bottom of the stack trace and not main().
Thread.run() is the equivalent of the main method for threads other than the main thread.
So the main method still exists. It's just being handled at the level of the container.
Web applications don't have a main; the 'program' that is running is actually the web container (Apache Tomcat, Glassfish, JBoss, Weblogic, whatever) and that program will service the web application(s) you deploy into it. You might want to read the JEE tutorial to learn and understand what a Java web environment is.
https://docs.oracle.com/javaee/7/tutorial/
You don't see any explicit main method just because it is a Web project. This project is built into a web application archive (WAR) file which is deployed into a web server / servlet container, e.g., Tomcat in this tutorial.
Web applications do not have to contain main methods. This is because you don't need to explicitly start any Java process from within your web application. Somewhere in its depths, Tomcat calls a main method of the code it has been built from. This happens at server startup time.
Then, it will bind your code to incoming HTTP calls, but it will not start new processes for that. It will rather start new threads.
Web applications are not stand-alone applications. They run on some applications what we call a servletContainer in a Java context so there aren't any "main method or Java process (OS)" for any web application. They are just deployed on those containers that have a main method and Java process in OS runtime.
If you've created a basic program in Java then you must know that every Java program has a main() method, which is the starting point of the program. So, how come servlets don't have a main()? That is because servlets are served using Web containers.
A Web container will perform all the underlying work on behalf of the servlet so the programmer can focus on the business logic. When a client requests a servlet, the server hands requests to a Web container where the servlet is deployed.
Well, this is my development environment:
I am using Java 1.8 and Eclipse 4.5.1 (Mars), J2EE tools and plugins installed to work with WildFly 8 as Application Server
I created a Java EJB project, with a simple HelloWorld stateless session bean class. It implements 2 interfaces: #Remote and/or #Local, where I defined a String getHelloWorld() stub.
Now, I have my client for consuming the EJB: A Dynamic Web Project with one Servlet.
Inside the servlet, I can inject the ejb class using annotations, like this:
#EJB
private HelloWorldLocal bean;
or
#EJB
private HelloWorldRemote bean;
As you see, I declared the bean as HelloWorldLocal/HelloWorldRemote types. However, if I want to deploy and run my application,
I need to put the EJB and Web projects into an EAR first. That allows the Servlet to know and compile the HelloWorldLocal or HelloWorldRemote bean types, by simply adding the EJB project on
the Build Path as Project, or even by putting the EJB project as a Deployment Assembly directive.
I'd like to create a client outside the EAR (a remote Swing application or Remote WebSite). That means my client will
have not the chance to adding the EJB project interfaces as project references in the build path as I did with the EAR. Even if I want to call
the remote bean with JNDI, I need to cast the lookup() object to those types in order to use the bean methods.
The question is:
How can I get the HelloWorldRemote/HelloWorldLocal bean types from my remote client without EARs, if those interfaces are declared into an separate EJB Project?
(Of course, I dont want to create a .jar with the EJB project here).
And what about portable JNDI lookup? https://docs.oracle.com/cd/E19798-01/821-1841/girgn/index.html It should work if the EJB in the same JVM as your client.
I'm not sure I completely understand what you're asking, and I haven't done this in years, but the normal approach for this would to to create an EJB client JAR containing only the client's bean dependencies and remote interfaces. To best accomplish this, you'll want to use a tool such as Maven to build your project which contains an EJB plugin for this. If you're not using Maven, you're going to be limited by the tooling within Eclipse, though at one point it did contain EJB client generation support. The Wildfly documentation on EJB client setup might help also, but explicitly mentions that packaging the client is out of scope.
I'd like to share the only one solution that I found: I have to create a .jar file, with all the EJB interfaces (#Remote, #Local, and so on), and use it like referenced types on my remote clients.
This .jar would be outside any EAR. however, it needs jboss-client.jar because of the # annotations. So, I packaged all, interfaces and jboss-client.jar, exported them to a .jar and I added this new file in my EJB and clients projects as external jar! Now I am able to use the HelloWorld* types on EJB classes implementations and #EJB client variables.
If I want a remote Web client, I've placed the EJB project with a Web Project module, into a EAR - Definitely we need an EAR. The Web module has Servlets, and the servlets handles the #EJB variables and responses. So, Outside this EAR, I just need to use URL's to the servlets and, you got it: EJB method results are reached from remote web clients.
In desktop applications with JNDI, I just put the interfaces .jar like external jar into the client project. In that way, I can cast the .lookup() to HelloWorld* types and using its methods.
I hope it helps.
I was trying to understand how the Web Services work and I came across this tutorial.
Now, I've seen Spring being used in enterprise applications and always wondered where the main method was and how everything worked? And whenever I would go to a Spring tutorial they'll start with beanFactory and Contexts and what not, all in a main Java method and from there just keep getting beans as required. This is totally different from what I see in the applications.
How exactly does Spring work in this case? What is the sequence of calls? I guess there will be some hidden main method somewhere, but I am not sure of that.
Normally if I were to run a simple Java project from command line, I'd do java mainClass. Now how would it happen in this case?
There is still a main method. It's just not written by the developer of the application, but by the developer of the container.
You can still see the main method being called by using the debugger like this:
Put a breakpoint in some initialization method, such as the init method of some servlet Servlet.init()
When the breakpoint hits, scroll down the call trace and the main method should be at the bottom.
This is an example with Jetty:
To see this we need to put the breakpoint in an initialization method so that we get the main thread of the application.
Putting the breakpoint in the processing of a request instead of an initialization method would show Thread.run() at the bottom of the stack trace and not main().
Thread.run() is the equivalent of the main method for threads other than the main thread.
So the main method still exists. It's just being handled at the level of the container.
Web applications don't have a main; the 'program' that is running is actually the web container (Apache Tomcat, Glassfish, JBoss, Weblogic, whatever) and that program will service the web application(s) you deploy into it. You might want to read the JEE tutorial to learn and understand what a Java web environment is.
https://docs.oracle.com/javaee/7/tutorial/
You don't see any explicit main method just because it is a Web project. This project is built into a web application archive (WAR) file which is deployed into a web server / servlet container, e.g., Tomcat in this tutorial.
Web applications do not have to contain main methods. This is because you don't need to explicitly start any Java process from within your web application. Somewhere in its depths, Tomcat calls a main method of the code it has been built from. This happens at server startup time.
Then, it will bind your code to incoming HTTP calls, but it will not start new processes for that. It will rather start new threads.
Web applications are not stand-alone applications. They run on some applications what we call a servletContainer in a Java context so there aren't any "main method or Java process (OS)" for any web application. They are just deployed on those containers that have a main method and Java process in OS runtime.
If you've created a basic program in Java then you must know that every Java program has a main() method, which is the starting point of the program. So, how come servlets don't have a main()? That is because servlets are served using Web containers.
A Web container will perform all the underlying work on behalf of the servlet so the programmer can focus on the business logic. When a client requests a servlet, the server hands requests to a Web container where the servlet is deployed.
I'm trying to call a web service. I used wsimport to create stub classes based on the WSDL. I created a small console app to test them in Eclipse, and this apps works correctly. I then moved these classes into a CMS I'm using (Day CQ 5.3), modified the package name accordingly, and created a small JSP page to test them. When I attempt to view the page, I get an error that says "A WebService annotation is not present on class package.name.ProductsSoap".
However, 1) ProductsSoap is an interface, not a class. 2) ProductsSoap does indeed have a WebService annotation. 3) There were no generated classes that implement the ProductsSoap interface.
What would cause this?
Do you use spring framework to consume your web service? You should have spring-ws-core and spring-ws-core-tiger in your classpath.
I'm trying to expose a web service method via JAX-WS annotations. Many examples I've seen reference the EndPoint.publish() method to quickly stand up the service in a standalone app (ex from Java Web Services: Up and Running, 1st Edition):
public class TimeServerPublisher {
public static void main(String[ ] args) {
// 1st argument is the publication URL
// 2nd argument is an SIB instance
Endpoint.publish("http://127.0.0.1:9876/ts", new TimeServerImpl());
}
}
One thing that I'm missing is how to accomplish essentially the same thing but in an existing app. Would I make a servlet to handle this? What is the proper way to publish this service in an existing WAR file?
In a container you don't have to publish like this. The container will do the publish. If you plan to use it in JBoss server try JBossWS otherwise for Tomcat or any other server Axis2 may be the better choice.
Read more from the following links.
http://jbossws.jboss.org/mediawiki/index.php?title=JBossWS
http://ws.apache.org/axis2/
This depends on what WS stack you are using.
If you are using Java 6 then that includes the JAX-WS reference implementation, then you can consult the documentation about JAX-WS RI WAR contents.
As #Jerrish and #andri coments, there are different aproaches and solutions, depending on your concerns.
The idea behind is that you don't need to set the configuration (port, etc) when will be published your web service. The best approach could be to set this via configuration files (XML, properties, etc) or using #Annotations.
For example, if you're accustomed to use frameworks like Guice or Spring, you know that is possible/recommended to start the context of your application publishing or initializing some objects, factories, datasources, etc and publishing webservices is another task that can be done in this time, because will be available when you will start your application, isn't?.
By the way, I've good experiences with CXF and another solution could be Spring Web Services another powerful solution for creating web services.