I am unable to get hot deployment of karaf feature to work in JBoss Fuse. I have the following feature XML descriptor in deploy directory, but it never gets picked up by Fuse and it never gets installed.
<?xml version="1.0" encoding="UTF-8"?>
<features name="IssSysIntRepo">
<feature name="sys-int" install="auto" version="1.0.0">
<bundle>file:/opt/sys-int.jar</bundle>
<feature>camel-jackson</feature>
<feature>camel-restlet</feature>
</feature>
</features>
If I manually add the repository by URL that leads to the file in deploy directory by features:addurl path/feature.xml and then install the feature by features:install sys-int it loads the feature successfully.
Logs on startup do not mention anything about the feature or an error, as I quickly looked over it.
Do you know where might be a problem?
I am using fresh install of jboss-fuse-karaf-full 6.2.0.redhat-099
Related
What could be a reason for not updated module version in Magnolia 5.7
In Magnolia java project I have submodule with XML descriptor in META-INF/magnolia/mymodule.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module SYSTEM "module.dtd" >
<module>
<name>mymodule</name>
<displayName>mymodule</displayName>
<description>my module</description>
<version>${project.version}</version>
<!-- <version>1.3</version> -->
<dependencies>
<dependency>
<name>core</name>
<version>5.7.4/*</version>
</dependency>
</dependencies>
</module>
When I rebuild the whole project with version changed in project maven pom.xml and deploy on a server I don't see an updated version in Magnolia's Author configuration console. I have to manually remove the old version node in the configuration console (remove JCR node) and then restart the server. After these steps, I can confirm the new version in the configuration console. Which is a pain if you have to deploy to several dev/stage/prod environments needless to say that I have no access to a public instance in a production environment.
The problem with not updated version sounds like not important, but I'm also not seeing new or renamed pages associated with this module. They appear only if I force to reload module by removing version.
One additional detail which may help identify the problem: I can delete version node in JCR, but can NOT delete the whole module node. I receive an error message "Level 1 and 2 nodes in config workspace cannot be unpublished".
What version do you see in the config:/modules/your_module/version before you delete it? Is it lower than version number of version you are trying to install? I would suspect that it's same or higher. Ie you are trying to reinstall same version or downgrade the version. Neither of those is supported hence it doesn't trigger the installation process. Or perhaps you are trying to move up from SNAPSHOT to full version for which there's no install delta either.
As for the warning you get when trying to delete those nodes, it is on purpose. You are not supposed to be deleting those nodes as a normal user since you could cause breakage of dependent (public) instances. Only as admin (via JCR Browser) you are allowed to delete, assuming you know what and why you are doing.
While building a solution cloned from a working repository, I'm getting the below error. Infact the url https://tc.xxx.yyy.intra/httpAuth/app/nuget/v1/FeedService.svc/ is correctly added as a package source in NuGet(according to Visual Studio).
https://tc.xxx.yyy.intra/httpAuth/app/nuget/v1/FeedService.svc/: Unable to load the service index for source https://tc.xxx.yyy.intra/httpAuth/app/nuget/v1/FeedService.svc/.
An error occurred while sending the request.
The remote name could not be resolved: 'tc.xxx.yyy.intra'
https://api.nuget.org/v3/index.json: Package 'ServiceLocatorAnalyzer.1.0.6533.24990' is not found on source 'https://api.nuget.org/v3/index.json'.
https://www.nuget.org/api/v2/: Package 'ServiceLocatorAnalyzer.1.0.6533.24990' is not found on source 'https://www.nuget.org/api/v2/'.
. Please see Error List window for detailed warnings and errors.
But, upon checking the NuGet.config file(below) in my AppData folder, I can see only 1 NuGet package source is added in it whereas according to VS there are 5:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>
</configuration>
Is this an expected behaviour?
I also deleted, the NuGet.config file; restarted my VS as someone mentioned here VS2015 nuget package manager not finding packages but it didn't work.
Any idea where I'm going wrong?
As specified in the how settings are applied documentation, many nuget.config files can be read. One of them is specifying the additional source.
If you download nuget.exe from nuget.org/downloads and use nuget restore, it should list all the nuget.config files that apply, although that might only happen if no fatal error occur (and I'm not sure if a source being unreachable is fatal). If so use dotnet new nugetconfig if you have the .NET Core SDK installed, as the nugetconfig template clears all other configs sources and adds only nuget.org. THen when you restore (use dotnet restore -v n if you have a .net core project because the default verbosity is minimal), all the nuget.config files will be listed, even if their sources are not.
Once you have the list of nuget.config files that were used in a restore, open them one by one until you find the one that defined the bad package source.
I'm setting up the spring webmvc project using spring boot 2.0.0 version. If i run the application inside the embedded tomcat, it runs fine. I tried deploying it in external standalone tomcat-8 server, it is working fine over there too. But i if package the war and deploy it in the tomcat-8 server configured within eclipse, then it throws below exception.
The absolute uri: http://tiles.apache.org/tags-tiles cannot be
resolved in either web.xml
I included the dependency in the pom file as below.
<dependency>
<groupId>org.apache.tiles</groupId>
<artifactId>tiles-jsp</artifactId>
<version>3.0.4</version>
</dependency>
I ensured that the tiles-jsp jar is present inside the WEB-INF/lib folder. But still its failing as it is not able to scan the jar for TLD. I tried changing the catalina.properties to include tiles-jsp*.jar. But it is still failing.
Please help me to fix this error.
Does your IDE automatically import dependencies?
Try cleaning your maven dependencies.
Maven clean.
Or try the more brutal command dependency:purge-local-repository.
By the way notice that there's a newer version of your dependency 3.0.8 of 2017. The one that you are trying to use, the 3.0.4, is of 2014.
For me, war file when deployed works perfect. Had an issue where, when I run it under tomcat from inside IDE(Eclipse/STS), it threw error. Maven clean really helped, no other change needed. MAven clean-->build--> restart eclipse/sts tomcat. it works like a charm. Answer by desoss prompted me to perform maven clean. Thanks #desoss.
I have an older extension that i would like to get to work in VS 2017. To be able to do this i understand that i will have to use the new VSIX Manifest v3. The extension works fine in 2015 Update 3. To update it I've done the following:
Open the extension source in VS2017. I'm prompted to do a one-time upgrade, which is completed successfully
Use NuGet to update the Microsot VSSDK BuildTools from 14.x to 15.x
Add the Prerequisite block to the source.extension.vsixmanifest file containing Microsoft.VisualStudio.Component.CoreEditor
Update the Installation target to also support the new Visual studio like so
<InstallationTarget Version="[15.0,16.0)" Id="Microsoft.VisualStudio.Enterprise" />
Builds successfully, but once i open the vsix file in my debug folder, get a message telling me
The file is not a valid VSIX package
If i open up the file using WinRAR i can see that the two mandatory files catalog.json and manifest.json is not in there as they are supposed to in the new v3 format.
What am i missing here ?
It turned out that my problem was, that inside the vbproj file (or csproj for most others) there was an import at the top like so:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="..\..\packages\Microsoft.VSSDK.BuildTools.15.1.192\build\Microsoft.VSSDK.BuildTools.props" Condition="Exists('..\..\packages\Microsoft.VSSDK.BuildTools.15.1.192\build\Microsoft.VSSDK.BuildTools.props')" />
<Import Project="..\packages\Microsoft.VSSDK.BuildTools.14.3.25407\build\Microsoft.VSSDK.BuildTools.props" Condition="Exists('..\packages\Microsoft.VSSDK.BuildTools.14.3.25407\build\Microsoft.VSSDK.BuildTools.props')" />
....
As you can see this project file has imports for both the new version and the old one of the BuildTools. I'm not sure why this happens, as all i did was update the VSSDK BuildTools via NuGet. I also tried to completely uninstall the BuildTools ticking Force uninstall but it seems to have remained through everything I tried.
So if you experience similar problems, look at your vbproj/csproj file if it has imports for older versions of the Microsoft.VSSDK.BuildTools
You must also upgrade the BuildTools package, the error you get indicate that this did not happen: https://learn.microsoft.com/en-us/visualstudio/extensibility/how-to-migrate-extensibility-projects-to-visual-studio-2017
I'm new to Wix and I have ran into a problem that I'm obviously not able to solve on my own, so any help will be very much appreciated.
Quick background:
I'm representing a software vendor building a comprehensive suite of SOA based applications for deployment in large enterprises. Our architecture consists of many layers which may be installed/upgraded independently, so I'm building several installers, composing from the ground up (like: platform, core framework components, service layer, business layer, application layer, etc.).
Software versions:
-Wix 3.5.1309.0 (wix.dll)
- Visual Studio 2008, .Net 3.5
- Build OS: Windows 2008 R2 Standard 64 bit
- Deploy OS: Windows 2008 Standard 32 bit
My problem is in regards to installing .Net assemblies in COM+ applications. I keep on getting the error "Could not install type library". I have been reading all the documentation that I can find, and I have been google'ing for several days now. I find quite a few posts on the topic, but I'm still not able to resolve the issue.
To isolate the problem I have extracted the issue into a separate installer. First I run the main installer:
1. Installs all assemblies into GAC, including the one to be installed in COM+.
2. Create local users and groups.
3. Create the target COM+ application, including roles etc.
4. Installs the target assembly, and the companion typelib, in a folder (to remove any GAC lookup issues)
This installer I can install/repair/uninstall, everything works fine.
Then I run the minimum installer containing only the issue, which tries to:
1. Install the assembly in an existing COM+ application (server), referencing the pre-installed .dll and .tlb.
The install fails, and the log is showing:
MSI (s) (AC:64) [19:16:01:127]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI1BAB.tmp, Entrypoint: ComPlusInstallExecute
ComPlusInstallExecute: ExceptionInfo: Code='0', Source='System.EnterpriseServices', Description='Could not install type library 'c:\Program Files\MyManufacturer\ComPlus\WDA.ServiceProviders.Update.11.tlb' into application 'WDA.ServiceProviders.Update.11'.', HelpFile='', HelpContext='0'
ComPlusInstallExecute: Error 0x80020009: Failed to invoke RegistrationHelper.InstallAssembly() method
ComPlusInstallExecute: Error 0x80020009: Failed to register .NET assembly
ComPlusInstallExecute: Error 0x80020009: Failed to register assembly, key: MyAssembly
ComPlusInstallExecute: Error 0x80020009: Failed to register assemblies
Action ended 19:16:02: InstallFinalize. Return value 3.
I also notice that the rollback removes the COM+ application, even though it was not created by this installer.
I can install the assembly manually, using the Server Manager, from the same physical file that the installer is referencing. After manually removing the component from the COM+ application, then the installer works!
Also, why do I have to supply a typelib in the first place? The EnterpriseServices.RegistrationHelper is generating the typelib on the fly anyway.
This is the minimum test installer that is failing:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:complus="http://schemas.microsoft.com/wix/ComPlusExtension"
>
<Product Id="48EDB258-BD84-47EF-94A2-B4950EE48139"
UpgradeCode="F29B8EBD-DFD1-4B7E-96FF-86842CAAE4A4"
Name="ComPlusInstalls"
Language="1033"
Version="1.0.0"
Manufacturer="MyManufacturer">
<Package Id="ABA41719-BC28-4A57-BA9A-58F4F3B2194F" InstallerVersion="200" Compressed="yes" />
<Media Id="1" Cabinet="WixTest.cab" EmbedCab="yes" />
<complus:ComPlusApplication Id="MyApplication" ApplicationId="1FCF220A-A1FE-44FE-BE91-B37341BA6D4A" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="MyManufacturer" Name="MyManufacturer">
<Directory Id="INSTALLLOCATION" Name="ComPlus">
<Component Id="MyComponent" Guid="6D46A007-6669-487B-BAA0-DFA7314C141D" KeyPath="yes">
<complus:ComPlusAssembly Id="MyAssembly" Type=".net" Application="MyApplication"
RegisterInCommit="no" DllPathFromGAC="no"
DllPath="[INSTALLLOCATION]WDA.ServiceProviders.Update.11.dll"
TlbPath="[INSTALLLOCATION]WDA.ServiceProviders.Update.11.tlb"/>
</Component>
</Directory>
</Directory>
</Directory>
</Directory>
<Feature Id="MainFeature" Title="WixTest" Level="1" Absent="disallow" InstallDefault="local">
<ComponentRef Id="MyComponent" />
</Feature>
</Product>
</Wix>
Cheers,
-Nils
I have the same problem. Ive tried Wix 3.5 and 3.6.2012.0 and it hasnt worked with either. It works if
I use regsvcs first
Delete the component
Run the msi and click on Ignore when a message comes up about the application already existing
Did you manage to find a solution?
First, you might try upgrading to the latest version of WiX v3.5. There were some bug fixes in COM+ at the end. If that doesn't work, take a look at the open bugs around COM+. There are a couple known issues with the installation code due to complexities in COM+.
If any of those bugs sound applicable maybe you can help fix them with the community?