We're experiencing a bug in Glassfish 3.1.2.2 (specifically, in the WSEndpointImpl class in Metro module) which is fixed but due in Glassfish 4.0 or some next release in the 3.1 branch hopefully. As this fix is critical for our application, we would like to patch this class alone and install it somehow to Glassfish, before waiting for the next release. Is this possible? What do you recommend?
Glassfish supports swapping in other versions of certain modules via the Endorsed Standards Override Mechanism and according to the Oracle documentation JAX-WS is among the replaceable components.
You just have to copy the updated version into the /lib/endorsed directory of your domain, but I'm pretty sure you can also put your file in the /lib/endorsed directory of the Glassfish server itself.
See a practical example in this blog entry
Related
Java 8 and prior versions have Java Web Start, which auto-updates the application when we change it. Oracle has recommended that users migrate to jlink, as that is the new Oracle technology. So far, this sounds good. This comes with a host of benefits:
Native code on Windows, Mac and Linux
Modularization of the code (although Proguard does this as well)
The use of new, supported technology.
The problem: I can't find the canonical Java solution to auto-update with jlink.
One would think that Java Web Start could continue to be used, especially if one casually reads this document. Notice the fact that Java Web Start continues to be prominently listed. But there's a fly in the ointment: Oracle is deprecating Java Web Start. It's slated for removal in JDK 11. So, what's the official path forward. Failing that, is there a standard way that people proceed?
For the purposes of this question the following are out of scope:
Paying huge amounts of money yearly to someone with an feature-packed enterprise solution. The application to be distributed is already packaged into a single jar that is smaller than 50MB.
Forcing users to run an InstallShield style app to reinstall the new version, and then manually uninstall the old version every time an update is pushed. That's sooo 1990's.
Porting the entire app to be a webapp, rewriting the UI and client side logic to fit in a browser and dealing with all the incompatibilities that entails. The authors of the application worked on GWT and know exactly what web browsers are capable of. Unfortunately, they also know the level of effort required.
Allowing users to continue to run old versions of the application. That, too, is sooo 1980's. Modern apps update quickly, and supporting every version of the application ever released is not tenable. That's what my father's COBOL application had to deal with, and he didn't enjoy it. I'm hoping technology has progressed.
Continuing to use Java Web Start. Until/unless Oracle changes its mind, Java Web Start is a doomed technology.
In May 2019 commented to watch the OpenWebStart project.
Now (October 2019) it is time to give OpenWebStart serious consideration. While not yet feature complete, a alpha beta release of OpenWebStart is now available for download under a "GPL with Classpath exception" license.
The OpenWebStart Technical Details page states:
OpenWebStart is based on Iced-Tea-Web and the JNLP-specification defined in JSR-56. It will implement the most commonly used features of Java Web Start and it will be able to handle any typical JWS-based application. We plan to support all future versions of Java, starting with Java 11. In addition to Java 11, the first release of OpenWebStart will also support Java 8.
The page goes on to state that OpenWebStart will support interactive installers with auto-update, and non-interactive installers. Some JNLP features will be supported, and it will include a replacement for the Java Control Panel. A more comprehensive list of planned features1 and their implementation status is provided in the feature table.
1 - If you have a requirement that is not on their feature list (e.g. jlink support), you could contact the OpenWebStart team, and offer a suitable incentive (e.g. money to pay developers) to implement the feature for you. They also offer commercial versions of the software for paying customers.
Disclaimer: I have no connection with the OpenWebStart project, the company (Karakun) or the project sponsors. This is not a recommendation.
I had a similar problem in a past project. We needed to migrate from Webstart to another technology.
The first approach was to install IcedTea. It is directly bundled with the AdoptOpenJDK Project.
But as far as I understood the problem, Java wasn't meant to be installed on the Client side like this anymore and we didn't want problems with all of our customers.
Our solution was then building an own specific Executable, which connects to the server, ask for enviroment settings from the server side, and then download and extracts the JLink Java. So we could use the old technologies and just wrapped it in an Executable.
Last thing done then was redirecting to the download location of the Executable when calling the jnlp-URL.
Do you use maven?
I've resolved my similar problem with maven (I need to update an EAR).
My main app (the ear package) has a pom.xml with listed the dependencies and repositories.
The dependencies have the <version> tag with a range (documentation) as in this example
<version>[1.0.0,)</version>
That means : get version 1.0.0 or newer of the dependency. (You can put also an upper bound to the version, [1.0.0, 2.0.0) so if you develope a new version, it is not used in old app)
In the repository section I added my personal repository.
Now, in the remote machine I need only to rebuild my ear package with maven : the compiler download the newer version of my jar and put it together.
You need a system to check if there are newer dependencies version and warn the user to update the app and also lock its work (you can't work if you don't update). Maybe you need a little app to make users do the rebuild process easily. It's 1990's but a lot of desktop-app works in this way
PRO
This schema can be used in a lot of different projects.
CONTRO
You need to build the app in the remote machine, so the client must have a JDK and access to your repository (like artifactory);
You must write code in different jars and add them like dependencies in the main archive.
You must change JAR version each time and publish on the repository (this could be a good practice)
I am new to Icemobile, but since it promises fast development on mobile devices I gave it a shot. I use Netbeans for development, Netbeans 7.1 on one PC and Netbeans 7.3 on another.
The problem is that with Netbeans 7.1, a managed bean is not called on post back. It is constructed and getters are called on the initial GET page. On Netbeans 7.3 this is OK.
I later found that in Netbeans 7.1, the JSF library is JSF 2.1 with jsf-api.jar and jsf-impl.jar , whereas in Netbeans 7.3, it is JSF 2.2 javax.faces.jar. I substituted this jar in the Netbeans 7.1 machine and problem solved.
I think icesoft.org should state this caveat in http://www.icesoft.org/java/projects/ICEmobile/supported-platforms.jsf. Here it only says JSF 2 Mojarra.
Also although the web site states Tomcat 7 is required, I found Tomcat 6 is OK so far (although some functionalities may not be supported on Tomcat 6)
I don't believe that we've done any specific testing with ICEmobile with Mojarra 2.2. I would recommend sticking with Mojarra 2.1 for now. Despite the version the NetBeans version is defaulting to, you can override that just by including the javax.faces.jar in the WEB-INF/lib folder so that it's always included in the war file. As for Tomcat, I don't believe that we say that Tomcat 7 is required. We actually support a very wide range of application servers. Check out our supported platforms page (http://www.icesoft.org/java/projects/ICEmobile/supported-platforms.jsf).
The issue you were having with managed beans not being called sounds strange, and I would guess that it's more likely due to JSF configuration than ICEmobile. We'd be happy to take a look at your app and configuration.
Thanks,
Philip
In addition to posting your app, which version of the ICEfaces Netbeans plugin are you using? http://www.icesoft.org/java/downloads/icefaces-downloads.jsf.
What are the exact version numbers of the Mojarra jars you've been using for both 2.1 and 2.2?
Hi I have a project in which the coding is on java and this code is using swing, ejb and ibm's websphere coz it was coded in 2001 by someone , so i have to convert it for using it on glassfish 2.0 . The problem is that in this code using the api of ibm's websphere is used like
com.ibm.ejs.util.Uuid;
com.ibm.ivj.ejb.runtime.AbstractAccessBean;
com.ibm.ivj.ejb.runtime.AbstractSessionAccessBean;
com.ibm.etools.ejb.client.runtime.AbstractEJBFactory;
com.ibm.ejs.container.EJSWrapper;
com.ibm.ejs.container.*;
com.ibm.ejs.persistence.EJSJDBCPersister;
com.ibm.websphere.cpi.PersisterHome
com.ibm.ejs.container.*;
com.ibm.ejs.container.*;
com.ibm.ivj.ejb.associations.interfaces.Link;
com.ibm.ivj.ejb.runtime.AbstractAccessBean;
com.ibm.ivj.ejb.runtime.AbstractSessionAccessBean;
com.ibm.xml.parsers.SAXParser;
COM.ibm.db2.jdbc.DB2BaseDataSource;
COM.ibm.db2.jdbc.DB2DataSource;
I don't want to use websphere and also not found any jar file to import that classes on glassfish so please suggest me how to convert it.
The classes you mention are generated by WSAD (WebSphere Application Developer, which is ancestor of RAD) during 'generate deployment and rmic code' phase of build process. You can also tell this from the class names, which probably have funny prefixes and suffixes attached original bean name and reside in the same package. So, developer did not write these classes himself, they are generated for WebSphere, and they shall be omitted (cleaned up from project) before migrating to an application server from another vendor. On how to get rid of these classes you may find instructions at tech note below.
EJBDeploy generation and deletion of stubs, ties and generated deploy code
I would say that you have a pair of problems here, because most probably Enterprise Java spec that was used is not currently supported by new servers (it is probably 1.2 as it is very old). So you must first perform a specification level migration, then application server migration.
For specification level migration (i.e. Java EE 1.2 to 1.4 at least) I would say your best bet would be to use RAD (Rational Application Developer), which can perform specification migration by using simple wizards. You may find information about how to perform this migration at article below.
Migrating the specification level of J2EE projects
Once you upgrade spec level it will be easier to migrate your project to another server because as the spec level increases, effort for server to server migration decreases. At this point what you shall do basically is prepare application server specific deployment descriptors for your target server (Glassfish), for which you shall check glassfish website. A good entry point would be Glassfish migration wiki, and Glassfish verification tool (I can't put links to these because I don't enough reputation to post more than two link at the moment :)
I don't know of any "simple" way to convert such projects. You will end up having to manually change all relevant parts to the updated spec. I assume you are not really willing to upgrade to GF 2.0? You should at least move to 2.1. I highly recommend to move to 3.1.
Please assume that I do not need to worry about development time and costs: I am interested in general technical benefits (improved performance? improved APIs?) and new features.
I am currently working on products using 4.2.x, and we consider a major shift for versions that are a long time ahead and need to converge.
I had a brief look at the release notes of each version and some articles about each release for 5.x, 6.x, 7.x and 8.x. But I would be glad to have first-hand feedback from people who have made the switch.
I noticed there are some important changes surrounding messaging (switching from JBoss MQ to JBoss Messenging), and that for JBoss 7.x it seems to change a fair bit its configuration layer. Then there's a lot more going on when switching to JBoss/WildFly 8.x.
Please recommend good articles pointing at pitfalls if you can. I found a few for migrations to JBoss 5.x, but not that many for 6.x or even 7.x, and someone else is evaluating 8.x for us now. Feel free to recommend alternatives as well if you think they are relevant, though I'd prefer to focus only on JBoss.
For information, we use a mix of JPF- and OSGi-enabled (using Eclipse Equinox) plugin-based systems, with clients developed in Swing (some deployed via WebStart).
Update: Though this question brought some great answers already, I think it deserves an update for WildFly (and actually, our internal projects delayed making the switch from 4.2.x to 7.x as originally planned to wait for WildFly). New thoughts and answers are welcome.
I've upgraded from JBoss 4 to 5 and from experience the following are the most important to note:
JBoss 5 (and 6 and 7) are not as forgiving as JBoss 4 with XML files. You must make sure that all your deployment descriptor XML files are valid. You may be using DTDs in some files - I recommend upgrading these to use XML schema instead.
Some libraries may cause incompatibilities. This can be particularly true if you access web services and/or do XML parsing
If you precompile your JSPs in JBoss 4, you probably won't be able to in JBoss 6/7.
JBoss 4 and 5 use different message queue implementations. If you have any message queues or topics defined you will need to redefine them.
JBoss TreeCache is no longer used. If you use this for caching purposes, you will need to change to use the new JBoss cache instead.
JBoss 5 security is different. If your remote clients require secured access to JBoss, you will need to configure them differently.
Some useful resources are:
https://dzone.com/articles/migrating-jboss-4-jboss-5
http://venugopaal.wordpress.com/2009/02/02/jboss405-to-jboss-5ga
Officially JBoss 6 is only certified for the Java EE Web Profile, so if you use "legacy" features such as EJB 2.x, they will potentially not be supported in the future. Depending on the lifecycle of your application, this may or may not be a problem. JBoss 6 currently supports EJB2.1 fully, but it is not certified against this.
I have also found that JBoss 5 handles memory a lot better that JBoss 4. With JBoss 4 I see a lot more PermGen errors than I do with JBoss 5.
I can only speak from production experience with JBoss 5.1.0 and some investigation of version 6.
JBoss 5 is Java EE 5 and JBoss 6 and 7 are Java EE 6. The disparity in API features is best documented in those specs. JBoss 6 is likely to have a very short shelf-life; it is only certified for the Java EE 6 web profile and bugfixes are being targeted at version 7 (in its 3rd beta at time of writing).
I think you'd get better answers on the JBoss community forum.
We upgraded from JBoss AS 5 to JBoss AS 7 and are eying towards WildFly AS 8.1. Right now we can't migrate to 8 because there is no MQ Series JMS 2 RAR.
Some of the differences:
The configuration is so much better and simpler. It's no longer spread over 20 XML files in which you configure aspects in XML files. Instead everything is one central place. All ports are configured in one central place, there is no longer an XSL file that transforms server.xml. You can make sense of the configuration file without knowing the implementation details of classes. It's hard to appreciate this if you've never configured a JBoss 5.x.
The class loading model looks sane and you get a lot of control through jboss-deployment-structure.xml
The centralized logging (Slf4j, JUL, JCL, Log4j, …) is really nice.
The EJB client library looks much more cleaned up. It's down to 10 JARs from 20, half of them are even OSGi bundles (our client is an Eclipse RCP application).
The EJB client maven dependency mess is gone, instead you now get a BOM POM.
You get a BOM POM for the server APIs.
Faster start up and less memory usage. We deploy 80 EJBs and the MQ Series RAR in 6 seconds without much tuning. Our live dataset is somewhere above 200 MB.
The deployments folder is empty by default
The (lack of) quality of XNIO is scary. In 7.x it's only used for EJB remoting and we hit several show stopper bugs (deadlocks, double free, socket handle leaks, …). In 8.x it is used for servlets as well instead of Tomcat. There are still a lot of very basic servlet bugs being fixed in undertow.
Changes that we had to do our application:
change JNDI names to EE 6 standardized names
migrate from JBoss Cache to Infinispan (part of our code has been migrated to the flat API, some parts still use the tree API)
security is slightly less flexible (you can no longer fix authenticated and unauthenticated calls)
some horrible code that relied on details of remote JNDI
the configuration of the EJB client is different
all of you scripts for installing, deploying, starting, stopping, …
ExternalContext is gone, we had to replace it with a different approach
we replaced MBeans in SARs with #StartUp EJBs
some ugly hacks for Cocoon
The AS 7.x series has a lot of bugs with fixes only available in the EAP series. If you want go to with 7.x instead of 8.x we strongly recommend you buy EAP 6.
Here is an interesting thread on JBoss AS 7 compromises and future, also mentioning issues with AS 5 and AS 6:
http://community.jboss.org/message/613171
Just wanted to bring this to anyone's attention who might be facing PermGen bloat issue after upgrading to the latest. The JBoss-6 Microcontainer tries to scan for Jboss specific annotations by loading the classes from all the JARs in the class-path on startup. This causes the PermGen bloating as it starts to load all the unwanted classes. To reduce the amount of scanning, the Microcontainer provides another descriptor hook, by means of jboss-scanning.xml.
Add this 'jboss-scanning.xml' to the WEB-INF inside WARs and ass 'jboss-scanning.xml' to the META-INF inside EARs.
<scanning xmlns="urn:jboss:scanning:1.0">
<!-- Purpose: Disable scanning for annotations in contained deployment. -->
</scanning>
I am very interested in the Web Services Connector for Java Management Extensions (JMX) Agents and the reference implementation ws-jmx-connector. JSR 262 will provide a new opportunity for cross-platform/cross-language enterprise integration projects, given the option to communicate with JMX Agents using non-Java clients. (I have been able to use the reference implementation with a Delphi client with little effort).
Are there any (open source) Java tools or products which are JSR 262 'enabled' and expose MBeans over JMX WS - so that the JSR 262 reference implementation can be used, without the need to modify their source code?
I am quite interested in it as well but I haven't had time to work with it. However, as it is just another protocol implementation you should be able to use it with the standard tools (like jconsole). Just make sure it is in the classpath and specify a valid service url, probably something like "service:jmx:ws://localhost:8080/test", when connecting.
If you look here http://java.sun.com/javase/6/docs/technotes/guides/management/jconsole.html there is an example on how to extend the classpath when starting jconsole. I've used that technique for a few other protocols and it usually just works.
In order to give you a good example I downloaded the the JSR-262-ri.jar, ran the installation and added the jar-files in the lib directory to my classpath but all I got was:
SEVERE: The JAX-WS 2.1 RI is not Sun's unbundled RI.
JAX-WS jars must be located in your classpath when running on JDK 5 and JDK 6 update release 4 (or higher).
If running on a previous JDK 6 (JDK 6 to JDK 6 update 3 included) you need to use the endorsed directory .
NB: The JAX-WS 2.1 release bundled in JDK 6 cannot be used to run this Connector. The unbundled release of JAX-WS 2.1 is required.
This wrong release is loaded from : the bootclasspath.
so I guess I had some conflict that I really cannot motivate myself to spend time on right now... If anyone knows, feel free to comment. I would love to get it working on my server side to play around.
I hope this is at least a better answer than having the question unanswered.
Edit: Or did you mean open source java tools that uses it to expose MBeans so that you can use them from delphi (or whatever)? In that case I will gladly open source a simple tool if I can just get rid of that error above :-)