We Keep Coding

How to configure Glassfish 6 Server in Eclipse manually [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
Hello I'm creating java web application with eclipse and glassfish since 6 years ago. After this years was updating the IDE and Server wasn't the harmful like today. With Jakarta (namespace) , now I lose my IDE and Server. It's great move about Jakarta but I'm wondering why eclipse foundation and Jakarta (that supported by eclipse) not integrated and I can't start fresh new Eclipse(Last Version) and Glassfish 6 without getting error! If someone can do it please share with me , maybe I'm too new! All I want is Download the eclipse , download Glassfish 6 and start programming so if that have configuration, I don't understand about it, please share it with me.
Other my question about eclipse and Glassfish 6

I'm wondering why eclipse foundation and Jakarta (that supported by eclipse) not integrated and I can't start fresh new Eclipse(Last Version) and Glassfish 6 without getting error!
Well ... the short answer is because of Oracle's legal department, and their past history of legal aggression.
As the Wikipedia page for Jakarta EE states:
"Java EE was maintained by Oracle under the Java Community Process. On September 12, 2017, Oracle Corporation announced that it would submit Java EE to the Eclipse Foundation. The Eclipse top-level project has been named Eclipse Enterprise for Java (EE4J). The Eclipse Foundation was forced to change the name because Oracle owns the trademark for the name "Java" and renamed the Java EE platform to Jakarta EE."
Given Oracle's tendency to aggressively defend Java trademarks, copyrights and so on, the Jakarta EE specification committee decided that the wisest (and most future proof) course of action was to do a Big Bang rename of all of the packages in Jakarta EE from javax.* to jakarta.*.
Unfortunately, this has an impact on people transitioning from (legacy) Java EE to Jakarta EE 9 and later.
It has also resulted in a stack of extra work for the folks who maintain the Eclipse IDE. Work takes time, especially when some of the work is done by volunteers.
References
https://blog.hargrave.io/2019/05/jakarta-ee-and-package-renaming.html
https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html
All I want is download the Eclipse, download Glassfish 6 and start programming so if that have configuration, I don't understand about it, please share it with me.
On the Eclipse Foundation's Glassfish Downloads page there are resources on converting from Java EE to Jakarta EE. Including a video.

Is there a replacement library for CORBA in JDK 11 [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed last year.
Improve this question
JDK-11 will remove a lot of older parts of the JDK (JEP-320).
For some of them (e.g. JAXB) functionality will be provided as regular library. You simply add another dependency and everything works fine again.
But not so for CORBA, because
There is no significant interest in developing modern applications with CORBA in Java
I am however in the painful situation of needing to maintain older applications that still require CORBA while still wanting to update to JDK-11.
Is there a replacement-library out there or another good way of migrating to JDK-11 without removing the CORBA functionality of these applications?

You can definitely take a look at javaee/glassfish-corba. The documented home page reads -
The GlassFish ORB complies with the CORBA 2.3.1 specification, and
with the CORBA 3.0 specifications for the Interoperable Name Service
and Portable Interceptors. It includes both IDL and RMI-IIOP support.
The GlassFish ORB has an open, extensible architecture that supports
flexible configuration and extension through an open SPI.
Further what shall also interest developers, from the JEP itself -
The risks of removing the java.corba module are:
1. CORBA implementations will not compile or run if they include only a
subset of the "endorsed" CORBA APIs and expect the JDK to provide the
remainder.
2. Applications and CORBA implementations that use RMI-IIOP will not
compile or run. The RMI-IIOP packages (javax.rmi and javax.rmi.CORBA)
are located in the java.corba module and tied to the CORBA
implementation therein, so there will be no RMI-IIOP support in Java
SE once java.corba is removed.
3. Applications and CORBA implementations that use the javax.activity
package will not compile or run. This package is located in the
java.corba module and tied to the CORBA implementation therein, so
there will be no support in Java SE once java.corba is removed.
and further down there
The transition of stewardship of Java EE from the JCP to the Eclipse
Foundation includes the GlassFish implementation of CORBA and
RMI-IIOP.
additionally,
The "CORBA interop package" if required is implemented along with the artifact javax.transaction : javax.transaction-api.

this dependency could be used in JDK11
<dependency>
<groupId>org.glassfish.corba</groupId>
<artifactId>glassfish-corba-omgapi</artifactId>
<version>4.2.1</version>
</dependency>

I haven't moved to Java 11 yet but I always had problems with the Java CORBA implementation anyway as it was incomplete and didn't support all the Object methods defined in the standards, didn't support ssliop, etc. etc. I always replaced it by placing th JacORB OMG jar in the endorsed directory and setting the system property to pont to the JacORB orb:
-Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB
-Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton
BTW. I do not agree that ""There is no significant interest in developing modern applications with CORBA in Java" after all what is J2EE sitting on?

JDK 11 is fully supported by all of the ORB's supplied by Micro Focus.

Just what is Java EE really? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Java EE has this "mysterious shroud" around it for younger Java developers - one that I've been trying to lift myself for quite a while with little success.
Confusion arises from:
Java EE seems to be both a library and a platform - there are multiple ways to "get" the Java EE library, typically from something like Oracle's Java EE SDK download. However, the Java EE library will not work, nor compile unless if your code is being run on or has access to a Java EE application server (such as JBoss, GlassFish, Tomcat, etc). Why? Can't the libraries function outside of the application server environment? Why do I need something massive as JBoss just to compile simple code to send an email?
Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?
Why are there so many Java EE offerings when there is really only two main flavors of standard Java (Oracle JVM/SDK | OpenJDK JVM/JDK)?
What can one do with Java EE that they cannot do with standard Java?
What can one do with standard Java that they cannot do with Java EE?
When does a developer decide they "need" Java EE?
When does a developer decide they do not need Java EE?
Why is Java EE library version not in sync with standard Java library releases (Java EE 6 vs. Java 7)?
Thanks for helping me clear the flog!

Why can't the libraries function outside of the application server environment?
Actually they can. Most of the libraries can be directly used standalone (in Java SE) or included in a .war (practically that's nearly always Tomcat). Some parts of Java EE, like JPA, have explicit sections in their respective specifications that tells how they should work and be used in Java SE.
If anything, it's not so much an application server environment per se that's at stake here, but the presence of all other libraries and the integration code that unites them.
Because of that, annotations will be scanned only once for all your classes instead of every library (EJB, JPA, etc) doing this scanning over and over itself. Also because of that, CDI annotations can be applied to EJB beans and JPA entity managers can be injected into them.
Why do I need something massive as JBoss just to compile simple code to send an email?
There are a few things wrong with this question:
For compiling you only need the API jar, which is below 1MB for the Web Profile, and a little over 1MB for the full profile.
For running you obviously need an implementation, but "massive" is overstating things. The OpenJDK for example is around 75MB and TomEE (a Web Profile implementation containing mail support) is only 25MB. Even GlassFish (a Full Profile implementation) is only 53MB.
Mail works perfectly fine from Java SE (and thus Tomcat) as well using the standalone mail.jar and activation.jar.
Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?
Java EE in a way was one of the first attempts to split up the already massive JDK into chunks that are easier to manage and download. People are already complaining that the graphical classes (AWT, Swing) and Applets are inside the JRE when all they do is run some commands on a headless server. And then you also want to include all the Java EE libraries in the standard JDK?
With the eventual release of modularity support we'll just have a small base JRE with many things separately installable as packages. Perhaps one day many or even all classes that now make up Java EE will be such package as well. Time will tell.
Why are there so many Java EE offerings when there is really only two main flavors of standard Java (Oracle JVM/SDK | OpenJDK JVM/JDK)?
There are more than just two flavors of Java SE. There is at least the IBM JDK, the previous BEA one (JRocket, which is being merged into the Oracle/Sun one because of the acquisition), various other open source implementations and a slew of implementations for embedded use.
The reason behind Java SE and EE being a specification is that many vendors and organizations can implement it and thus it encourages competition and mitigates the risk of vendor lock-in.
It's really no different with C and C++ compilers, where you have many competing offerings as well all adhering to the C++ standard.
Why is Java EE library version not in sync with standard Java library releases (Java EE 6 vs. Java 7)
Java EE builds on Java SE, so it trails behind. The versions do correspond though. Java EE 5 requires Java SE 5. Java EE 6 requires Java SE 6 and so on. It's just that mostly when Java SE X is current, Java EE X-1 is current.

Here are a few quickly composed answers to your questions...
Why can't JavaEE libraries function without an application server?
The services provided by JavaEE (container managed transactions, container managed dependency injection, timer service, etc..) inherently involve JavaEE compliant Application Servers (for example: GlassFish, JBoss, WebSphere, etc...). Therefore the JavaEE libraries serve no purpose without such a container. "Why do I need something as massive as JBoss just to compile simple code to send an email?" You don't. There are ways to send an email without JavaEE... But if you want to do it the JavaEE way, you need a JavaEE container.
Why are JavaEE libraries not included with JavaSE download?
The same reason that many libraries aren't included: it would be overkill. Since you can't even use the JavaEE libraries without an application server, why bother to include them? JavaEE should be downloaded if and when a developer installs an application server and decides to use JavaEE.
Why are there so many JavaEE offerings?
Are there really "so many" JavaEE offerings? If so, please list some of them. More accurately I believe there are multiple implementations of the same APIs.
What can one do with JavaEE that they can't do without standard Java?
Lots. You can't rely on an application server to manage transactions or persistence contexts without JavaEE. You can't allow an application server to manage EJB dependency injection without JavaEE. You can't use an application managed timer service without JavaEE. The answer to this question should make the answer to the first question quite clear... Most of the services provided by JavaEE require a JavaEE container.
What can you do with JavaSE that you can't do with JavaEE?
Um... I don't know.
When does a developer decide they need JavaEE?
This question is completely subjective... But if you need any of the services provided by JavaEE, you start to think about it. If you don't know what JavaEE is... you probably don't need it.
When does a developer decide they do not need JavaEE?
See previous answer.
Why is JavaEE library version not in sync with JavaSE version?
Good question. I won't pretend to know how to answer it... But I would guess the answer is: "because they're not in sync".

At bird's eye view, Java EE is a platform, i.e. something that we can build on.
Taking a more technical perspective, the Java Enterprise Edition standard defines a set of APIs commonly used for building enterprise applications. These APIs are implemented by application servers - and yes, different application servers are at liberty to use different implementations of the Java EE APIs.
However, the java ee library will not work, nor compile unless if your code is being run on or has access to a Java EE application server (such as JBoss, GlassFish, Tomcat, etc).
You compile against the Java EE APIs, so you only need those APIs at compile time. At runtime, you'll also need an implementation of these APIs, i.e. an application server.
Why do I need something massive as JBoss just to compile simple code to send an email?
You don't. However, if you wish to use the Java EE API for sending mail, you will need an implementation of that API at runtime. This can be provided by an application server, or by provided by a stand alone library you add to your classpath.
Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?
Because only the APIs are standardized, not the implementations.
Why are there so many Java EE offerings
Because people disagree on the right way to implement certain features. Because different vendors compete for market share.
What can one do with Java EE that they cannot do with standard Java?
Since Java EE implementations are built with "standard Java": Nothing. However, leveraging the existing libraries can save a great deal of effort if you are solving typical enterprise problems, and using a standardized API can prevent vendor lock-in.
What can one do with standard Java that they cannot do with Java EE?
Nothing, since Java EE includes Java SE.
When does a developer decide they "need" Java EE? When does a developer decide they do not need Java EE?
Generally speaking, the Java EE APIs solve typical, recurring problems in enterprise computing. If you have such problems, it usually makes sense to use the standard solutions - but if you have different problems, different solutions may be called for. For instance, if you need to talk to a relational database, you should consider using JPA. But if you don't need a relational database, JPA won't help you.

What is Java EE?
Let's start from canonicity definition at wiki:
Java Platform, Enterprise Edition or Java EE is Oracle's enterprise
Java computing platform. The platform provides an API and runtime
environment for developing and running enterprise software, including
network and web services, and other large-scale, multi-tiered,
scalable, reliable, and secure network applications.
The main point here is that Java EE is a platform provides an API, not some concrete library.
What for Java EE needed?
The main scope of Java EE is the network based applications, unlike Java SE oriented to the desktop applications development with simple network support. This is the main diference between them.
Scalability, messaging, transactioning, DB support for every application... the need in all of this has increased with the evolution of the network.
Of course a lot of ready solutions which Java SE provides are useful for network development, so Java EE extends Java SE.
Why do we need application servers to run our code?
Why do we need operation systems? Because there are a lot of painful work with hardware we need to do to make even simpliest application. And without OS you need to do it again and again. Oversimplified OS is just a programmatic container, which provides us a global context to run our applications.
And this is what the application servers are. They are allows us to run our applications in their context and provides us a lot of highlevel functionality which is needed for enterprise highloaded network applications. And we are don't want to write our own bicycles to solve this problems, we are want to write code which will satisfy our business needs.
Another example here could be JVM for Java.
Why Java EE doesn't contains onboard app server?
Hard to say for me. I think, it was done for more flexibility. Java EE says what they should do, they decide how to do it.
Why JVM doesn't include Java EE?
Because they directed to different market sectors. Java EE has a bunch of functionality which is doesn't need for usual desktops.
Why are there so many Java EE offerings?
Because Java EE only describes the behaviour. Everybody can implement it.
What can one do with Java EE that they cannot do with Java SE?
To conquer the internet. It's really hard to do with Java SE applets and sockets :)
What can one do with Java SE that they cannot do with Java EE?
As mentioned above Java EE extends Java SE, so with Java EE you should be able to do everything what is available for Java SE.
When does a developer decide they "need" Java EE?
When they need the power of Java EE. All what is mentioned above.
When does a developer decide they do not need Java EE?
When they write a usual console or desktop application.
Why versions of Java SE and Java EE are unsynced?
Java always had troubles with it's technologies naming and versioning. So this situation is not an exception.

Java EE is all about container concept. Container is an execution context within which will run your application and which provide this last a set of services. Each kind of service is defined by a specification named JSR. For example JSR 907, JTA (java transaction Api) which provide a standard way to manage distributed transaction against different resources. There are generally many different implementations for a given JSR, the implementation you will use depends on the container provider, but you don't really mind about that as you are sure the behavior respect the predefined contract : the JSR API. So to take advantage of Java EE, you need to run your application inside a container. The two main ones are EJB and servlet container which are both present on any Java EE certified application server.
The aim of all of this is to defined a standard execution environment to allow to package your application with only the essentials, id.est. your business. It avoids to depend on a unknown and various set of third-party libraries that you would have to package and provide with your app otherwise, and which may be sources of conflict with other apps on the server. In Java EE you know that all standard non functional requirements like security, transaction, scalability, remote invocation, and many more will be provided by the container (factorized for all apps running inside it) and you just have to base your work on its.

What features does EJB3 bring and also how does EJB3 stack up with the Spring Framework? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I have never worked on ejb, when I started programming Spring was already arrived and all my projects have been with Spring only, recently I had one interview and they wanted knowledge of EJB3.0 and so I want to know how does EJB3.0 stack up with Spring Framework and why many projects nowadays are with Spring Framework and not with EJB3.0, do not quote me here as I can be wrong
I would really appreciate if difference and benefits of using one over another could be explained from practical perspective.
Note Please do not give wiki links as answer as I want to understand actually how both this technology stack up.
Update Also what would be best way to start learning for EJB3, what are the recommended Books, Online Tutorial for the same ?

EJB is a quite old technology (ca. 1999). However, until Version 3 of the standard, it was horribly inconvenient to use. Spring became popular as a sane alternative that offered some of the same core features (declarative transactions and security) as well as some new ones (dependency injection, AOP). It also integrated well with many other technologies such as Hibernate.
However, starting with V3.0, EJBs (or rather, the whole Java EE platform of which EJBs are a part) got a major overhaul and became much easier to use. Additionally, a lot of features made popular by various frameworks (including Spring) were made into official standards and added to Java EE.
Right now, the Java EE platform is gaining a lot of ground vs. Spring in terms of popularity, since they're about even in ease of use and features, and Java EE has the advantage of being based on open standards with multiple implementations for most component. At the same time, it seems to me Spring is having problems keeping up with the state of the art when it comes to integrating with other frameworks (which used to be its strength).

I would say the only major difference is Java EE 5 and 6 are a standard. It's taken the ideas of Spring and others and created a standard out of them. Compared to the old EJBs, EJB3 is night and day. All your EJBs are POJOs and dependencies are injected by the container. Gone are all those different interfaces and creating instances manually from the home interface. It will take you maybe couple hours at most to learn if you've already done a lot with Spring. You'll also want to look at JSF if you're doing web applications.
I never did a real application with the old EJBs because it was such a pain. EJB3 I use all the time as it's effortless. If you want to try the newest everything, get a copy of glassfish which I think is still the only Java EE 6 certified server.

In terms of both dependency injection and MVC architectures, Spring had the edge over Java EE 5 in terms of flexibility and ease of use, although as others have said, Java EE 5 (EJB3) was a huge improvement over previous versions of Java EE/EJB. With Java EE 6 I believe Java EE has leapt ahead of Spring in both DI w/ the new CDI (JSR-299) implementation, and in MVC w/ JSF 2.0.
The Oracle online tutorials are rudimentary, but a good starting point for learning Java EE. An excellent resource for learning about DI in Java EE 6 is Reza Rahman's series of articles http://www.theserverside.com/news/1373391/Dependency-Injection-in-Java-EE-6-Part-1

Which is the best Open source application server? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
We are looking for a open source J2EE Application server for log budget deployments. We are considering JBoss and Glassfish. Which is the best open source application server? Any comparative study available?

JBoss has been used in production environment for over 6 years now.
Glassfish's codebase is over 10 years BUT most of the code is recent. Glassfish v3 (still in beta) has a microkernel (so is Jboss 5) architecture.
Glassfish has command line tools and a nice console. Since Glassfish is from sun, usually it will work well with the latest version of JDK/J2EE -- currently JDK 6/J2EE 5.
Glassfish should work well in windows, solaris and linux. Jboss(from redhat) should work just fine on linux, windows for sure.
community : a much much bigger community around Jboss. Glassfish still forming its community. Books and other 3rd party products are available for JBoss but not for Glassfish.
If something is mission critical and you need to get it up and running right now, you will NOT go wrong going with JBoss. However, if you have some time, in the long run Glassfish will NOT hurt you. Especially, if you're targeting Solaris.

After using JBoss from the very beginning and then switching to Glassfish in the last 6 months, I can honestly say that Glassfish is fast, reliable and full-featured. I would never consider going back. Im not talking "PetStore" here, my experience with these servers is in the high-transaction online stock-trading arena.

I'm sure the answer depends on your specific needs. You won't go wrong with either Glassfish or Jboss. I tend to prefer Glassfish because of the nice admin console. My advice to you is that you draw you requirements and test both app servers. Most benchmarks I find on the net tend to be a little biased.

A comparison table between JBoss, Geronimo and Tomcat for latter 2007.
This article has many interesting points to aid your decision and is worth reading:
Geronimo 2 is the clear choice if your
Java application needs are
particularly extensive or if you just
want to leverage total Java EE 5
compliance. Although JBoss 4.2 is not
completely compatible with Sun's Java
EE 5 standard, the JBoss 4.2 team is
responsible for many of the
cutting-edge technologies used by all
of the servers and added to the
standard Java EE 5 capabilities.
Tomcat 6 by itself is a lightweight
solution. It does not come with all
the Java EE features and additional
packages found in JBoss and Geronimo,
but also doesn't require much memory
and runs fast even on smaller servers.
In conclusion the author says:
Bottom line: JBoss, Geronimo, and
Tomcat are reliable, fast, and
definitely able to handle the traffic
on large-scale enterprise
applications. Furthermore, many of the
high-demand Java server technologies
presented in the features comparison
originate from the open source world,
not the commercial one.

I would consider any bells and whistles you might be interested in. JBoss has a lot of nice integration points with frameworks, such as Hibernate, but has a history of not playing well with Spring. Both very useful frameworks, both code change your decision on how you might proceed.

Websphere CE is also worth looking at, but over all my vote would be for glassfish. The v3 version is looking very promising.
Karl

I've had great experiences with JBoss 4.x, but unfortunately they seem to have gone off the tracks with their Java EE 5 implementation effort. The fact that JBoss 5 is so late getting to market is extremely disappointing.
The most impressive to me right now is Glassfish. It has a great pace of development, and appears poised to dominate once Java EE 6 hits the wire.