I have created a web application project and deployed it to Azure.
In the web.config file for this application, a number of <assembly> elements appear in the <system.web><compilation> element. Specifically, these assembly entries point to DevExpress assemblies but they could really be anything.
I have also created a Web API project that is deployed as a virtual application under the web application. It looks like the <assembly> entries are being inherited from the configuration of the web application. The Web API project does not use these assemblies and throws an exception stating that they cannot be loaded.
As a temporary workaround, I have manually copied over the assemblies to the bin folder of the Web API application. However, this is not a permanent solution.
I have tried clearing the assembly entries in the Web API configuration (using the <clear /> element). I have also tried removing the entries (using the <remove> element). Neither of these worked.
What is the best way to stop this inheritance form occurring?
As mentioned in this official document about ASP.NET Configuration File Hierarchy and Inheritance:
ASP.NET application root directory > Web.config
The Web.config file for a specific ASP.NET application is located in the root directory of the application and contains settings that apply to the Web application and inherit downward through all of the sub directories in its branch.
ASP.NET application subdirectory > Web.config
The Web.config file for an application subdirectory contains settings that apply to this subdirectory and inherit downward through all of the subdirectories in its branch.
I assumed that you could leverage Location Settings to achieve your purpose. Also, there is a blog about Settings and Virtual Directory Inheritance, you could refer to it.
Related
The documentation states that I can configure the liferay server to use my own templates for the email messages. Specifically, if I add these properties to a portal-ext-env.properties in $CATALINA_BASE/conf/liferay:
blogs.email.entry.added.enabled=true
blogs.email.entry.added.subject=${resource:com/liferay/portlet/blogs/dependencies/email_entry_added_subject.tmpl}
blogs.email.entry.added.body=${resource:com/liferay/portlet/blogs/dependencies/email_entry_added_body.tmpl}
Liferay will supposedly use the templates in the specified paths (com/liferay/portlet/blogs/dependencies/email_entry_added_subject.tmpl and com/liferay/portlet/blogs/dependencies/email_entry_added_body.tmpl). The thing is, it's not very clear what these paths are relative to. Are these files relative to $CATALINA_BASE? For example, would the above configuration result in Liferay looking up $CATALINA_BASE/com/liferay/portlet/blogs/dependencies/email_entry_added_body.tmpl for creating the body of an email message? If this is not the case, where does Liferay lookup templates for Blog-related email messages?
After some digging, I've found that you place the templates in the $CATALINA_BASE/webapps/ROOT/WEB-INF/classes folder. Paths that you reference in the properties (e.g. blogs.email.entry.added.body=${resource:com/liferay/portlet/blogs/dependencies/email_entry_added_body.tmpl}) are relative to the aforementioned classes folder.
So, if I wanted Liferay to use a template file in the ff. relative path: org/foo/my_email_entry_added_body.tmpl, I would do two things:
Place the file in $CATALINA_BASE/webapps/ROOT/WEB-INF/classes/org/foo/my_email_entry_added_body.tmpl.
Add the following line to $CATALINA_BASE/portal-ext-env.properties: blogs.email.entry.added.body=${resource:org/foo/my_email_entry_added_body.tmpl}.
I consulted my co-worker and got a better understanding of why this is. The architecture of a Liferay application is such that it comes bundled with a Tomcat server. According to the documentation, WEB-INF/classes is a directory that a web app deployed to a Tomcat server looks up for classes and resources:
A class loader is created for each web application that is deployed in a single Tomcat instance. All unpacked classes and resources in the /WEB-INF/classes directory of your web application, plus classes and resources in JAR files under the /WEB-INF/lib directory of your web application, are made visible to this web application, but not to other ones.
Specifically, this folder is high in priorty in the web app's classpath.
When you see Liferay code similar to ${resource:path/to/foo}, it's looking up resources in its classpath. One of the paths in that classpath is WEB-INF/classes. Hence, if path/to/foo is placed in WEB-INF/classes, Liferay will find path/to/foo there.
I created my first openui5 hello world application on eclipse and want to deploy on my phoenix(elixir webserver) server.
Application structure:
And the app looks as follow:
My question is, how make the application ready to deploy?
Its all static content. Copy all files and folders inside Webcontent to your web server. You can put it to the web servers root, but you don't have to. WEB-INF and META-INF are not needed.
Then copy the openui5 framework to the Webserver to a folder of your choice. You may have to change the bootstrap element to point to your sap-ui-core.js.
That's it. Optionally You can use the grunt-openui5 plugin to build a packaged preload file of your application.
I've recently written my first grails application.
The application is a "product" in that I'd like to build a single version of the application that can be deployed to multiple customers as a war file.
I need to be able to configure each application differently.
What is the "best practice" for deploying a grails application as a product.
I found this documentation after some searching on the grails site.
3.4 Externalized Configuration
The default configuration file Config.groovy in grails-app/conf is fine in the majority of cases, but there may be circumstances where you want to maintain the configuration in a file outside the main application structure. For example if you are deploying to a WAR some administrators prefer the configuration of the application to be externalized to avoid having to re-package the WAR due to a change of configuration.
In order to support deployment scenarios such as these the configuration can be externalized. To do so you need to point Grails at the locations of the configuration files Grails should be using by adding a grails.config.locations setting in Config.groovy:
grails.config.locations = [ "classpath:${appName}-config.properties",
"classpath:${appName}-config.groovy",
"file:${userHome}/.grails/${appName}-config.properties",
"file:${userHome}/.grails/${appName}-config.groovy"]
In the above example we're loading configuration files (both Java properties files and ConfigSlurper configurations) from different places on the classpath and files located in USER_HOME.
Ultimately all configuration files get merged into the config property of the GrailsApplication object and are hence obtainable from there.
See the section on External configuration at this link. I'm not sure if this will configure everything you need but it should be a start and will cover the basics such as data sources.
I created a test project using a web.config file by renaming it to same name as the project, copying it to the bin folder and setting the Configuration File Name of the NUnit GUI runner to the name of my config file. Now I want to add more assemblies to this project but the problem here is each assembly has it's own web.config file.
How can I set the configuration files for the assemblies because I need to get my connection strings from these config files and considering when loading multiple assemblies they need to be in the same directory
While I feel that using config files for NUnit tests is a no-no (it's an integration test, in that case, I assume), there are various approaches you can try:
Put all your different connection strings under web.config in the connectionstrings section, with different keys. Access them via the System.Configuration classes.
For each project or DLL you can add an app.config file where you can store assembly specific information. This will be renamed as ProjectName.dll.config once compiled. Again you can access the contents of this file using System.Configuration
Create a new assembly that simply loads all these connection strings from a single file. And then access this assembly
If you are loading different web applications into the same directory (as you're saying you're accessing web.config files -- which means web applications) then you're making your life difficult. Each application has to have their own folder and virtual directory, and a web.config specific to only that application.
I would like to create a single .war that contains both a web based FORM login for a web GUI AND BASIC authentication (in this case, for a web service interface.)
/index.html (unsecured welcome page)
+---/interactive (folder containing web pages using auth-method=FORM)
+---/service (servlet mapping for web service using auth-method=BASIC)
I don't see a way to configure such a setup in the web.xml file. It appears that login-config can not appear inside a security-config and that it only allows a single auth-method globally for the .war.
The solution was to create two .war submodules and package them in an .ear file.