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.
Related
I'm referring to an old Java application, almost 10 years old.
My application uses technology components like Java Webstart component (JNLP), FlexDock ( Java Docking for native UI library ), jdic, etc.
For authentication, this application directly using login credentials. Want to upgrade to Azure Active Directory.
Can we accommodate Azure AD functionality in such an application?
is anyone have any reference document or something?
JDIC is obsolete technology and the project was "abandoned" 12+ years ago.
There is a copy of the source code tree sitting on Github but the original website (java.net) that where the project material, mailing lists and so on once lives is long gone.
Flexdock (not Flexdoc) is also available on Github. It also appears to be inactive. (The last commit was in 2018.)
However, it appears that SciLab depends on Flexdock, so there is still some life in the project.
Can you integrate JDIC and/or Flexdock with AAD?
Frankly, I don't know.
But I would suggest that you are better off removing all dependencies on JDIC. Or, if that is too much effort, maybe you should consider ditching your 10+ year old legacy application.
My team is using Pebble template engine for preparing messages. We have done lot of POC on this and everything looks good in our side. We decided to implement that.
Now problem we see here is we are having JRE1.6 in our application servers but pebble jars are compiled in JDK1.7. So we are facing version mismatch error. Can anyone suggest a workaround for this problem?
We are already approaching our release timeline and stuck here :(
Technically, there are 4 options:
You start searching; sometimes either the providers of libraries; or some "mirror site" somewhere has kept older JARs. Maybe those would work instead.
You upgrade your application server to run on a 1.7 runtime.
You could try to de-compile those JARs; to then compile them with Java 6.
Turn to the home page of peeble, find that it points to GitHub ... in other words: we are talking about open source here. So: you download the source, and you build your own jars; using a Java 6 environment.
Option 3 is obviously the most "hackish" one; and there might even be licence terms preventing you from doing that. And on the other hand, option 2 sounds scary; but you know: when you just change the underlying JRE (without touching your app server itself) there is a certain chance that this "just works".
And the real takeaway here: such subtle details are important. You should improve your processes to discover them early up; not during the last 5 minutes of your schedule.
I need to upgrade the source code for an existing Java EE 1.4 application to Java EE 7. What I need to do primarily? Any particular steps in order which I need to follow?
You are looking into a time difference of 10 years between 1.4 and 7, which in the IT is huge.
Replacing the old J2EE parts by Java EE code basically means rewrite the whole application - so it very much depends on what exactly needs to migrated and how much you can control this scenario.
From an own project where I had to deal with J2EE code I can recommend - if rewriting is not an option - to make the old application run on a new application server and only migrate small parts of it, if possible into a newly deployed application. This worked well, we still have J2EE code in the application and even add/fix small parts in the old code, but it runs together with Java EE code. One thing you have to take care about is the entity manager, because it leads you into trouble if you persist the same data via both ways.
Other than the obvious syntactical changes, I'd suggest looking at what libs you're using and seeing if those are now supported under 7.
When moving application code across versions, most of the time the jump is backwards compatible (I'd say in your case it won't be given such a massive jump) but one of the biggest factors will be if you're using legacy third party code, you'll need to find new supported versions of those products.
This includes say, if you're using a legacy application server and upgrading that. After all this then you can start to consider any syntactical changes that your IDE should help you with :)
I'd recommend WebSphere Migration Toolkit (an Eclipse plugin). Although it's primary usage is to look for a changes, when migrating from other platforms to WebSphere, it will scan your code, jsp pages, xml files and detect any Java, Java EE related issues also. So you will have rough idea what will need to be changed e.g. in relation to JDK changes.
See some info about that toolkit:
WebSphere Migration Toolkit
WebSphere Migration Toolkit download
Other WebSphere migration tools
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.
I've recently been messing around with an open-source Java web app. I'm using JDK 7 locally but I know that the upstream builds using JDK 6.
I want to write some code that uses classes that only exist in JDK 7 (currently, ThreadLocalRandom). I can do that on my local system just fine, but when I want to send patches upstream I have to hunt down any such references and translate them to the equivalent JDK6-safe code, which is a pain in the butt.
Is there a way to have both JDK6 and JDK7 source in the project, and have Eclipse automatically use the appropriate version at compile time based on the project target? I would like something that's easy for both myself and the upstream maintainer, so nothing like weird build scripts or text replacement.
The project does use Guice, if that helps, although I think doing it at runtime might be too late (because then the maintainer wouldn't be able to compile using JDK6 tools).
I'm only at "dabbler" level in Java, so please use small words.