Update hibernate-validator in glassfish4 - glassfish-4

Glassfish-ApplicationServer comes with a bean-validator.jar, which itself includes / was built with hibernator-validator 5.0.0.Final
// From glassfish4-startup:
2014-05-13T14:49:37.260+0200|Information: HV000001: Hibernate Validator 5.0.0.Final
I want use another version of hibernate-valditor. How can I achieve this?
What happened so far..
Glassfish4-source is available at svn.java.net, but I cannot find anything close to a package "bean-validator". The only thing mentionable is nucleus/core/kernel/src/main/java/org/glassfish/kernel/bean_validator/, but that seem's to be a dead end.
Stackoverflow-Question How to upgrade the hibernate-validator 4.3.0.Final to the Glassfish 3.1.2? brings us to a good blog-article http://peter-butkovic.blogspot.de/2012/11/glassfish-311-oss-with-hibernate.html. In this blog-article, svn.java.net/svn/hk2~svn/branches/hk2-gf-3.1.1/ is mentioned. I don't know what that is, or where something similar for glassfish4 is.

You may refer to this question as a starting point.
It's not 100% up-to-date though as it applies to Hibernate Validator 4.3. But actually I'd expect the update from 5.0 to 5.1 to be even easier as no new dependencies have been added, so you'd basically have to update the OSGi bundle from Glassfish with the latest HV JAR (and update the manifest to export the new "valuehandling" package if you want to make use of this feature).

Related

install titanium module from github

i'm having some issues getting modules to work on my app - I keep on getting told that the requested module cannot be found.
It is entirely possible that i'm not installing the modules correctly - so, for the purposes of this question:
Once i've downloaded the zip file from git hub using the green "download" button, what do i do to import the module into my project? Not how do i tell tiapp.xml to use the module - just what do i do to install it?
Can you please run through using the facebook module found at https://github.com/appcelerator-modules/ti.facebook
thanks!
Inside the zip file of the download you'll see there is a folder called modules. This is the same folder that is in your root of the project.
So, an iOS module should be installed in the /modules/iphone folder. Once added, you can add Facebook to your app like this:
<module platform="iphone">facebook</module>
If you want to specify a version you can do so like this:
<module platform="iphone" version="1.1.0>facebook</module>
note: I made up the version number
You can also add it through the tiapp editor in Appcelerator studio, although it doesn't always seem to find the module. This might be a bug in studio though, usually it works great.
HMMMM
Two main issues here, one directly relating, the other less so.
Issue 1
The link i gave to get the codebase from github is wrong - well, it gets the codebase, but not in a form that can be used as a module. It is, in fact, the uncompiled version.
Versions for download can be found here.
So that takes care of issue one, what about
Issue 2
The latest version for use is a bit broken. Seems someone (from the appcelerator team???) decided to make the latest 6.0.1 release have a minsdk of the (at this time) as-yet-unreleased version 6.0.0, and sets the apiversion to 3.
This breaks the current release of 5.5.1, so for anyone reading this prior to 6.0.0 for appcelerator, you will want to use this release version.

is manual installation of findbugs plugin in sonarqube ok?

I have a fairly old sonarqube installation, which for various reasons I can't upgrade. I upgraded however the java plugin to 2.0, and run into an issue with multiple plugins being incompatible. I manually removed those plugins, and reinstalled them from the Upgrade Center once I was able to restart sonarqube. However, for whatever strange reason the findbugs plugin keeps failing to download from the center. I can however manually download the jar file from here:
http://downloads.sonarsource.com/plugins/org/codehaus/sonar-plugins/java/sonar-findbugs-plugin/2.0/sonar-findbugs-plugin-2.0.jar
and manually copied it to extensions/plugins/, as explained here.
when I restart sonar-qube I don't see any problem in the log file, and in fact I see this:
2015.06.25 12:44:44 INFO org.sonar.INFO Register rules [common-java/java]...
2015.06.25 12:44:44 INFO org.sonar.INFO Register rules [common-java/java] done: 6 ms
However, something is fishy: if I go to the update center, I don't see findbugs listed under the installed plugins, and yet I don't see it under the available ones either.
Can somebody clarify what should be done to correctly install manually?
Also, when I go to the Quality Profiles section I see only two rows under Java:
Rules
SonarWay 70 ...
SonarWay with Findbugs 70
This seems a very small number of rules, I know there should be many more...what am I missing?
The Java Plugin version 2.0 embedded FindBugs, so there's no need to download it independently. That's also why you're not seeing it in the download center. You should remove it and restart your server. That may resolve the issue with your profiles as well.

