Remark: I do have searched for similar questions but found no solution that worked, hence I dare to ask this again. Please bare with me!
I am using Eclipse (Version: 2022-12 (4.26.0) / Build id: 20221201-1913 which includes WTP) to work on a Maven project. I am trying to deploy from Eclipse directly to a local Tomcat 8.5 server.
What is currently blocking me is that some of my application's resource files (like application.properties and logback.xml) contain place-holders and obviously these are not "filtered" when Eclipse/WTP deploys them to the wtpwebapps-folder before starting Tomcat.
When I run the build in Maven on the command-line then the resource files are all properly filtered (i.e. all properties defined in my settings.xml file or in the pom.xml do get properly replaced in the copy of these resource files that gets placed in the target-folder and which are then wrapped up into a .war file).
So, deploying that .war file to Tomcat works but starting it directly from Eclipse would be so much easier and quicker.
However, when I build this project in Eclipse then the files that get "published" to
<workspace>/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/<project_name>/WEB-INF before it starts Tomcat still contain the original placeholders which then causes the application to crash during startup. :-(
I do have the resource folder defined in the pom.xml (this was one suggestion that I had found) as:
<resources>
<resource>
<directory>src/main/resources</directory>
</resource>
</resources>
but this had no effect on the filtering for Eclipse/WTP.
I also tried to enable the maven-war-plugin's explode-goal in M2E's lifecycle mapping because the war-plugin's config contains a corresponding "filtering"-config:
...
<resource>
<directory>${basedir}/src/main/resources</directory>
<filtering>true</filtering>
<targetPath>WEB-INF/classes</targetPath>
</resource>
...
but with no effect, either.
Any other idea, hint or suggestion to convince Eclipse/WTP to "filter" these resource files before starting Tomcat?
Related
Good day,
Can someone help me please,
I am using WAS 8.5 to deploy ear files, once the ear file is deployed, I am not able to register the ear file on Liferay,
Did anyone experience this issues before,
Please advice.
Your portlet .war file probably didn't go through Liferay auto deploy process. Before the portlet is deployed to WebSphere, Liferay needs to manipulate the .war file and add its custom configuration and libraries. Without the auto deployment, the application is invisible to Liferay.
Does the portlet .war contain util-java.jar library (+ util-bridges.jar, + util-taglib.jar in /WEB-INF/lib folder)? If not, it was not auto deployed.
The auto deployment is configured using these properties in portal-ext.properties file.
#
# Set this to true to enable auto deploy of layout templates, portlets, and
# themes.
#
auto.deploy.enabled=true
#
# Set the directory to scan for layout templates, portlets, and themes to
# auto deploy.
#
auto.deploy.deploy.dir=${liferay.home}/deploy
#
# Set the directory where auto deployed WARs are copied to. The application
# server or servlet container must know to listen on that directory.
# Different containers have different hot deploy paths. For example, Tomcat
# listens on "${catalina.base}/webapps" whereas JBoss listens on
# "${jboss.home.dir}/deploy". Set a blank directory to automatically use the
# application server specific directory.
#
auto.deploy.websphere.dest.dir=${env.USER_INSTALL_ROOT}/wsadmin-deploy
Plus other configuration options.
What you need to do:
Copy the .war file into auto.deploy.deploy.dir.
Take the modifed .war file from auto.deploy.websphere.dest.dir.
Now you can deploy the modified .war to WebSphere application server.
If you build with Maven...
If you build with Maven, you can automate the auto deployment with the help of liferay-maven-plugin.
Sample configuration:
<plugin>
<groupId>com.liferay.maven.plugins</groupId>
<artifactId>liferay-maven-plugin</artifactId>
<version>6.2.10.11</version>
<executions>
<execution>
<id>pre-deploy</id>
<phase>package</phase>
<goals>
<goal>direct-deploy</goal>
</goals>
<configuration>
<appServerDeployDir><<LR will save the modified .war to this folder>></appServerDeployDir>
<appServerType>websphere</appServerType>
<liferayVersion>6.2.10.11</liferayVersion>
</configuration>
</execution>
</executions>
</plugin>
The plugin executes Liferay and can be further configured through src/main/resources/portal-ext.properties file.
My common configuration:
auto.deploy.copy.commons.logging = false
auto.deploy.copy.log4j = false
auto.deploy.websphere.wsadmin.app.manager.query =
I have an executable that I want to be deployed together with my Azure web role. The executable has a configuration file that needs to be included as well.
I tried adding a reference to the executable's project in my web role project, which made the exe file appear in the bin folder of the cspkg, but not the configuration file.
How can I get the configuration file to be included as well?
It seems wrong to include it directly as a content file in the web role project because this file is a build artifact (app.config gets renamed to .config.exe during build).
Thanks!
In an early SDK they added the concept of Role Content folders, or folders you could point to in the service definition file and say anything in this folder, add it to the package and deploy it with the role. If you look at the schema for the Service Definition you'll see these listed on the both the web and worker roles schemas. You can manually add this and point to any location on the local system and anything in that directory will be picked up and included.
<WebRole name="SimpleWeb" vmsize="Small">
...
<Contents>
<Content destination="ConsoleApp">
<SourceDirectory path="c:\src\SimpleWebContent\ConsoleApp\BuildOutput" />
</Content>
</Contents>
</WebRole>
For example, you could point to the output directory of the build for your executable so that anything that is generated by your build for that executable would be included. You can set the destination directory in relation to the app root, but the tricky part is the source directory. Note in my example above the full path is provided. The documentation says that you can use a relative path, but I tried many combinations and the behavior seemed very quirky. The complete path does work.
The VS SDK tools didn't expose this until SDK 1.7 and it's still not very good. Phil Hoff did a blog post on it called "Add Files to your Windows Azure Package using Role Content Folders". Note that when you use this method of adding the files you won't see the content elements appear in your service definition. They get auto injected at package time. If you are doing this as part of a build process that may not happen since VS tooling is doing the injection, but to be fair I didn't try calling cspack directly to see if having the content elements included in the service definition file actually packaged those or not. Also, I found that just adding a new folder and just having files under that folder didn't seem to work. I had to actually add the files by name there, which seemed wrong. I did hack the .ccproj file to use a wildcard on the folder include, which did work, but also seemed like a hack to me.
I have a web role in which I have extended the RoleEntryPoint to do some work that is outside of the scope of the web site. As part of the RoleEntryPoint.Run() my code is required to read from the .config using ConfigurationManager.
While this is a little unusual, using SDK 1.8 I was able to make this work by ensuring that my package included a [The name of my project].dll.config file.
Now that I have upgraded to SDK 2.2 when I try to use .AppSettings or .GetSection() the values are always null, which leads me to believe it is unable to find my file.
I have tried deploying a Worker Role and the .config file still follows the same name pattern that I'm currently using.
I have also tried naming the file WaIISHost.exe.config.
I am aware that ideally this configuration should be included in the .csfg file, but my questions is does anyone know what I should be calling my config file?
UPDATE:
With the help of this question, I now know that the name of the config file it is reading from is E:\base\x64\WaIISHost.exe.Config, but I don't know why this has changed or what I can to overide this.
After much investigation and trial an error I finally have a solution.
The name of the file is still required to be [The name of my project].dll.config, but you need to make sure that this file is in your approot\bin\ directory of your package.
I believe my initial problem was caused by the Copy to Output Directory property being changed to Do Not Copy, although I'm unsure how this happened. If you find yourself in a similar situation you can just add a file with the correct name to your project and set the Copy to Output Directory to be Copy Always.
Once I'd done that however I realised I had another problem. I needed the .config file to have had the config transformations run over it, which this didn't do. To fix this I updated the .ccproj file to have the following:
<PropertyGroup>
<!-- The first two of these targets are what is defined in the base SDK 2.2 targets file. When we upgrade we may need to look reassess this. -->
<CopyRoleFilesDependsOn>
CopyWebRoleFiles;
CopyWorkerRoleFiles;
CopyWebConfigToBin;
</CopyRoleFilesDependsOn>
</PropertyGroup>
<Target Name="CopyWebConfigToBin">
<!-- We need to copy the transformed Web.config to the bin directory so that the RoleEntryPoint has access to the config settings.-->
<Message Text="Copy %(WebRoleReferences.OutputDir)Web.config tp %(WebRoleReferences.OutputDir)\bin\BackOffice.UI.dll.config" Importance="high" />
<Copy SourceFiles="%(WebRoleReferences.OutputDir)Web.config" DestinationFiles="%(WebRoleReferences.OutputDir)bin\[Name of project].dll.config" />
</Target>
This adds an extra target which waits until all of the other files have been copied to the appropriate directory and then picks up the web.config and puts a copy in the bin directory with the correct name.
Are you able to put the config values into the Azure config file (the .cscfg) rather than using the .config file? You can read the values from the cscfg via the RoleEnvironment.GetConfigurationSettingValue static method.
This page explained why it's called WaIISHost.exe.Config and where you can put it in your project.
http://azure.microsoft.com/blog/2010/12/02/new-full-iis-capabilities-differences-from-hosted-web-core/
Like knightpfhor mentioned, you can also use [AssemblyName].dll.config to put these configuration too. It depends on the assembly name of your project, you can check property of your web role project.
I have the following in the theme but I want to make it server independent so that it can be moved seemlessly from deve to test to prod.
how do I genericize http://www.devserver.com?
<resource>
<content-type>text/css</content-type>
<href>http://www.devserver.com/CommonElements.nsf/commonMAX.css</href>
</resource>
I would assume the following - but doesn't work as it makes the reference relative to the current .nsf
<resource>
<content-type>text/css</content-type>
<href>/CommonElements.nsf/commonMAX.css</href>
</resource>
From an article on the Notes & Domino App Dev wiki:
"When the XPages runtime emits a URL, it assumes that the root "/" is the root of the application (e.g. /mydb.nsf). But as this notion doesn't exist in the browser, this is added by the JSF runtime. To work around this add the syntax "/.ibmxspres/domino" to the beginning of the path to set the root as the Domino data directory."
In Chapter 14 of Mastering XPages there is a discussion of Themes. Beginning on page 597 there is a discussion of "Resource Paths" and the Path Aliases for three key paths:
/.ibmxspres/domino points to: /data/domino/html/
/.ibmxspres/global points to: /data/domino/java/xsp/
/.ibmxspres/dojoroot points to: /data/domino/js/dojo-1.4.3/ (or the current version of dojo)
So your block is:
<resource>
<content-type>text/css</content-type>
<href>/.ibmxspres/domino/CommonElements.nsf/commonMAX.css</href>
</resource>
Happy coding
/Newbs
Another option is to investigate the XSP Starter Kit on OpenNTF.org
This will allow you to build an OSGi plugin library for XPages and one of the starter examples that you can extend in the library shows you how to create your own resourceProvider service.
Depending on how you refactor the XSP Starter Kit to your own name space you would be able add your css and other files ( common icons, logos etc ) and then you can access them using your own file path of /.ibmxspres/.yourNameSpace/file.ext. You can even build your own directory structure in the library to make managing the files easier.
One big advantage of this over storing them in a NSF is that they are cached by the end users browser whereas files served via nsf are not always cached.
Also, if the library is set as a global library on the server then you don;t need to add a dependency to the calling application, the resource provider will be available for anything that needs it.
This works if your application is in root.
./commonMAX.css
CruiseControl.net creates (by default) for each project a subdirectory under: c:\Program File\CruiseControl.NET\server
How can I change that? (it's such a bad idea to mix data with program files...)
I found a way to configure the artifacts directory per project, but that's not quite it (it's merely a subdirectory of the project directory).
Set the project's working and artifact directory and you're done. They default to:
[ccnet-install-dir]\[project-name]\WorkingDirectory
[ccnet-install-dir]\[project-name]\Artifacts.
If you e.g. set these directories to...
[projects-dir]\[project-name]\WorkingDirectory
[projects-dir]\[project-name]\Artifacts
... you can safely remove the [ccnet-install-dir]\[project-name] subtree (You will loose your project build history then).
So your configuration will look like this:
<project name="foo">
[...]
<workingDirectory>C:\projects\foo\WorkingDirectory</workingDirectory>
<artifactDirectory>C:\projects\foo\Artifacts</artifactDirectory>
[...]
</project>
I have CC.NEt not installed here, and I have atm no access to my build-server at work, but if I remember well, you should find 2 configuration files in your c:\Program Files\CruiseControl.NET folder.
ccnet.exe.config and ccservice.exe.config.
The first configuration file is used when you run CC.NET using the console app, the second one is used when you start CC.NET as a service.
In those files, you should find a configuration-setting which points to the location where the configuration-file(s) that describe the build-process for your projects can be found.
edit:
In the ccservice.exe.config file, you'll find a key in the appSettings section which is called ccnet.config. Change the value of this key to the path where you want to put the ccnet.config file.
If this key is not present, you can add it:
<appSettings>
<!-- Without this appSetting ccservice will look for ccnet.config in its own directory. -->
<add key="ccnet.config" value="D:\CCNetConfigFiles\ccnet.config"/>
</appSettings>
This is how I've done it:
I've changed the ccnet.config appSetting in the ccservice.exe.config file, so that CruiseControl.NET searches for the ccnet.config file in a different location instead of the standard location. (As described above). (I understand that you do not want to do this ?)
I've changed the ccnet.config file itself, so that it looks like this:
<!DOCTYPE cruisecontrol [
<!ENTITY project1 SYSTEM "file:D:\CCNETConfigFiles\project1\project1buildconfig.xml.config">
<!ENTITY project2 SYSTEM "file:D:\CCNETConfigFiles\project2\project2buildconfig.xml.config">
<!ENTITY project3 SYSTEM "file:D:\CCNETConfigFiles\project3\project3buildconfig.xml.config">
]>
<cruisecontrol>
&project1;
&project2;
&project3;
</cruisecontrol>
By doing this, I can have each project configuration in its own file, and I can put each project-configuration in its own directory.
Then, I just have to make sure that in each project config-file, I remove the cruisecontrol tags, because otherwise the ccnet.config file wouldn't validate against the schema.
Probably not the answer you're waiting for, but could still be interesting: we're using about twenty build machines with about fifty different builds. Because indeed it's not a good idea to mix data with program files, we decided to put our ccnet installation in source control. Each server has its own configuration file in that directory (also in source control) and a local batch file or short cut starting ccnet specifies which configuration file is used. This means that local data (the build logs) are mixed with data that is in perforce (ccnet binaries/configuration files), but we have accepted that situation. Hope this helps.
Regards,
Sebastiaan