I am using a WebSphere Portal Server that runs some servlets as well. Previously, while I was using eclipse to develop I used this solution to add roles in my web.xml file and map them in the integrated solutions console in the menu Applications > Application Types > Enterprise Applications > NAME_OF_APP > Security role to user/group mapping > Map users/groups. But now I am using the Rapid Application Developer and I can deploy directly through it. Unfortunately I can't use the the console anymore to create role mappings (as explained here by TroyBishop in the second post nicely).
All over the internet people say, that I can create the role mappings using the file META-INF/ibm-application-bnd.xml / META-INF/ibm-application-bnd.xmi, but nobody seems to care about saying why that file is sometimes called .xmi and sometimes called .xml. Is this irrelevant or treated differently? And HOW the hack do I actually use the file? What's the format??
EDIT: And what about the ibm-web-bnd.xmi? Does that have to do with it as well?
Go to server view in RAD, double click WebSphere to open its overview, uncheck "Minimize application files copied to the server". Save it. Remove and add again the application so changes take effect. That should solve all missing "OK/Apply/Save" buttons.
The XMI files were meant for tools (and not for humans). XML files on the other hand were targetted.
For a long long time, till WAS V7, if i recall correctly, IBM used only the xmi files. It is with the advent of Java EE 5 that all the DDs were using XML instead of xmi.
Both the bnd and ext files used to use the XMI (XML Meta data interchange format). These are the IBM specific DDs.
Details about difference between xmi and xml binding files (from the Infocenter)
For IBM® extension and binding files, the .xmi or .xml file name
extension is different depending on whether you are using a pre-Java
EE 5 application or module or a Java EE 5 or later application or
module. An IBM extension or binding file is named ibm--ext.xmi or
ibm--bnd.xmi where * is the type of extension or binding file such as
app, application, ejb-jar, or web. The following conditions apply:
For an application or module that uses a Java EE version prior to version 5, the file extension must be .xmi.
For an application or module that uses Java EE 5 or later, the file extension must be .xml. If .xmi files are included with the
application or module, the product ignores the .xmi files.
To generate these files:
If you have RAD - then select the project (Web, EJB), right click, then select Java EE > Generate WebSphere Binding/Extension Deployment Descriptor. If you don't see that option ensure that in project properties, Project Facets - you have WebSphere Coexistence/Extended facet enabled.
If you use Eclipse - install WebSphere Developer Tools, which will enable same option
To edit bindings via console you have to change default publishing configuration in RAD as described in the Rafael answer.
Related
There's one thing I never understood after so many years of using Spring IDE and Spring Tool Suite (STS).
I'm using XML configuration files. One file (say "applicationContext.xml") imports other XML files, through the use of:
<import resource="classpath:path/to/otherContextFile.xml" />
In my Eclipse project properties, under Spring | Beans Support, the option "Enable support for <import/> element in configuration files" is enabled.
In the same project properties page, if the list of the configuration files only contains applicationContext.xml, STS is nevertheless able to detect the contents of otherContextFile.xml and parses it correctly.
However, what I see is that if STS performs an autodetection of configuration files, it always adds to that list otherContextFile.xml as well. But adding all the imported configuration files to that list sounds like the option "Enable support for <import/> element in configuration files" is then useless to me. Since I like to keep my project setup clean and tidy, when this happens I usually remove the imported files from that list.
However, every now and then, the automatic scan is triggered (maybe on STS upgrade or I don't know...) and those files are re-added. This makes me think that it might be a better choice to keep them listed anyway...
So, the question is: what is more correct, elegant and efficient (from a performance point of view)? Just list the "root" configuration files or all of them (even the imported ones)? And if the answer is the latter, what's then the point of that option "Enable support for <import/> element in configuration files"?
The main purpose of the "Enable support for <import/> element in configuration files" is exactly what you are using it for and what you describe at the beginning of your question. Therefore I think you are using it in the "right" way (from the STS tooling perspective).
The automatic scan should not add those imported files to the list of used Spring config files in the project properties. It does that for specific files only, like Spring Boot application main classes or files that are listed in the web app. I have no idea at the moment why those imported files are added to that list every once in a while. This could be a bug or could be caused because the mechanism finds those files being used somewhere else.
I would love to take a more detailed look, so it would be great if you could create a small sample app that reproduces this behavior and create a GitHub issue for this problem at: https://github.com/spring-projects/spring-ide/issues. Please attach the sample project and a few steps how to reproduce the issue.
In addition to that you can disable the "automatic scanning" per project or for your entire workspace (to quickly get rid of this behavior). You can deactivate specific automatic configs via the project properties (the third tab, next to the list of config files). The "global" disable can be activated in the general "Preferences -> Spring -> Beans Support" and then "Disable Auto Config Detection".
Hope this helps!!!
I am writting application in fasm and have problem with determinating Windows version 8.1 and upper. Functions GetVersionEx and Version Helper give me Windows 8. As MSDN says, I must target my application via changing manifest file in Visual Studio, but I'm not using VS, so what should I do?
Any programming environment that allows you to link resources into the compiled executable can be used to create a manifest resource. All you have to do is write a suitable .manifest file for your app that contains the desired XML values, and then link that file's content directly into your application's resources, making sure the resource type is 24 and the resource ID is 1, 2, or 3 (see this page for details about when to use which ID). You are not required to use VisualStudio for this.
If, for some reason, you cannot link the manifest directly into your app's resources, you can alternatively save the XML into a file named <myappname>.exe.manifest (where <myappname> is the actual name of your EXE file) and put it in the same folder as your app. This is not the preferred approach to manifestation, but it does work.
That being said, there are alternative APIs you can use instead of GetVersion/Ex() or VerifyVersionInfo()-based helpers to get the correct OS version without dealing with manifestation at all. Namely, RtlGetVersion(), NetServerGetInfo(), and NetWkstaGetInfo() can be used instead (and all of them have been tested as working in Windows 8.1 and 10).
The manifest file is XML file embedded as Win32 resource. It can also be external file with the name your.exe.manifest. Search for examples in internet for sample contents.
I'm currently implementing a vsix extension tool window which will soon need a database connection string for querying some data to display to the developer in the tool window. I'd like to make this connection string configurable by the developer. As the developer is unlikely to change the config settings often a file would be sufficient.
Is it possible to just use an app.config file in the same folder as the sln file and if so must I use some custom configuration settings to wrap the file? NuGet seems to implement this approach but I don't fully understand the internal architecture to see how the config file is used.
I'd appreciate any alternative approaches too.
Edit:
I have since realised that the dynamic data the config store would serve must be solution specific so that a tool window used in one solution can use different properties to that of another solution. I guess one possibility would be to use the .settings file to store the location of a single config file that itself stores information related to different solutions.
The best place to store settings for a .vsix extension is to use a .settings file. In order to create one do the following
Right Click on the project and select "Properties"
Go to the Settings Tab
Click on the link to create a default settings file
This will create a couple of files in your solution.
Settings.settings
Settings.Designer.cs
Additionally it will bring up a designer from which new settings can be added. These can be accessed afterwards by using the Settings.Default static property
Been there and in my opinion the built-in mechanism works best, detailed walkthrough: http://msdn.microsoft.com/en-us/library/ff460144.aspx
Adding a note from self I can see that the underlying implementation uses system registry subkey. However after VSIX extension uninstalled all the keys are removed automatically so your extension is not polluting the system leaving orphaned entries.
Background: We have a ClickOnce-deployed WPF app, that talks to WCF Services, which in turn both talk to our own SQL database and also to SharePoint via the Client OM. To set up the WCF and the ClickOnce, we have a Setup project, which takes in details about server paths and database connection strings from the installing user and fires an Installer class to do fun stuff like writing config XML and updating the ClickOnce strapper for that deployment URL and such.
We need to add some BDC Models to SharePoint via this installer, so that end users can use SharePoint list interfaces to configure some of the rarely-changed table values in our database. (As "one-click" an install process as possible is a requirement being imposed by the client.)
Including a BDC Model project in our Visual Studio 2010 solution, we can get a packaged WSP for our BDC stuff, which sounds great...
One problem with this, however, is that in the feature.xml that gets packaged into this WSP, this hard-coded line appears:
<Property Key="SiteUrl"
Value="http://BuildingWorkstationSharePointInstanceUrl/" />
Visual Studio won't build with the feature SiteUrl set to anything other than a SharePoint instance local to the machine (which is pretty lame), so we can't change that pre-WSP.
Furthermore, the .bdcm files themselves have hard-coded connection string information:
<LobSystemInstance Name="DatabaseName">
<Properties>
<Property Name="AuthenticationMode" Type="System.String">PassThrough</Property>
<Property Name="DatabaseAccessProvider" Type="System.String">SqlServer</Property>
<Property Name="RdbConnection Data Source" Type="System.String">DatabaseServer</Property>
<Property Name="RdbConnection Initial Catalog" Type="System.String">DatabaseName</Property>
<Property Name="RdbConnection Integrated Security" Type="System.String">SSPI</Property>
<Property Name="RdbConnection Pooling" Type="System.String">True</Property>
<Property Name="ShowInSearchUI" Type="System.String" />
</Properties>
</LobSystemInstance>
This would also have to be re-written by the installer once the installing user has provided the database connection information.
I'm also not sure what the best approach will be for actually installing the WSP on the server via the MSI (trying to execute a powershell script is all I've thought of so far).
It seems to me like designing BDC models for a third party shouldn't be that obscure of a scenario, but I can't find any information or support on how to overcome any of these problems!
Anyone have any advice?
I ran into this issue as well. I'd like to package our BDC model into a WSP and deploy it via the WSP. Unfortunately (like you've indicated) the BDC model contains specific environment information that must be configured per environment.
What we've landed on is keeping the different BDC models and just importing them instead of packaging them in a WSP. From the sounds of it, you may need to ask for the specific environment information at the time of install and somehow use that.
Two methods you could employ:
If you're using a "Custom" assembly type (instead of a DotNetAssembly as your LobSystem Type),
you can implement IAdministrable to allow you to change properties (either the LobSystem or LobSystemInstance) in the Central Admin. It doesn't seem to work for DotNetAssemblies, even if IAdministrable is implemented.
Alternatively, you can change properties by importing Resource Files. Easiest way to do this is to import your model, then export it as a Resource file and edit the file down to the properties you need changed. Then import the bdcr (resource) file and you'll see an indication that the properties had been changed.
Advanced Installer offers some support for this. Basically, through its XML editor you can use Windows Installer properties instead of hard-coded values in your manifest files.
The other solution I can think of is to use a custom action to modify the files after install.
Either way, this requires a complex installer, like an MSI package. ClickOnce doesn't support it.
If you want to deploy your BDC to a specific siteURL when you deploy it, go to your project folder for your bcd model when you view your solution and in the properties of the folder you should see something called "Feature Properties".
Click on the elipsis to expand the properties and add a heading called "SiteUrl" and set it to be the root of the site you want to deploy it too: i.e "http://spsite".
It will be deployed to that site instead of the Local one.
In our case, we implemented a custom Feature Receiver using instructions located at SharePoint 2010, deploying a BCS Model using a farm property bag to have a dynamic siteurl
It allows to deploy in any environment because the Site Url is discovered during the feature activation.
How to create installer for web application to run on both Windows and Linux? I need no more than extact some jar, jsp and xml files into a chosen directory. (Web server and database should be already installed, when our app is installed)
There can be two output files - one for Windows, one for Linux.
http://izpack.org/ is a fully-fledged cross-platform java installer-generator, and it's awesome.
But I'm not sure you need that exactly ..
I think, maybe, you just want a .war file? (i.e. a web application archive)
Here's an old article about war files:
http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/WCC3.html
Our product, BitRock InstallBuilder is a multiplatform installer that can do what you want. It is commercial but we have discounts for small companies and free licenses for open source projects. For example of web applications packaged with BitRock, check Bitnami