As the title says, is it possible? Right now, we have Java 6 + sqljdbc4 + glassfish 2.1.1. We're planning on upgrading our Java 6 to Java 8 in order for Sqljdbc42.jar to work, because we are having JDBC Connectivity issue and the solution might be to upgrade to sqljdbc42. Please see Option 1 in this link:
https://blogs.msdn.microsoft.com/dataaccesstechnologies/2016/11/30/intermittent-jdbc-connectivity-issue-the-driver-could-not-establish-a-secure-connection-to-sql-server-by-using-secure-sockets-layer-ssl-encryption-error-sql-server-returned-an-incomplete-respons/
Of course some of you might say to upgrade Glassfish to a later version but in case is this is not an option, would errors occur? I found out that editing the asenv.bat will do the trick (http://alvinalexander.com/blog/post/java/fixing-glassfish-jdk-path-problem-solved) but I'm not sure about the deeper problems we might face.
Thank you so much for your answers.
You would have to be very brave (and have lots of free time) to try jdk-8 on glassfish-2. While you can still download glassfish-2, the Extended Support support ends this year (2017). This is not even Premium Support, it's Extended meaning you have already gone too far by this time. I know this because of a client I used to work for that used glassfish-2.
There were multiple bugs and complaints reported or the 3-rd and 4-th versions with jdk-8, not even speaking of 2-nd. Unfortunately you should upgrade to something way more recent (and have a constant plan to upgrade from there still). Obviously you can try and change the jdk version and see what happens - but I bet you would be visiting this site way more often than you would want to.
The real reason why you should seriously consider upgrading is that not a lot of people can answer deeper problems we might face, because not a lot of people use this version. Just my 0.02$.
Related
We have two different 'suites' of software: the windows-side software and the firmware. And, unfortunately, only certain versions of the windows-side software work with certain versions of the firmware.
For example, if a customer calls up with firmware version 10 we need an easy way for everyone (techs, developers, secretaries, etc) to know what this certain firmware works only with versions 12, 13, 14, and 15 of the windows software.
We have a wiki page just listing the versions and it worked fine, but there are enough 'hiccups' of people not following the process that we needs something a bit more forceful.
We have mercurial as a versioning system, but I can't see how this would be helpful for this problem (we are fine with forcing everyone to install hg).
Any ideas of programs / setups / anything that will help us alleviate the problem?
EDIT: So far most of the discussion is what I can do with the code from now on. I'm working on fixing that, too, but what can we do about all the previous releases where I can't go back and change any code? Thanks everyone for your help so far! Very appreciated!
To add to ChristopheD's comment, one way would be to make the software check the compatibility:
either through Internet (to download the latest updated list of compatible firmware and see if one of those version is present on the local computer)
or through a simple local text file if no WAN connection is available (which is easier to communicate and update than a full application release)
You might take a look at ClickOnce deployment. It allows more advanced configurations such as minimal versions. The deployment server might be on the internet or on the intranet.
I do think that you will have to change the implementation to solve this problem anyway. You cannot force an update (if you could that would be very virus-like)
I suddenly thought of this.
Think in the case of your software developed in .NET, and as well as the .NET framework (various versions). Maybe you want to follow that.
The client's host may be installed with firmware version 10 and 11; but your application requires firmware version 12. so your installer will download and install version 12.
However if your application requires firmware version 10, and the installed version is 12, maybe version 12 will also contain files from the previous versions (non-conflicting) and thus allowing the application (which requires version 10) to run from version 12.
I hate to answer my own question, but I wanted to mark something as the answer (it's ruining my perfect score!):
All that we did (and it ended up mostly fixing this problem) is rearranging the wiki so that if you wanted a windows version, you had to select which firmware you were using (and vice versa). I guess people ignore text enough, but forcing them to click on something was enough to get them to think.
i wonder if Doctrine 2 is stable enough to use for a production project?
i guess the project will be finished 3 months from now so maybe then Doctrine 2 will be released in a complete version.
i'm wondering if its smarter to use learn and use doctrine 2 right away instead of learning the current version and then convert everything to version 2. cause i've read that the difference is huge between them.
thanks
I've been using Doctrine 2 in production for a few weeks now. Performance wise, it is much speedier than Doctrine 1. And it's much easier to develop with. I've had a few minor issues with bugs, or unimplemented features, but nothing that I couldn't work around.
Honestly, I don't think learning Doctrine 1 is terribly worth your time. Development for it will stop in 2011. And the two framework are so different, you're going to need to teach yourself twice.
As mentioned elsewhere, there have been some backwards compatibility API changes between the last Alpha release and the upcoming Beta (which is slated for the end of April), but they haven't been huge.
It's very possible by the time you're really picking up speed with a project, it'll be into the Beta phase.
The difference is huge, but one additional concern is API stability. I think they've stated in some blog posts that the API won't be considered final until a beta release (so far everything's been alpha). So, there's a chance you'll still have to refactor some code to fit any API changes they may make before beta.
I doubt they change anything earth-shattering, but not being able to say so definitively means that it's a little disconcerting for production use. My suggestion would be to at least wait until the first beta release, which should mark the API freeze.
My job is to upgrade all of our applications that use OpenSceneGraph (an openGl toolkit) version 0.9.9 to the latest and greatest 2.8. Well quite a few caveats come with this task:
1.) After version .9.9 there was a major overhaul the the core OpenSceneGraph (OSG). Commonly used functions and classes were added and removed. Simply put, I can't just replace the old with the new and modify a few deprecated or removed functions - there is a lot that needs to be changed.
2.) Our applications were built using MFC in Visual Studio 2003. They want me to stick with using that for the upgrade.
3.) Good organized documentation for my particular scenerio for OSG seems impossible to find and unorganized and scattered at best.
My question is: What would be a somewhat detailed methodical approach for tackling this problem. I've got about two weeks to upgrade one of the applications. The plan is then to follow and apply this approach for the rest of the applications. For me, the biggest hurdle is finding a starting point. On most projects I work on, I can easily just dig right in and figure it out with a little organization and plan at hand. This seems like a bit more convoluted problem, with a more accurate and precise plan of action needed. Your ideas and suggestions are much appreciated.
In my opinion, you should upgrade your osg to new version and try to build it again until you get no exception.
for every exception which is not solved easily, you can ask to osg-mailing list.
you can also ask what are the major changes with your current version and latest version.
Bugs can be difficult enough to resolve when they're your (or a coworker's) fault. However, we all know that the technology we use to implement our programs is written by infallible people such as ourselves. So it stands to reason that some people have been affected by bugs in the implementation of the tools they used.
So, have you found a bug in your program that was caused by a widespread underlying technology, such as a programming language or framework? If so, did it fail with some indication, or did it silently overwrite some data? How difficult was it to debug? Did it cause a potential security vulnerability? Were you able to contact the provider and confirm that it was fixed (or fix it yourself)?
Here are some of the worst (in my opinion) technologies to have a bug in (especially one that fails silently):
Programming language
Concurrency framework
Remote API
Database
I deal with one on a daily basis called Internet Explorer.
To be fair though, there are lots of bugs in all of the browsers. I have filed several bugs for Firefox as well, and just the other day I found a strange case where the border doesn't take padding into consideration.
This is a good argument for writing lots of unit tests. If you upgrade your platform to a newer version that has some new bug, hopefully you have a test that reveals the bug
in one case I had, the vendor was working on a brand new API. They were not ready to release the new API, but they were not very keen to fix the bug in the old one either as they considered it dead from a $$ perspective.
A colleague once stumbled across a bug in the Jikes Java compiler. He had something like this:
if (condition)
{
}
else
{
System.out.println("Code that does stuff.");
}
He hadn't intended to leave the top block empty permanently, but just had it that way during development. He discovered that the condition was ignored unless he put a comment in that block so that it was no longer empty.
During my time developing (mostly) with Java I've run into bugs in the following components:
Java compiler
This actually happened several times. Usually we found that ecj (the Eclipse compiler) and javac (the Sun compiler) disagree about the validity of some Java code. Usually I enter bug reports for both systems, one of them gets accepted and the other one is closed as invalid.
Database engine
Those are very rare and very, very nasty, because no one expects the DB itself to have a bug. In our case it was an old product (the bug was already fixed in a newer release) that accepted values in a field that were not within the defined range (similar to having a NOT NULL field containing NULL)
JDBC driver
There were several bug fixes to a JDBC driver due to a project I've been working on. The bug fixes ranged from trivial ("why is there debug output in the production release?") to might-not-even-be-a-real-bug ("you can easily safe one roundtrip per statement by doing that-and-that").
JVM implementations
those are hard to diagnose and often present themselves as effectively random crashes on one JVM and stable operation on another one. We temporarily switched JVM vendor several times due to things like this.
Each time it took quite some time (and usually the involvement of the vendor of the component) before I actually believed it was a bug in that component.
And yes: the cases of false positives (i.e. the bug was actually in my/our code) were orders of magnitude more common.
The only place where bugs in the third-party component are kind-of expected seem to be web browsers. Almost no one questions you when you say "that's a bug in <insert buggy browser of the week>, we need to work around it like this ...".
I guess almost anyone who has programmed JavaScript with Internet Explorer has found a bug in their program which was caused by a widespread underlying technology.
The indication of failure is the blue "e" on your Windows desktop.
The first that comes to mind was with version 1 of the .NET Framework; for some reason, Random.NextDouble() method never produced a value greater than 0.5. I was completely baffled, and having run a test apps that called the method thousands and thousands of times, I had to presume it was a bug and work round it.
Never did find out what the cause was...
I've run into something with the gcc 4.4.0 but as the product I'm currently working on is still pre-alpha, it was fairly easy to repair locally. Hopefully they'll fix it soon.
i found a very strange bug in gcc on Mipsel (openwrt). We was testing a small app (about 3K sloc) that give me sigsev even if the code was corrected in theory.
I don't know the detail of the bug (and I don't have that code anymore) but change the gcc version from 4.1 to 3.6 solve the problem.
I'm unemployed and I have a job interview tomorrow where knowledge about Websphere 5.x and Websphere 6.x is required. I only use Tomcat and Glassfish.
What is the strict minimum to know about Websphere? They will ask me if I have ever used it and I will say no but I would like to have a few things to say in order to lower the impact of not knowing it.
Thank you very much for your help
Besides the obvious (its file structure, deploying an app, etc.) maybe you can surprise the interviewer by mentioning some features version 6 incorporated. I found really useful to read changelogs to understand the features of a software version
You need to know just enough to be able to rip it out and replace it :-)