In JBoss EAP 6.1, there is a file
JBOSS/bin/client/jboss-client.jar
It contains all the client classes needed by web applications. However, when we install a WAR file, it is not seeing these classes available to it.
To work around this, we have been including a copy of this JAR in the war files WEB-INF/lib folder. These copies are a waste, but more importantly it means we have to have a different WAR file for every app server we want to install into.
Is there a trick to allow the applications in the WAR files to load and use the classes from this library where it is, without having to copy it into the WEB-INF/lib folder of the application? Alternately, is there a place we can copy this jar so that it would be available to all WAR applications?
The solution was to place a file named jboss-deployment-structure.xml in the WEB-INF folder. The contents of that file was:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<!-- Excluding conflicting JBoss-6 Implicit Modules so that jars bundled within war file is used. -->
<exclusions>
<module name="org.apache.log4j" />
<module name="org.apache.commons.logging" />
</exclusions>
<!-- Defining additional dependencies for JMS usage in model API -->
<dependencies>
<module name="org.jboss.remote-naming" />
<module name="org.hornetq" />
</dependencies>
</deployment>
</jboss-deployment-structure>
This allowed us to use the JMS classes from JBoss without having a copy of the client library included with the application being installed. It seems that some time ago, a programmer ported the application to JBoss, and ran into a problem which was "solved" (hacked) by putting the client library in, but this is a far better solution.
Check Jboss Modules to make the lib available as an external module of Jboss.
https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Development_Guide/chap-Class_Loading_and_Modules.html
Related
I'm trying to put an ASP page on my website that accesses a MySql database. The Website project was built in VS2015 and I used MySql.Data dll version 8.0.11.0 (the latest release).
I hosted the website on localhost on the development machine with IIS server. The web.config file has the following assembly reference which was created by VS -
<compilation debug="true" targetFramework="4.0">
<assemblies>
<add assembly="MySql.Data, Version=8.0.11.0, Culture=neutral, PublicKeyToken=C5687FC88969C44D"/>
</assemblies>
</compilation>
Everything works fine on the development machine, I can access the database, execute queries, etc.
The problem comes when I upload everything to the hosting server. The assembly reference above causes the following error from the parser -
Parser Error Message:
Could not load file or assembly 'MySql.Data, Version=8.0.11.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d' or one of its dependencies. The system cannot find the file specified.
I'm thinking that the host server may not have this latest version. Could this be the problem, and if so, how should I reference the MySql.Data assembly?
I have looked all over the web, but cannot find anything very specific, would greatly appreciate any help.
The proposed fix was to paste the MySQL.Data dll in bin folder
I downloaded and installed the NuGet Package: Select.Pdf. At runtime, when I click on the button that utilizes the code using the Select.Pdf namespace, I get the following exception:
The package is in the proper file directory and is properly installed, as you can see via the packages.config file:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Select.Pdf" version="16.4.0.1" targetFramework="net452" />
</packages>
I've been fighting with this for 2 weeks and I'm pretty much over it. Has anyone ever encountered this? Does anyone know how to fix this?
Possible fixes for this issue:
Please check whether Nuget package restore is enabled and the
packages are restored properly.
A folder called packages will be added to the folder where the solution file (.sln) exists when you build the solution or restore NuGet packages.
Please check the reference path to the assembly in your project file
and the actual location of the assembly is same.
If both project (.csproj) and solution(.sln) files are in the same folder then it will be packages/select.pdf in your project file
The version you are using in code and referencing can also cause the
mismatch.
Ensure the assembly version restored and referred in the project file are same.
I am developing a Windows Store App and I like to keep the most recent baseline installed while developing the next.
The problem is that whenever I run the current developmental version in Visual Studio 2013 (with F5) it un-installs the recent baseline.
I create and install a baseline by manually editing the Package.appxmanifest as follows:
edit the Identity Name
Append .R to every instance of the app name (eg. MyApp to MyApp.R)
(full file listing below)
I think that should be enough, but in my vain attempts to get this working I have also, in the project properties, append .R to the Assembly name, eg. MyApp.R, and changed one number in the MyApp_TemporaryKey.pfx
Then, when I run the app (F5) it is installed as MyApp.R, and persists and can be used outside Visual Studio.
The problem is that when I undo these changes to resume development, and run it again as MyApp then MyApp.R is uninstalled, and I am left with only the latest version, ie. MyApp.
I know that this is achievable because I have done it once before. I didn't record exactly what I did that time, because it didn't seem too hard, but after hours of trying I can't do it again. Either I haven't reproduced the steps correctly, or something has changed in Windows 8.1 since I last did it.
Why does Windows think the two versions are the same App? Is there another identity or key which I haven't changed?
Package.appxmanifest:
<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://schemas.microsoft.com/appx/2010/manifest" xmlns:m2="http://schemas.microsoft.com/appx/2013/manifest">
<!--<Identity Name="8086b500-65af-4dd4-a67b-923c43472921" Publisher="CN=joedev_000" Version="1.0.0.0" />-->
<Identity Name="11111111-65af-4dd4-a67b-923c43472930" Publisher="CN=joedev_000" Version="1.0.0.0" />
<Properties>
<DisplayName>MyApp.R</DisplayName>
<PublisherDisplayName>joedev_000</PublisherDisplayName>
<Logo>Assets\StoreLogo.50x50.png</Logo>
</Properties>
<Prerequisites>
<OSMinVersion>6.3.0</OSMinVersion>
<OSMaxVersionTested>6.3.0</OSMaxVersionTested>
</Prerequisites>
<Resources>
<Resource Language="x-generate" />
</Resources>
<Applications>
<Application Id="App" Executable="$targetnametoken$.exe" EntryPoint="MyApp.R.App">
<m2:VisualElements DisplayName="MyApp.R" Square150x150Logo="Assets\SquareLogo.150x150.png" Square30x30Logo="SquareLogo.30x30.png" Description="MyApp.R" ForegroundText="light" BackgroundColor="#464646">
<m2:DefaultTile Square70x70Logo="SquareLogo.70x70.png" Square310x310Logo="SquareLogo.310x310.png" Wide310x150Logo="WideLogo.310x150.png" ShortName="MyApp.R" DefaultSize="square150x150Logo">
<m2:ShowNameOnTiles>
<m2:ShowOn Tile="square150x150Logo" />
</m2:ShowNameOnTiles>
</m2:DefaultTile>
<m2:SplashScreen Image="Assets\SplashScreen.620x300.png" />
</m2:VisualElements>
</Application>
</Applications>
<Capabilities>
<Capability Name="internetClient" />
</Capabilities>
</Package>
The Identify in the Manifest is the important part (in the visual manifest editor this is the "Package Name"). Changing the Identity is sufficient to allow both versions to be installed. You can also change the Identity to something meaningful rather than a GUID.
As you note, Visual Studio will uninstall the old version it has staged for you, but you can create a deployment package and install it again yourself.
When you are ready to switch to a new baseline use the Project.Store.Create App Packages... menu to create a development test package (i.e. not to upload to the store).
Update your manifest to use the new Identity. Changing the display names is not technically necessary but will make things less confusing.
Building this will install the new version and remove the staged version.
Now install the development package you created: go to AppPackages folder and run the Add-AppDevPackage.ps1 for the older version you want to reinstall.
You will end up with a normally deployed (in Program Files\WindowsApps) developer package of the old version and a staged (in your VS project directory) package of the new version.
(Alternatively, you can shuffle the versions to rename the old version to indicate it's old, create an app package for the renamed version, re-rename the Identity back to the original, and then install the dev-package for the old renamed version).
Try this if it works... Worked for me
Run the baseline application
Create a new working folder (or branch if you are using a code repository like TFS)
Eg : VS 2013 -> Projects -> App 1 then create VS 2013 -> Projects -> App 1-Copy
Change the Package Name in Package.appxmanifest under packaging tab in the new working copy
something which will be unique like changing the last couple of digits (to make a distinction between both the apps you can change the display name under Application tab and package display name under Packaging Tab)
and run the new application
this will list both your baseline and your development version
Hope this helps
I am trying to deploy my web service on AppHarbor through GitHub. My web service is using NHibernate.Spatial, which has Microsoft.SQLServer.Types version 10.0.0.0 as a dependency. This assembly is, if I understand correctly, installed along with SQL Server 2008. When I run my web service on my development computer, on which I have SQL Server 2008 installed, the service runs without trouble, but when I deploy to AppHarbor I get the following exception:
"Could not load file or assembly 'Microsoft.SqlServer.Types,
Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or
one of its dependencies. The system cannot find the file specified."
As I already build my own version of NHibernate.Spatial.MsSql2008, the assembly from which the dependency derives, I have simply tried copying the required dll into the bin folder when building this project, by setting the reference property Copy Local to true. This is also reflected in the web service bin folder which is pulled by AppHarbor through Git. This didn't help though and my guess is that my web service is looking for the dependency in a different folder than bin.
How do I make the Microsoft.SqlServer.Types assembly available on AppHarbor? As the exception states, this might also be caused by possible missing dependencies of Microsoft.SqlServer.Types, but how do I find if this is the case, and again, how do I make the dependencies of Microsoft.SqlServer.Types available on AppHarbor?
Here's a NuGet package with the Microsoft.SqlServer.Types assembly. You can use this in combination with NuGet package restore on AppHarbor.
I have a closed-source project that I would like to build using Maven. It has a dependency on two java libraries which are not available in any public repository that I've been able to find (libGoogleAnalytics.jar and FlurryAgent.jar in this case, but the question applies to any closed-source dependency).
I would like anyone in my organization to be able to build the application using the exact same versions of the dependencies that I use to build the application. This includes my colleagues and our build-server.
How do I manage closed-source dependencies that maven doesn't know how to resolve?
Obviously, I could go to each person's machine and manually execute "mvn install:install-file" to get the binary into their maven repository, but manually managing dependencies like that defeats the purpose of a dependency manager.
As per maven's Internal Repositories documentation, I could set up a repository server somewhere and put the binaries there, which all the developers would then access. But that means I have a new server to maintain (or at least a new website on an existing server). It also means I have to worry about permissions to ensure that outside parties can't access the repository. It also means I have to worry about backups and availability now so that developers don't run into hiccoughs if the repository is unavailable.
All of these problems would go away for me if I could somehow use our existing scm (hg in this case, but it could be git or svn or whatever) to store the dependencies. Our source control repository is backed up already, it will basically always be available to developers doing builds, and its permissions have already been dealt with.
But I haven't been able to figure out how to manage maven dependencies using hg yet, if this is even possible.
It turns out that Manfred's answer didn't quite work for me. The app compiled, but it did not run on my Android device because the required google analytics classes were missing.
Following the links he supplied, I discovered this solution which is actually a little cleaner and worked properly.
In summary, I added the following dependencies to my pom.xml. The groupId, artifactId, and version were all made up by me using reasonable values:
<dependencies>
...
<dependency>
<groupId>com.google.android.apps.analytics</groupId>
<artifactId>libGoogleAnalytics</artifactId>
<version>1.1</version>
</dependency>
<dependency>
<groupId>com.flurry</groupId>
<artifactId>FlurryAgent</artifactId>
<version>1.24</version>
</dependency>
</dependencies>
I then added a repository definition for where I'm storing the third party dependencies in my project's source tree:
<repository>
<id>third.party.closed.source.repo</id>
<url>file://${basedir}/../maven_repo_3rd_party</url>
</repository>
I then moved the jar files to the following location:
./maven_repo_3rd_party/com/google/android/apps/analytics/libGoogleAnalytics/1.1/libGoogleAnalytics-1.1.jar
./maven_repo_3rd_party/com/flurry/FlurryAgent/1.24/FlurryAgent-1.24.jar
Once I did that, my project compiled and ran exactly as if the third party dependencies were resolved from an official maven repo.
While I really think you should use a dedicated repository server and Sean Patrick is totally right about it here is a hack to get it to work.
Put the jar file in a libs folder just like you did in the days gone by (remember Ant.. ouch) .. and then declare a dependency to each jar using the scope system and a path.
An example can I did this for is described here
http://www.simpligility.com/2010/01/how-to-mavenize-a-typical-web-application-build-jasperserver-3-7-sample-webapp/
Specifically a dependency would e.g. look like this
<dependency>
<groupId>jasperreports</groupId>
<artifactId>jasperreports-chart-themes</artifactId>
<version>3.7.0</version>
<scope>system</scope>
<systemPath>${project.basedir}/src/main/webapp/WEB-INF/lib/jasperreports-chart-themes-3.7.0.jar</systemPath>
</dependency
Oh and now that I told you how to do it keep in mind that this is BAD practice and has a bunch of issues but it will work...
Use A dedicated Repository Server
As per maven's Internal Repositories
documentation, I could set up a
repository server somewhere and put
the binaries there, which all the
developers would then access.
Exactly. Set up a maven repository server with several repositories, e.g. these:
internal-releases
internal-snapshots
external-opensource
external-closedsource (this is where the lib we are talking about goes)
But that means I have a new server to
maintain (or at least a new website on
an existing server). It also means I have
to worry about permissions to ensure that
outside parties can't access the repository.
Yes, but a company that does serious software development should have an infrastructure like that. But if your company is serious about using Maven, there should probably also be a dedicated position for configuration management, and that person should administer this server.
It also means I have to worry about
backups and availability now so that
developers don't run into hiccoughs if
the repository is unavailable.
The standard repository servers (e.g. Sonatype Nexus) are rock solid. If it ever hangs, just restart the app server / servlet container it's running on. Also, once developers have downloaded a library from the repo, it remains in the local repo, so even if the repo is down, there shouldn't be a problem (but you can't reference a new dependency when the server is down).
Use your existing SCM as a maven repository
OK, if you really want to use your SCM as a maven repo, here's how to do it:
http://maven-svn-wagon.googlecode.com/svn/site/index.html
This article describes how to setup an SVN-based maven repository for your own project. But if you want to deploy a third-party to the repo, just create a pom with the config mentioned here and use that pom to deploy:deploy-file your library.
(There are other wagon / scm implementations also, and the configuration is slightly different, but the solution remains the same: create a pom according to the wagon implementation you are using and then do deploy:deploy-file (see more info on the usage page)