Is OLAP4J (Java library for connecting to XMLA services) dead? The things that suggest it is are:
The web site hasn't been updated since 2013.
The last message on the dev mailling list was in May 2016.
The last available release build was 1.2.0, in 2016. There are more recent release tags, but the build artefacts haven't been uploaded to any Maven repository.
If it is dead, then is there a suitable replacement?
I am the original author of olap4j, and also own the www.olap4j.org domain. Development has certainly been slow recently, but I wouldn't say the project is dead. If people have pull requests to contribute, then I will be happy to commit them to the project and make new releases.
I don't know of any alternatives to olap4j. The idea that you can connect to any XML/A-compliant OLAP engine via Java, get metadata in the same way that you would from a JDBC data source, and that your code depends only on the API, not a particular driver implementation, is still a good one.
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 looking to query LDAP server to retrieve all the user entries from it. I have come across some libraries
OpenLDAP
LDAP SDK
Mozilla Directory
Apache Directory API
My requirements would be to query all users in an LDAP implementation like AD Server, ease of programming and good community around the library. I don't find a clear winner here. Can someone tell me the widely used and robust API?
The best API to use with Java is the UnboundID LDAP SDK. It's clear, complete, fully implements the LDAP standard specification, easy-to-use and understand, fully documented, thread-safe where it should be, and the standard edition is free. No other API even comes close.
see also
LDAP Examples using the UnboundID LDAP SDK
Had to dive into Java LDAP SDK market, as some old LDAP JAVA programs with SDK bugs needed to be fixed and I had lost up-to-date overview of supported Java LDAP APIs for a while. A little research has brought me to several aged overviews and this rather old thread. I thought, I'd just share my more-up-to-date SDK findings here.
As of today, this is what the Java LDAP SDK market seems to offer:
jLDAP (Novell Java LDAP SDK),
OpenLDAP Java SDK (sibling fork of Novell LDAP SDK),
Netscape/Sun Java LDAP SDK,
OpenDS LDAP SDK: All 4 repositories seem practically dead/unmaintained for several years (some of them for a decade now) now. No backing companies or active communities in sight.
Oracle LDAP SDK: Basically the former Netscape/Sun Java SDK with paid Oracle support, but otherwise not maintained either. Does not even exist in the open source world.
OpenDJ Java LDAP SDK: The backing company has moved away from the open source market, no longer maintain this SDK. The most recent SDK version 3.0.0 is already several years old and never left beta stage, the latest official release version is even older: 2.6.11. The commercial version of the SDK is said to be practically abandonned either.
ldaptive.org: some university project. A former JNDI wrapper, but now claims to have an own LDAP SDK protocol implementation. There seem to be no community or users outside of the university perimeter. Not dead, but currently unclear, what quality state to expect here. If you'd ask me, this project would have done a lot better, to spend their time backing the Apache LDAP SDK project, as no one actually needs yet another look-mom-I-also-made-an LDAP-Client-SDK in an a saturated market full of other mostly mediocre JAVA LDAP SDKs.
Apache LDAP SDK: Compared to other Apache projects, the LDAP SDK shows really slow pace. Somehow Apache LDAP seems to miss a real company backing things, it's only talented hobby enthusiasts pusing things forward. You probably do not want to start any new projects with SDK V1.0, as they state that V2.0 breaks interface code. but you probably also do not want to use SDK V2.0 yet, as it's still beta and no one knows for how much longer it will stay beta (V1 stayed beta for 6 years...). The SDK is far from being dead, it's just showing really really slow progress.
Java JNDI: Built into Java since ages and has not changed since release. Still is really ugly for coding, documentation is a mess, every task beyond basic search is an implementation nightmare, basically every project fails to properly implement it, several things are broken by design. There seem to have been a few concept ideas of a JNDI-LDAP-successor for a future JDK, but nothing has ever followed so far.
Unbound SDK: Mature, best maintained SDK, has huge amount of features, though the backing company is still nurtured from venture capital, burning money. So far it does not look like they stand on their own feet any time soon. So the long term aspect of SDK backing support is unclear. A former party pooper for the SDK in commercial projects once was its GPL license. The open source version now seems to have a LGPL license as well (that may or may not fit a project).
Spring: seems like a stable LDAP SDK, plus has the large Spring community. But less feature-rich and no bleeding edge stuff. Personally no experience yet though with this SDK.
So right now, Java LDAP seem to have a reasonable choice of four: JNDI, Unbound, Spring, Apache, each with their pros and cons. And you probably will hate JNDI a lot, as soon as you start using it.
A good advice might be, to not rush into migration projects of old SDKs and to invest into the extra effort of implementing wrapper code, to be at all able to easily switch the SDK later when needed.
Check the Apache Directory Client API it is opensource and has an active community (full disclosure: I work on Apache Directory project) and most importantly Apache Directory Client supports all basic LDAP controls including password policy and syncrepl by default unlike some commercial versions which support these in a paid version only.
You can easily add new/custom controls and extended operations if needed and it is very easy to start an in-memory Directory Server with the help of the annotation driven test framework
Take a look at this example to see how you can leverage the API and test framework for unit testing.
And otoh, if you ever need a Kerberos v5 server in your unit test, it is just an annotation away.
We use the the UnboundID LDAP SDK. It is very good and there are many examples and good support.
Poor support and maintenance for the JLDAP and Mozilla Directory APIs is why we QUIT using them.
Like the https://wiki.mozilla.org/LDAP_Java_SDK does not exist.
The JLDP sdk has not been updated in YEARS. (2009 as I recall).
There is also open source lib from Imperva https://github.com/imperva/domain-directory-controller
There You can find a pretty good examples of queries.
I'm using https://www.ldaptive.org/ in production, so far I'm pleased it's like 'ORM'
I've read the HornetQ FAQ, but I can't find anything related.
I'm using HornetQ 2.2.5, it contains a bug (yeah, just one ;). According to this post https://community.jboss.org/message/624958?tstart=2 it's been fixed from 2.2.7.Final onward.
On the main download page, http://www.jboss.org/hornetq/downloads the latest version available is 2.2.5.Final. I'm not scared of compiling a newer version myself, but can I consider it stable?
I'd say yes since it's a minor release update, but I'd like some other opinions. Thanks.
This answer uses the 2.3.X branch as an example. Let's skip looking at their Downloads page, and go straight to the artifacts:
http://mvnrepository.com/artifact/org.hornetq/hornetq-pom
You can see that 2.3.X went through Alpha, Beta and CR stages, to finally reach 2.3.0.Final, the Community release. This is what most people in the open source world would end up using, and what you will find available for easy download.
It's also the last version the non-paying customers are intended to use (in the typical JBoss release cycle - see e.g. the JBoss AS/EAP FAQ). Now, from a commerical perspective, 2.3.0.Final would be considered Alpha again. An analogy from the JBoss AS/EAP FAQ which probably applies here too: "The first EAP stage Alpha is of equivalent, or better, quality to a community Final release [...] we don't recommend using it in production" (probably an overly harsh judgement, but anyway.)
After 2.3.0.Final, they fix more bugs (2.3.1.Final, 2.3.2.Final, ...) until they get to a commercial production release (which they bundle into their other commercial products). So, you should be using the latest .Final that you can for production (for the 2.3.X branch, it was 2.3.13.Final).
Do you have to pay for 2.3.13.Final? From what I can tell, you don't. (HornetQ is also not available commercially AFAICT, except when bundled into other products.)
How do you get 2.3.13.Final? You probably won't find a nicely packaged RPM or even zip file. Instead, you will need to get the JARs from public Maven repos (or build from source).
Do you need a postgrad degree in JBoss Versioning and Product Naming to use their products? Perhaps :) - I don't have one, so apologies in advance if I have failed to comprehend the enormous complexity of the beast. But I do wish the HornetQ developers would make it easy to get a stable release of their product, and know that this is what one is using. It's a good product (perhaps the most fully featured of the lot), with an excellent manual, but a snap judgement of the download page and FAQ may make some people look at competing projects instead.
Well, after some more research, I can say yes, it is stable.
In particular, JBoss EAP 5.1.2 package includes HornetQ version 2.2.10.GA.
I wonder why there is no direct link on the HornetQ download page.
Folks, I am in the process of releasing a plugin for Solr (under ASF license) that implement different ranking strategies. I have tested it against 3.5 version, it works great, since I started fairly recently on open sourcing it went with latest version of Solr (3.5). But then a request came in to use that plugin for version 1.4. The problem is that Solr API has undergone some significant changes between 1.4 & 3.5.
For instance, SolrQueryResponse was moved from
org.apache.solr.REQUEST.SolrQueryResponse (1.4)
to
org.apache.solr.RESPONSE.SolrQueryResponse (3.5)
I use Git for DVCS, Maven for Build/Project Management, Google Code for project hosting, what would be an ideal strategy to make changes & maintain the code for different versions of underlying Solr/Lucene API. Branch could be way to achieve it, but I am not really convinced.
Would like to know if there is a better way to develop/maintain code for different underlying API versions & distribute them ?
What Java WebDAV client side library could you recommend?
I've recently created one that is quite easy to use:
https://github.com/lookfirst/sardine
Have you looked at Jackrabbit's?
OK I'm a bit late, but you really should check out the milton webdav server project. Its open source (apache2), mature and is actively maintained.
Its designed to allow any backend implementation to be hooked up to webdav, and many users have reported implementing it in under 4 hours for existing applications.
It supports all the usual webdav stuff like locking, custom properties, digest/basic authentication, etc. It also supports caldav and integrated with apache FTP so you get 2 protocols for the price of one!
Milton ships with a servlet and a spring controller, and it can run independently of a web container.
Milton also has a nice little webdav client library, which is ideal for desktop apps due to its observer support.
I used the client library provided by the Jakarta Slide project for a software that I developed about 2 years ago, and it worked fine. Now, visiting the site, I see that the project is no longer active for lack of developers. But the client library should still be a good choice for you. Anyway, I don't see many alternatives out there.
Try to esteem about them here: http://www.webdavsystem.com/javaserver
Did you check Sardine?
https://code.google.com/p/sardine/
https://github.com/lookfirst/sardine
Latest release 5.3 - August 2013 and available at Maven Central:
https://mvnrepository.com/artifact/com.github.lookfirst/sardine/5.3