I have updated to Azul Zulu 8u282 JRE and I noticed a new JAR file that wasn't there in the previous version I used (8u265). It's called 'crs-agent.jar' and the class files are all inside the package structure 'com.azul.crs.*'. When I decompile them with IntelliJ it looks like some diagnostic or reporting stuff and there's also networking at work.
I went through lot's of release notes of current and old releases on the Azul website but there is no information about this CRS. Wikipedia yields several results for that acronym with 'Carrier Routing System' making the most sense.
So what is this JAR for? Can I just delete it?
Yes, you can ignore/delete this file. It's not used and was added for experimental features that are turned off and are never used at the moment.
The latest release notes refer to this as:
New Experimental Features
Zulu includes optional experimental support for interaction with
connected runtime services through an emerging protocol. These
experimental capabilities are enabled by the -XX:+UseCRS flag and are
turned off by default. The -XX:+UnlockExperimentalVMOptions must also
be on for this option to work.
Related
Are there any plans for the ServiceStack packages to start using the SemVer standard? We just had an unfortunate circumstance where we were broken by the interface breaking changes introduced in 4.0.44 from 4.0.43 around OrmLite.
We are a sizable commercial customer and have a custom implementation of a OrmLiteDialectProvider for one of our DBMSs, it all seemed good upon the initial upgrade in our web application, however as part of testing the changes around type converting broke our system. This wasn't initially evident as part of the upgrade because our custom implementation is in a NuGet package which overrides OrmLiteDialectProvider.ConvertDbValue on version 4.0.38 which is now gone. There were no binding issues because it is only a minor version difference.
NuGet adopted SemVer back in version 1.6.
Having the SemVer standard would make it a lot easier for us to know when interface breaking changes have been made, without having to dig through the Release Notes page.
NOTE: The release also didn't indicate that the old method had been removed and upgrading would break any custom implementations.
UPDATE FROM RESPONSE
Anyway, fair enough answer. I can appreciate it would be difficult to track each package individually. In our case we wrote a custom dialect provider as we have a legacy DBMS that wasn't supported and this appeared to be the way we were supposed to add the support. We wanted to use ORMLite because we use the rest of ServiceStack and it's a fantastic product.
The new way to support the types is a great improvement and actually made our implementation easier.
We actually ran into this issue because we do always keep our ServiceStack packages inline and were upgrading the ASP portion for some fixes to the WSDL generation and this came along as part of our upgrade.
ServiceStack adopts a single rolling version for all NuGet packages which all share the same Version number. Of all ServiceStack's 60 NuGet packages it's likely there's a breaking change to at least one of the packages so semver would be useless, you should also never mix and match different versions of ServiceStack together - when you upgrade, upgrade all packages to reference the same package versions. We do aim to keep user-facing breaking changes to a minimum, by looking to deprecate old API's first, maintain parallel API versions for a while then list the new API's release notes.
IOrmLiteDialectProvider is not a user-facing interface
However IOrmLiteDialectProvider is not considered a user-facing interface since it should be extremely rare that anyone implements their own custom provider. It's also the interface for specialization for all RDBMS's and often changes with every release to support new features, internal refactoring, optimizations, etc. E.g. implementing Type Converters was a major internal refactor that required changes to IOrmLiteDialectProvider but did not affect OrmLite's external user-facing API, later releases includes optimizations requiring further changes, again this doesn't affect OrmLite's external user-facing API.
SemVer won't help here, every ServiceStack version potentially has a breaking change in some of the packages and we have no intention to complicate each release by versioning each of the individual packages differently. The issue you're having is depending on an unstable Interface that's not intended for customization. It's not treated as a user-facing API so we don't try to maintain compatibility with existing versions or publish breaking changes which happens nearly every time we add features / optimizations to OrmLite. You should instead check the commit history of
IOrmLiteDialectProvider for any changes to this interface.
We've upgraded to latest Azure Management libraries from Nuget and are seeing that the calls to CloudContext.Clients.Create-various-management-clients no longer exist. Is there a substituation somewhere else for this functionality?
TIA
So, it appeared that there is a decent amount of updates in the "Preview" mode of Nuget libraries for this.
It looks like some libraries, /at this time/ are released as stable releases that point correlate with dependencies in the "Preview" state. So, all of the CloudContext.Client extension methods are only present in the Preview library as Microsoft is migrating namespaces from Microsoft.WindowsAzure to Microsoft.Azure
Very confusing at the moment, hopefully things will clear up
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.
I'm going to upgrade my company's subversion server from version 1.6 to 1.7. The server runs on linux (Ubuntu AFAIK).
I've read all those:
Subversion 1.7 release notes
I've also read those posts:
subversion-client-version-confusion
how-to-upgrade-svn-server-from-1-6-to-1-7
Here and now, I know how to perform this. It's not a big deal. What concerns me the most is the current hooks infrastructure. There are several scripts in bash and perl.
As for now I've found no information referring hooks infrastructure changes, but maybe there are some known issues I missed? Is there anything against the upgrade I should know?
PS: Try and see what comes method is absolutely unavailable. I'd like the upgrade to be as fluent as possible. Repository users shouldn't even notice any changes. I can't allow myself any failure in that matter.
The Subversion compatibility guarantees promise that your hook scripts are called exactly the same in 1.6 as in 1.7. In 1.7 (and future versions) more arguments can be passed to scripts, but the old arguments still match the old behavior. So if you created your scripts like the templates, to ignore 'extra' arguments you shouldn't see a difference.
Subversion 1.7 didn't change the repository format since 1.6, so you can even (accidentally) use the svnlook from 1.6 to access the repository after upgrading.
Try and see what comes method is absolutely unavailable...
Yes, the try and see what comes method is available. You build a copy of your Subversion 1.6 environment, make the Subversion 1.7 changes, and test until everything is correct.
I don't see how you can accomplish your goal of a quiet upgrade unless you copy and test.
I guess it depends what you do with your hooks...
If your hooks are using svnlook, you should have no issues. If you're using an API (like the Python API), you probably are also okay as long as you're doing svnlook type of stuff.
Where you might start heading into problems is if you poked and prodded where you weren't suppose to poke and prod. For example, instead of doing svnlook, you do svn. There are a couple of places where the parameters have changed. Also, if you did an svn checkout (an absolute no-no in a hook) and then looked in the .svn directories, you'll get a surprise. Follow the rules, color in the lines, and your hooks won't have any issues.
I don't know of any issues from Revision 1.1 to revision 1.7 that should affect well behaved hooks hooks, and I suspect that you will not have any issues as long as we are still in Subversion 1.x. When Subversion 2.x comes out, all bets are off.
Yes, there have been some changes in how hooks work. The start-commit hook has an extra field that wasn't in versions 1.4 and earlier (The capabilities field), but nothing that would affect current hooks. And, in either Subversion 1.5 or 1.6, users now can set revision properties when doing a commit. These don't affect current hooks, but might be features that you want to incorporate in your current hooks.
The upgrade has been performed and succeeded. Subversion server was updated without issues. Hooks were designed without any hacks or slashes, respecting the rules and common sense. It was risky but promising and came out profitable (checkouts are light-speed now).
Just for sake of completeness: there was a consecutive centrally managed client upgrade. And there were issues, however not critical and predictable. After transition svn client 1.6 -> 1.7.7 working copy format changed. Every existing working copy had to be manually upgraded (or wiped out and checked out clean again).
Server upgrade is safe though.
Can you suggest a tool(if exists) to keep track of all the versions of all the resources i use to develop a project?
i.e. Project:Myproject
IDE:Eclipse
php:5.0.2
iReport Plugin:1.2.1
...
Thanks.
One approach is to use source control: check in the binaries (or installers) for all the tools you use along with your project. When you upgrade a tool, check in the upgraded version, so the source control history includes everything that is needed to build a particular version of your project. If you want to build last year's version of the code, everything you need is then in source control.
(Disk space is cheap, so just keep a copy of everything)