Where can I download the JBoss AS7 Documentation?
I tried to find a link to download the JBoss Documentation everywhere (including http://www.jboss.org/), but failed.
You can use the Export to PDF or Export to Word features on the documentation page, per the screenshot below. To do so, choose the guide you wish to export and either the PDF or Word option.
If you do choose this, remember that this is a fast-moving project which, at time of writing, has just celebrated the launch of the JBoss Application Server 7.1.0 release. This means that there will be a lot of tired and excited contributors catching up on and expanding the community documentation. Just be sure you update your local copies regularly, and check back often for changes.
https://docs.jboss.org/author/display/AS7/Documentation
For JBoss AS 7.1, it has changed a bit:
https://docs.jboss.org/author/display/AS71/Documentation
Every minor version will probabaly have a new URL to preserve the docs for the older releases.
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 trying to integrate Glassfish server support to an already existing eclipse java (maven) project. IMore precisely, I am looking into JMS and queues. I have completed a tutorial wih NetBeans, due to lack of success in Eclipse, but as my skills and familiarity with Eclipse are a lot better, I would really like to make it work there too.
I've tried a lot of different, but similar tutorials, and here is what happens in all of them:
1. Download Glassfish Tools for eclipse. As far as I can tell, this is done:
2. Create new server, if not existing. No servers available. No Glassfish option available.
3. Try Downloading additional server adapters. Still no glassfish options...
None of the tutorials available seems to deal with this scenario. And they are all dependent on completing these steps. I am in the dark here. Any idea of what my problem might be? I am behind company firewall. There might be proxy-settings involved in this issue, but I have not been able to find the right concepts to explore if that is the case.
If it still doesn't work for you (2014.10.07) use the following link to install GlassFish 7.2 (with Eclipse's Install New Software mechanism):
http://download.oracle.com/otn_software/oepe/12.1.3.1/luna/repository
The one from the marketplace is 7.3, and it is broken for now.
Courtesy of Jan Kowalski
A new version of GlassFish Tools (7.3.0.201409251743) was released recently, which seems to be broken. There is this bug report, and I myself experienced buggy behavior after upgrading my installed version, too, like not being able to start the server anymore.
This is very annoying because apparently one can't revert to the previous version anymore either:
No repository found containing: org.eclipse.update.feature,oracle.eclipse.tools.glassfish,7.2.1.201407111426
Got the same problem at first when using the GlassFish Tools or the OEPE downloads (both deliver the same version) via Eclipse Marketplace. The installation runs smoothly, but no GlassFish option when adding a new server.
I'm running Kepler SR2 and Java 6 update 45.
Then, when browsing the Oracle site for OEPE, I found that the latest few versions are for Java 7/8. Via the archive page for OEPE http://www.oracle.com/technetwork/developer-tools/eclipse/downloads/oepe-archive-1716547.html
I downloaded version 12.1.2.3 which is the last one for Kepler and Java 6.
With this version, the GlassFish option in the New Server dialog finally turned up.
Took me a few hours to find out. It's a bit disappointing that there were no error messages in neither the Eclipse UI nor in de Eclipse log.
(No comments on me using an old JDK please :-) I'll upgrade in the near future.
There is a document from 2006 http://docs.jboss.org/jbossas/guides/installguide/r1/en/html_single/ that describes using a GUI to select options for installing JBoss. However, I'm unable to determine where the contemporary version of the jems-installer-1.2.0.jar mentioned in that install guide is found.
The wiki at http://community.jboss.org/wiki/JEMSInstaller provides links to passworded SVNs only; whatever it's discussing is nowhere to be found on the public SVN.
A blog post at http://www.ericgar.com/2006/10/17/eclipse-jbossas-ejb-30-setup-instructions/ provides a direct link to Sourceforge where there is an installer jar: http://prdownloads.sourceforge.net/jboss/jboss-4.0.4.GA-Patch1-installer.jar?download.
Does this utility simply no longer exist?
Here you go:
JEMS Installer on SourceForge
Although it looks as if the project was abandoned around 2008ish. It should support JBoss 4, possibly 5, but not any later editions from what I've read online.
Personally I wouldn't bother with it, installing JBoss is pretty simple - and getting to know the config files will help you later while you're administering it.
I'm thinking of writing a little program for my SDR-14 software radio
using Java and had a look
around for a Java library to communicate with the SDR's FTDI USB interface IC. A
quick Google finds loads of mentions of the JD2XX library which used
to be at ..
https://jd2xx.dev.java.net/
Except that that page now gives a 404 error so I wonder if that
project was deleted or left that domain following the Oracle take over
of Sun.
Does anyone know where this project has gone and where I can
download the library from ?
Regards
Ian
The project was evidently lost in the recent (or not so recent) java.net upgrade. The last reasonable archive I found with the source for the project is (oddly enough) at http://fred.bilinski.it/src/Fred-20050525.zip so you may want to download that and archive it. It has the source for the jd2xx classes and the jd2xx dll (not sure whether the dll is 32-bit or 64-bit) but these are dated from 2005, so you might want to reach out to http://bleyer.org/jd2xx/ and see if you can get more recent updates.
Alternatively you may want to look at http://sourceforge.net/projects/ftd2xxj/ which appears to be more recent.
It seems he has made a SourceForge project as well: http://sourceforge.net/projects/d2xx/
And the files can be found in the SVN repository: http://d2xx.svn.sourceforge.net/viewvc/d2xx/
The network between our company and Sun's javadocs seems to be down. Where can I get a copy of the javadocs for a given package, so that I can keep my own stash to handle network outages in the future? Are there any mirrors for the Sun javadocs?
For each major release there is a large doc package, e.g. here for JDK 1.6.
(I hope the link is correct, picked it out of the docs I downloaded a while ago. Can't connect to SUN either from here.)
Down for me too (java.sun.com seems to be MIA at the moment).
Some form of the JDK docs are here: http://www.docjar.com/docs/api/java/
Most surefire bet: download the source and run Javadoc over it yourself, and stick it on an internal web server.
(FWIW - I can't reach their javadocs from my internal network right now either.)
I run classfinder on a MacMini locally. It's a small webserver dedicated to serving Javadoc and related source. You just take the zipped Javadoc and (optionally) the source package, and drop them in the appropriate directory. Classfinder works out the dependencies between all the docs and presents everything as a unified set of docs.
If you have multiple versions of packages (e.g. different servlet docs) you can dynamically select what you want to display. It all works beautifully and deserves much more fame than it currently gets.