We have created installer for our eclipse RCP Application using install4j. We have single installer with Version 'X'. We have mutliple server profiles to connect to with version 'X'.
We are taking below inputs from user during installation -
Installation Directory - <Installation_Path/AppName_ServerProfile_X
Server Profile to connect to - Server_Profile_X
However we are facing an issue during auto update mechanism -
Auto update fails to locate installation directory with server profile and again prompts for an input for installation directory and server profile to connect to during an auto update.
As per my understanding, this is because Application ID doesn't contain any information related to Server Profile.
How can we ensure that our server profile name is tagged with 'Application ID' somehow so that, it can detect installation directory with server profile automatically?
Below is snippet for update options -
Related
I downloaded Wildfly (wildfly-13.0.0.Final) and I want to configure it. I start standalone.bat in the bin folder of JBOSS_HOME directory (I use Windows platform).
I go to management console: localhost:8080 -> Administration Console. I see this
Your WildFly Application Server is running.
However you have not yet added any users to be able to access the admin console.
To add a new user execute the add-user.bat script within the bin folder of your WildFly installation and enter the requested information.
I run add-user.bat and it asks me what kind of user I would like to add.
I need a user to have permissions to deploy, redeploy applications. For example, for Apache Tomcat I can consifure tomcat-users.xml file and add users there (https://stackoverflow.com/a/1327730/4587961), so when I log into console as that user, I can deploy applications.
You need to add a Management user with the add-user.bat, whose credentials you will be able to log in the web admin with.
You could direclty add the user to the mgmt-users.properties file in the configuration directory of your standalone or domain, but the entry must be of the form <username>:DIGEST-MD5(<username>:ManagementRealm:<password>), which the add-user.bat script will handle for you.
You don't need any particular role unless you set up RoleBasedAccessControl.
Applicative users are used by applications with frameworks such as JAAS and are interfaced through the "default" security-domain, which refers to the ApplicationRealm containing those users.
As I read
https://docs.jboss.org/author/display/WFLY10/EJB+invocations+from+a+remote+server+instance
https://developer.jboss.org/thread/240892
Management user is used to enter the web console. Here you can deploy app, make settings, add resources (JPA config for example). Application users do not have access to the web console. They can be used for example to authenticate services. For example to invoke remove EJB bean, you need application user credentials to access the remove server.
I configured releases same way for a couple of our servers but I have issue with one of them (others work perfectly):
[error]Failed to deploy web package to IIS website.
[error]Error: C:\vstsagent\A2_work_tasks\IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba\0.0.20\MSDeploy3.6\msdeploy.exe failed with return code: 2148734720
Unfortunately I can't find anything helpful related to this error Code.
My release configuration:
IIS Web App Deploy (Preview)
Deployment group with one specific staging server (I'm using on-premise agent)
Website name: correct name of my website in IIS
Virtual Application: empty field
Package of Folder: zip chosen from build drop artifacts
Selected "XML variable substitution"
Selected "Remove Additional Files at Destination"
What I've already tried with no luck:
manually turn of application
delete all files in application folder
changing user account to use for the service
Again - same configuration for other servers works fine.
Servers configuration: Windows Server 2012R2 Standard x64
Looks like I figured it out. .NET Framework 3.5 was missing on my server...
I was investigating logs and I found out that below line is causing failure.
"C:\vstsagent\A2\_work\_tasks\IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba\0.0.20\MSDeploy3.6\msdeploy.exe" -verb:sync -source:package='C:\vstsagent\A2\_work\r2\a\temp_web_package_8269135298977384.zip' -dest:auto -setParam:name='IIS Web Application Name',value='httproot'
So I copied it to CMD and got proper Windows message when I tried to execute it.
I am facing the puzzling fact that the information of update sites fail to be updated despite my forcing a reload in Preferences > Install/Updates > Available Software Sites.
I have a local update site (file:/ protocol, on Windows) and an online update site (https://) that I use as staging/test update sites for an open source project that I am maintaining.
I build the update site using an update site project that is stored locally and wiped clean each time I build it. When I have tested the new release in a different Eclipse instance and I have validated my changes, I then upload the entire update site to my server. Then, just to simulate what a user would do, I update the plugin in another Eclipse instance that runs on a different physical machine.
I have (yesterday) built another version, 2.2.0.201702052007 and uploaded it to my server. The previous version was 2.2.0.201702042059.
The problem that I have is that the Eclipse instances (Mars.2 and Neon) on my development machine keep reporting the previous to last version, despite my reloading the update site information. However, the other machine sees the new version without a problem.
This is what I've tried:
Reloading the information of the update site: each time, I get a confirmation message saying "information for [...] has been reloaded from the server" but it turns out that it hasn't been reloaded: I see the older feature version.
Accessing the update site from a different Eclipse instance on a different machine: I see the new version.
Loading the update site's site.xml file from a browser: I see the new version.
Using FileZilla to download the entire update site to a local folder and unzipping content.jar and artifacts.jar so that I can read the XML files embedded in those JAR files: I see no trace of the older version.
Removing the update site, restarting Eclipse and adding the update site again: the problem was still there.
As a last resort, I removed all files of the update site from the server: Eclipse still reported successfully reloading the information from the server.
I shut down the httpd service on the VPS. Eclipse reported success until I restarted it and it then failed. But once the web server was again online, it failed to actually send a request to the web server as it kept saying there was no update site! As a consequence, the online update site now appears empty and restarting Eclipse does not change that.
[EDIT] Even more incomprehensible, the Reload button reports success even when there's no network connection to the update site (network interface disabled).[/EDIT]
There seems to be in the provisioning framework a cache somewhere between the UI and my server that reports an outdated information and feature version in spite of the explicit requests to reload that very information.
Is there any file or folder that I can delete to have the provisioning framework reset itself? If possible, I would altogether disable its cache.
I've found out that Oomph apparently has an action on the update site information retrieval process.
Anyway, I could recover normal operation (for now) and have the information properly reloaded by first deleting the appropriate files in C:\Users\...\.eclipse\org.eclipse.oomph.p2\cache.
By “the appropriate files”, I am referring to the fact that files in that folder are named after the URLs of repositories known to your Eclipse instances.
We have a MobileFirst application that worked with Worklight 6.2 server - production also. We are using a http adapter: <connectionPolicy xsi:type="http:HTTPConnectionPolicyType">
Currently we are changing the production server to 7.0.0. On Development Server we could test our application and all the functionalities were OK. We'we created the .war with the production server on build configuration and uploaded together with the android .wlapp . Now we receive 404 when the application tries to call any adapter function on production server. invokeProcedure onFailure returns UNEXPECTED_ERROR. This is with:
Server version: 7.0.0.00.20150312-0731
Project WAR version: 7.0.0.00.20150402-2001
Adapter name: XXXXX. Version: 7.0.0.00.20150402-2001
Application: XXXXX-android-0.9.7, Version: 7.0.0.00.20150402-2001
We have no security enabled in the application.
Is there something that must be enabled on Server in order to allow old type adapters call?
When we've tested with upgraded MobileFirst Development Studio 7.0.0.00.20150430 as development platform - same server version, and we got same 404 (Context not found), but there tries to connect with authorization/v1/clients/instance instead of /apps/services/api/XXXXX/android/query
Should a Server upgrade solve this problem? We've noticed that there are updates available.
The Server is on a https connection, but was same on WL 6.2.
By the description in the comments and the supplied messages.log, it is clear that you are attempting to use Application Authenticity Protection.
This feature worked in a certain way in v6.2 and it works in a different way in v6.3 and above.
From the comments it appears you are only adding the publickSigningKey - this is no longer enough.
See the updated Application Authenticity Protection tutorial for steps to follow: https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-7-0/authentication-security/application-authenticity-protection/
General steps to follow:
Setup authenticationConfig.xml with the security test
Add the security test to the environment node in application-descriptor.xml
Add the publicSigningKey to the <publicSigningKey> element
Add the application package name <packageName> element
I believe you are missing step 4.
Note that you also able to now enable the Extended Authenticity mode; follow the instructions in the tutorial.
Note about step 3: obviously the same keystore used to generate the publicSigningKey must be used when you export the signed .apk file... otherwise there will be a mismatch and the authenticity challenge will fail.
In your authenticationConfig.xml, make sure you have the securityTest available (= not commented out like in the file you've supplied in the comments below.
In your application-descriptor.xml, you are missing the securityTest attribute in the Android environment element: <android version="0.9.9"> change to <android version="0.9.9" securityTest="customTests">
I Try to deploy a application using Microsoft Release Management for Visual Studio or better known as "InRelease". But i face unexpected Problems using the MSI-Deployer.
The deployment fails with the flowing error:
Setup.msi XXX139W8 10/1/2014 11:19:18 AM 00:00:00 Package location '\\Server\drop\Application\Build_20140930.5\Setup.msi' does not exist or Deployer user does not have access. Failed
First suggestion(incorrect Path) is not the case, i double checked that.
So why does my Deployer user not have access to my server? And how to fix that?
I tried out running the DeploymentAgent as Administrator, as Local Service adding XXX139W8$ permissions to the drop folder, running as domain user with admin rights on the drop folder.
Sadly the deployment agent is totally unreachable or the error mentioned above shows up.
Here are some system specs:
TFS and RM Server run on a Windows Server 2012 R2 with SQL Server Express 2012 Installed.
The client i am Working on uses the Release Management Client for Microsoft Visual Studio 2013
The Target Machine is a Windows 8.1.
The deployer user is defined in the MS Deployment Service, ensure that this account has access to your Drop folder. I give the domain\EVERYONE account read access to the drop folder so that anyone can read the data
I resolved this Problem.
The cause was that i specified a File as Package (quite confusing if you try to deploy a single msi file) but the Component should only specify a Folder "Package".
The deployment agent fails to access the Folder (Setup.msi) and fails with the error i showed above.
Then i wasted hours in trying to fix my access problem, because if i enter the "Package location" everything worked fine._.