How stable is Netty 4, at least the parts that implement the HTTP codec, including web sockets? Is that portion just a renaming of packages, or have there been some fundamental architectural changes that make the code unstable?
I need to be able to use the HttpPost functionality from 4. I thought about trying to make it run in 3.4.0, but I am using OpenJDK and trying to drop 3.4.0 in gave me a stack trace because it couldn't load the class sun.misc.Unsafe. Perhaps this had something to do with trying to run this in an OSGi container, but I also looked at the rt.jar file in my OpenJDK install and sun.misc.Unsafe wasn't there. Perhaps just building it and making the sun.misc classes optional in the OSGi headers would help.
Using the Sun VM is not an option here, I need to use OpenJDK.
Netty 4.x is not really stable yet. We will prolly break a lot of the API within the next weeks. So unless you know what you do I would not use it yet ;)
The problem with the Unsafe class should be fixed in 3.4.1.Final which should be out this week if everything works out. The fix is related to this.
We plan to have a 3.5.0.Final release which will include the HttpPost stuff. We just want to have 3.4.1.Final first. So stay tuned..
Related
I'm installing Knowage in Windows. But when trying to make it work with OpenJDK 12, I've found several NoClassDefFoundError regarding classes in javax.xml (this one can be solved downloading small jar files) and sun.misc.BASE64Encoder (there are no jars for this one). Probably more, but those appear just trying to login. It seems to work fine with Java SE 8.
I have several solutions:
Leave Knowage with it's own Tomcat running Java SE 8, have a second Tomcat running Java 12 for any other app. But I'd like to avoid having two Tomcats, even if I'll have an Apache front-end proxying them anyway. Seems wasteful.
Fork Knowage, modify, compile, deploy, keep updated, redeploy, repeat. But I'd like to avoid the extra work.
Report an issue (done), wait for others to solve it. But I'd like to avoid the uncertainty of not knowing when it will be solved, if ever.
Take the rt.jar from Java SE 8, that has versions of those missing classes, place it in the tomcat/lib folder. I lean to this one, hence the title, at least until Knowage gets modified. But I don't know if this is safe. It seems to work: I can login! But, will it break the Universe or give headaches in the future?
Could you recommend me one solution or another?
I'm about to start setting up programmatic access to vTiger 5 from a Java application, and I was looking for a client library that will interface with the REST API. The vtwsclib library seems to be the right (only?) way to go. It looks like v1.0 was released in 2008 and over the course of a year, the version moved along to 1.4
There doesn't seem to have been any changes to the library since, except for a couple of weeks ago (2014-08-26) v1.5 was released. There's no documentation for it, either on the download page (like the other versions) or in the downloadable itself (that I can see).
So what's the deal with this new version? Is it suitable for working with vTiger 5? I'm considering migrating to vTiger 6. Is the the 1.5 library targeted at vTiger 6? Does it make no difference which version of the lib I use?
According to my findings, there are no significative changes in the .php, .js or .py code of version 1.5 compared to 1.4, and for the Java code it appears most changes are related to the project files and not the code itself.
I obtained the "diff" by extracting 1.4 to an empty git repository and subsequently adding 1.5 to it.
The repository is hosted at this link so you can examine by yourself.
Based on this, the answer to your question is that you can use it for Vtiger 5 as little or no changes seems to have been made. Please improve this answer if needed.
I have a Java application using Grizzly 1.9.59, Apparently around the version 1.5.x version 2.0 was also released with a totally new and incompatible API. Both versions are being developed 1.x being legacy.
So taking in consideration that both versions are being developed is it safe to assume they offer the same capabilities? What would be a really good reason to upgrade to 2.3.15(latest)?
Is there any documentation comparing both versions feature wise?
Does anyone know if they plan to stop developing 1.x, if so when?
I can't answer the question fully. But from their website:
The latest stable release of Grizzly is 2.3.14. Older versions of Grizzly (2.2.x, 1.9.x, 1.0.x) are still available and can be found on Maven Central.
So they see 1.9.x as an old version and on their website there are no direct download links, to 1.9.x. To me at least this indicates a wish to make uses adapt to the newest version.
So taking in consideration that both versions are being developed is it safe to assume they offer the same capabilities?
NO! It is not, many libraries run a legacy version, which primarily receives bug fixes and minor updates. File the new fancy version receives the awesome updates.
What would be a really good reason to upgrade to 2.3.15(latest)?
At some point when 1.x.x no longer is developed you will have to do it anyways. But really it is a cost/benefit situation you are in
How much time will it take to do
Will you continued to use Grizzly
Is the new API, so hard to learn?
How much do I need to change the rest of my code
and so on, personally I would make the jump, if I where looking for a long term solution.
Is there any documentation comparing both versions feature wise?
I have not been able to find any, not even on there Jira
Does anyone know if they plan to stop developing 1.x, if so when?
Try their mailing list for answers to that, they properly no more and might be able to provide a feature table as well.
Summary:
Their website focus on the newest version (and refer to prior as old versions), though 1.9.x still is in development. You can not be certain the two different versions has the same features and capabilities. If they stop developing 1.x.x you would still need to update to the newest version.
For questions about more project specific things try their mailing list
A small note, your question is pretty open. I know my answer is more a comment but not enough space in the comments.
is there a way of having a language-mixed component framework like OSGi? I'd like to mix modules or bundles that are written in C and Java. On the site of NativeOSGi (https://github.com/abroekhuis/NativeOSGi) there is a hint, however the project seems to be not maintained anymore. Is there a way of getting Apache Celix and Felix to work together?
The easiest way of making Felix and Celix work together is through the OSGi Remote Services specification. Work is currently being done to make Amdatu Remote (an implementation of that specification) interoperate with Celix. I would encourage you to ask on the Celix mailing list, as they can probably tell you more about its current status.
Like Marcel said, the best way to go would be using Remote Services.
Since the Amdatu Remote Services has been working on a new release I am not sure if the current version is compatible with the Celix implementation. If this is not the case, we should work on getting it up and running again.
You mentioned NativeOSGi, and while the github page isn't maintained, we are still working on it (sadly a bit slow..). Basically the idea is to make Celix implement the NativeOSGi API (or base the NativeOSGi API on Celix, just a matter of perspective). Since Celix has had a 1.0 release, we have started working on the API, so expect to see some progress on the trunk wrt NativeOSGi.
I hope this helps a bit, if there are any other questions, feel free to ask!
I need to make my Java program as a PlugIn to OME - an Image processing web based s/w having Java API
www.openmicroscopy
OmeroJava is the appropriate API for the latest version of OME (OMERO 4.2), if you are writing a client. If you would like to embed your code inside of Insight (the OMERO Java client), then you should start with How to write a client. Other links to OME-Java libraries are for a legacy version and should not be used.
Looks like the Open Microscopy Java API is worth investigation. If it's not, it's worth highlighting in your question as to why it's not suitable (marked as legacy?)