MEF Plugin update strategies for winforms

I'm developing an extensible application with MEF. The application will have many types of plugins to collect and process data in different ways.
I'm thinking about building a versioned online repository for the plugins, that will enable the user to download new versions of the plugins when they become available.
It would be nice if MEF could load different versions of the same plugin simultaneously, though from what I understand this isn't possible (correct me if I'm wrong).
So I've resigned myself to the fact I will need to update the plugin and archive the previous version.
What would be the best strategy for doing this?
Example 1
The Application downloads a new version of a loaded running plugin. I can't place the plugin in the plugin directory as there is already DLL with the same name. So I could rename the new plugin with a version suffix. I can't load the same assembly, so I guess I'll have to force a restart. So on restart, it achieves the old plugin and loads the new one.
--- This seems solutions seems a little messy
Example 2
The Application downloads a new version of a loaded running plugin.
The plugin is encased in some type of installer.
The installer closes the host gracefully and archives the existing plugin.
The installer installs new plugin and restarts the host app.
--- this also seems a little messy
I am seeking any correction of my assumptions, or any insight into a successful strategy to my achieve my goal.
The .NET Framework has a fearure called Shadow Copy which allows you to update loaded assebmlies. Basically it copies the assemblies to a temp folder and loads them from there. This way the assemblies located in your application's installation folder will not be locked by the OS and you will be able to replace them. ASP.NET, unit test framweorks and many other applications use shadow copying.
To enable this feature you will need to load your application in a new AppDomain since you cannot enable shadow copying on the main AppDomain. You can create a simple loader that will create an AppDomain and execute your application there. This is very straight forward. For an example of MEF + Shadow Copy have a look at Glenn Block's Way of MEF and in particullar the PartUpdatesInPlace sample.
Now as far as versioning is concerned you will need to be able to have two or more versions of an assembly loaded at the same time in the same application domain. There are two ways to do this:
Strong named assemblies in the GAC.
Assemblies with the version included in their name (like Plugin.v1.dll). Strong naming is optional in this case but a good idea nonetheless. The advantage of this approach is that two or more versions of a plugin can coexist in the same directory.
Have a look at this answer for an example of MEF + Versioning.
You can even use the recomposition feature of MEF and have your plugin container updated after:
A new plugin assembly is added
A plugin assembly is deleted
A plugin assembly is replaced
Have a look at this question for an example.

How to validate an upgrade before installation

