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.
Related
I was able to create a JAVA Rest API Web Service using SpringBoot. How do I deploy it so not only my localhost can access it but other computers in the private LAN as well.
I dont want to officialy publish it outside. Is Glassfish the tool for this?
I want to have an endpoint like
https://privatewebservice.net/api/
in the private network that other people can use.
Thanks.
Deploy the rest on your tomcat server on port 80 and in other PCs in the private LANs update host file for privatewebservice.net to point to your PC's IP in the LAN
It needs to run an a servlet container(aka web server). There are many; Jetty, Tomcat, Glassfish etc. That servlet container will start and host your application and make it available via it's port(s).
You can run this process on any physical or virtual machine that is visible on your LAN. You could even use your own machine for this if it's visible to your LAN (barring firewall/network rules blocking the traffic).
To make it available to your LAN from your machine, find your machines internal LAN IP address (run ifconfig on Linux or ipconfig on Windows) and try accessing the app via that IP from your browser. If other machines on your LAN can see your machine, they should be able to access it too via that IP address (likely you will also have an internal DNS name for your machine which would be cleaner to use in case your IP address changes).
Obviously that's only good for development and testing. Generally for internal hosted applications for your company you would have a machine running somewhere that you could deploy the app to to make it accessible by others on your LAN.
It's worth noting that Spring Boot by default comes with an embedded server/servlet container. By default this is Tomcat, but can be changed to say Jetty, via configuration and changing default dependencies in your maven POM file or Gradle build file. The default will be fine unless you have some specific reason to change it.
To use this embedded server, use one of either Maven or Gradle Spring Boot plugins which will provide a set of tasks that can be used to build an executable Java jar file for the application that will run the application on the embedded server, and the application within it. This can then be run with something like java -jar myapp.jar
Technically speaking this would probably be the easiest way to deploy the application. With the only major requirement on the machine you are deploying to being a compatible version of Java. Although I'd recommend wrapping that app in a Docker image that already has Java on it and use Docker to run the docker image as a container. This means your applications' dependencies(including Java and it's specific version) are housed within the docker image/container and also means the machine that will run the app could host many different applications resource efficiently(RAM, CPU etc), with each managing their own dependencies. The machine hosting the app would then just need Docker installed on it, and doesn't get polluted with any other applications dependencies.
follow this step :
1- generate a war file of your Spring-boot project API - see here how to do
2- deploy it on tomcat server see here how to do
3- replace your localhost with your #adress ip (where the server is on and where the project is deployed)
JRebel has the possibility to deploy an application on a remote server.
To do this, according to the documentation, the JRebel agent should be put in the server boot.
Later tools like Eclipse provide the ability to connect to the remote server and deploy the application.
According to the documentation in the Eclipse plugin the URL of the remote server is simply indicated.
Doubts:
[Server level] Is possible to develop into a JRebel-enabled server, its own service, as a kind of customized end point receiver for deploy jrebel requests ... ? The idea would be to have a unique "JRebel_Deploy_Receiver_As_A_Service" url
[CLIENT level] Is possible to develop a custom client application, instead of being Eclipse o other marketplace tool.. In other words, to develop a client for deploy against a JRebel enabled server in the given endpoint?
There are no current plans for developing standalone utility to sync changes to remote JRebel server via the remote protocol used in IDEs. As for server-side, it's difficult to understand what would be the purpose. If all you want is to push files to server, there are plentiful of applications allowing you to do this, e.g. RSync.
I'm really new to Java and I have a basic question. I'm getting ready to deploy a Java web service that I have created in Netbeans/Glassfish. I used Netbeans because of the development GUI and tools. Of course I also deployed to Netbean's built in GF server because of easy and simplicity. I have a Windows 8 server with IIS that I now need to deploy this to. I was thinking that since Java 1.7 EE was already on my IIS server, than I wouldn't need a "container server" like GF but that doesn't appear to be the case. So, I'm confused. What's the difference between the server that Glassfish creates and the JVM that Java EE creates when it is installed? If I have to install Glassfish on my IIS server, am I going to have competing web services and port conflicts to resolve?
Thank you.
The Java Virtual Machine (JVM) is used to execute any Java program. However, all it does is execute the byte code in a Java binary, for example a Java archive (.jar) file. It does not include implementations of many of the Java EE libraries.
A web application, typically deployed as a web archive (.war) file, usually requires libraries not provided by the JVM. In addition, the standard Java web application architecture means that the entry point for the application is not in the .war file - it is in the web application server, which then calls into the code provided in the .war file.
The web application server, which includes full J2EE containers like Glassfish and also more limited web servers like Tomcat and Jetty, acts as an intermediate layer, running on a JVM and executing the web application provided in the .war file.
Probably the best way to run your application on an IIS server is to set up the IIS server as the front end - so the client facing ports would be under IIS control - and set up the web server as a back end to which IIS forwards the relevant requests. The answers at the following question provide some links that may be useful:
Deploy War File in Microsoft IIS 7
I Require a clarification on one Technical Implementation to check its feasible or not.
I have one VPS server which has a Java Environment and I have one more dedicated server which doesnot have a Java Environment where i have built my PHP based web application,
In the VPS environment I am planning to implement the XML based application using the Observer pattern with java and DOM Parsers and make that application available at say for example
123.124.125.65/XML_Works/Sample,xml file
Now My doubt is that: 1)is it possbile to access this application in dedicated Server where the java environment is not there.
2)if yes, then is it possible to access that java + XML application in IFrame in PHP based web portal.
1) No JVM = no java running on that machine
2) The most common solution I saw (and am using) is to externalize the java functionality you want as a web service or servlet and package it as a .war
Then use some web container such as tomcat to load that war and use a connector to connect calls to tomcat to your PHP server.
So the configuration I use is, Java as war, Tomcat as web container, Apache as PHP server and mod_jk connector for communication between servers.
Note that the mod_jk connector also supports other web servers.
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!