We have an eclipse feature that is licensed and the license is handled by our own code. The user can go in on our update-site and upgrade his feature. The problem we face is when the user's license needs to be updated before he can use the new upgrade.
What I want to do is to validate the feature version against the users license and warn the user that his license needs to be updated before he install.
I thought I would do this using a custom eclipse p2 touchPoint action validateLicense.
Example:
My code is called, where I validate the version against the user's license. If it fails I warn the user and he can then cancel the installation.
So my first question is:
Do I get this right, or is it some other way to do this?
My second question is pretty basic:
Where do I tell eclipse to run my code?
I have looked here at eclipse help where they explain what it is. But I don't understand where to put the information to run my code? Is it in the feature.xml.
Lastly:
Is there an example how to create and use p2 touchPonts?
I implemented a custom action as shown here and I have a system that seems to work. I left out "touchpoint" extension as it's unnecessary in my case, but the rest is the same.
My action is executed during install phase of my feature (instructions.install) but maybe configure phase could work too. Collect phase did not work.
The action is executed during installation process, after the download was already performed. Ideally it would be before the download but it's not a big issue for me. Returning an error status from the action cancels the install. It leaves some downloaded files around but they do not get activated and are probably removed later by p2's garbage collector.
I also managed to do some more interesting things. My actions plugin has a dependency (optional and non-greedy) on my main plugin. So the install works like this:
Actions plugin is downloaded
Custom action is executed
The action detects whether my main plugin is already installed and if yes, it calls into it to retrieve licensing info. The main plugin has to expose an API for the action. The action also checks main plugin's version to detect whether the API is there or not.
The action now can decide whether to proceed or cancel the install. It can even interact with the user using Display#syncExec (this is what the code in checkTrust phase does so I think it's safe). If needed, the action could also detect whether the install is headless.
Some gotchas:
Action itself must be versioned. It's the version you declare in plugin.xml and p2.inf files and it's different from plugin's version. I just replace 1.0.0 with the same version my plugin has. This way the latest version of the action plugin is always downloaded before being executed. This is great because now any problem changes to licensing rules can be implemented in actions plugin.
Actions API changed between Eclipse 3.5 and 3.6. I will probably drop support for 3.5 as it's pretty old anyway.
Actions plugin should probably be signed. It's the case in my case. The system seems almost too powerful to me as just pointing Eclipse to an update site gets it to execute downloaded code.
I still need to test how this works with different versions of Eclipse and other IDEs. I saw a strange (non-blocking) error with 3.6. However the results are promising and it looks like the system might actually work.
Touchpoints are executed at installation time, which means that the resolution (validation) has already happened. I'm not sure they would help. What about creating an Installable Unit (IU) (or Eclipse Feature) that represents the license the user has installed. Then you would put a dependency from your product to that license.
For example, create an IU called com.mycompany.license (1.0.0). You would create another one called com.mycompany.license (2.0.0). When you installed a license, the appropriate IU would be added to the profile.
Now, when you go to install you product, the new version of the product would require license version 2.0.0. If this license was not installed, the resolution would fail.
Does this make sense? Do you think this would help?

Apache Felix not binding my configuration correctly - wrong inputstream version

I had a bundle deployed in an Apache Felix (Sling, in fact) host. The bundle contained some configurable elements, and its version was 2.0.
I have updated the bundle to v2.0.1 for some small code changes, and now the bundle will not pick up its configuration correctly - it remains at the defaults set in code rather than picking up the values configured in the Felix Web Console.
There is an error message in the log: "[Configuration Updater] org.apache.felix.scr Cannot use configuration pid=com.mypackage.MyClass for bundle inputstream:my-bundle-2.0.1.jar because it belongs to bundle inputstream:my-bundle-1.0.jar" which sounds like the cause of the issue.
However:
I can't edit the inputstream value through the web interface - only by stopping the server, editing the config file manually, and restarting. Surely when I update the bundle, the config should be updated too?
Although the inputstream specifies v1.0, the bundle did not have a problem when it was upgraded to v2.0. What's made the difference here?
I have done the same thing (though perhaps not exactly!) on two servers, and one server seems to have the config specify inputstream=v2.0 (and the bundle at v2.0.1) and it works fine. What caused inputstream version to update on this server? (Presumably the same as the answer to 2 - I imagine it'll depend exactly which steps in the process have been executed and in what order.)
Any advice gratefully received - I haven't been able to find any documentation that gives instructions or troubleshooting suggestions for administering bundles through the Felix Web Console.
If at all possible, I would simply stop and remove the bundle altogether and install it using Sling , e.g. with the maven-sling-plugin or dropping it in the /apps/myapp/install folder using WebDAV .
I find it easiest to be consistent this way and the installation is nicely automated and it handles bundle upgrades properly.