I am facing one weird issue while running mule application. We have multiple entries in mule-app.properties (220 lines
). When I try to run the application, it fails with file or extension too error.
When I remove some random entries from properties file, application starts successfully. Any help will be appreciated.
I have had a similar issue to this, and it because of the way the entries in mule-app.properties are applied at runtime. The JVM is complaining that the VM arguments are too long, which is how properties in mule-app.properties are applied.
The way you can work-around it is to store your properties in a separate .properties file in src/main/resources and include this file as a property placeholder in your global configuration:
<context:property-placeholder location="myApp.properties"/>
Note if you use environment specific properties like this also you can reference multiple files separated with a comma, e.g.
<context:property-placeholder location="myApp.properties, ${mule.environment}.properties" />
Related
I have a customer using an application called 'Nhibernate' and a plugin called Log4net. Both work in conjunction to generates a log file.
My problem is that once nhibernate.log reaches more than 200MB a new file is generated and the old file is renamed NHibernate.log.1
Is there way to avoid the segmentation of the log files and makes the log readable even after 200MB.
Thank you for your responses.
Regards.
You can open the NHibernate.log.1 with any text editor. If you open the configuration file you can change the logname pattern for the NHibernate logger file property.
If you want all in one file you can change the appender to a normal fileappender.
An link to an older blog with some information on how to do the configuration for the NHibernate appender: http://geekswithblogs.net/opiesblog/archive/2006/09/29/92721.aspx
Log4net has a configurator that defines the max size of the file and the number of extra files created after reaching this max size.
If you want everything on a single file, you can re-defines these properties.
You probably have an .config file or on your app.config/web.config an set of xml properties that defines these parameters.
This is an example of the property you are looking for:
<maximumFileSize value="200MB" />
I'm using IntelliJ 15.0.3.
Update: Have also tried updating to 2016.2.4, but the issue persists.
By creating variables under Settings -> Appearence and Behaviour -> Path Variables, these can be used in a run configuration with $VARIABLE_NAME$ to indicate for example what working directory or program arguments should be used by that run configuration. This is useful if for example the same directory is used in many parts of the run configuration but is changed from run to run.
However when using $VARIABLE_NAME$ in a run configuration it doesn't seem to be persistant. If I close my IntelliJ session the value of the variable will replace the variable reference. So for example if I have the variable:
FILENAME = somefile.csv
and in my run configuration I put "$FILENAME$" under program arguments, this will only be persistant for that session. When I close and reopen IntelliJ the program argument has been set to "somefile.csv" instead of retaining the reference "$FILENAME$".
How do I ensure that the variable reference is retained over several sessions?
Edit: Added screenshots showing before and after session reset.
Before a session reset I set my program arguments to reference my FILENAME variable. This also happens if I try to for example use the working directory field instead of the program arguments field.
After restarting IntelliJ the run configuration no longer references FILENAME.
I can't reproduce the issue in v2016.2.4 (i.e. I still get the replacement value after a restart). You may want to upgrade to v15.0.6 which is the latest v15.x available and see if that resolves the issue.
The values you set are simply stored in the file .IntelliJIdea\config\options\path.macros.xml (see Directories used by the IDE to store settings, caches, plugins and logs for info on where the configs directory is located.) So you can take a look at that file and see what's going on. Maybe try adding it outside IDEA (when IDEA is closed) and see if it holds (in the event a bug is causing the that file to not save properly after editing via the IDE.)
From here, I get to know how to create a Web Deployment Package with MSBuild. The command line looks like this:
MSBuild "MyProjectName.csproj" /T:Package /P:Configuration=Staging;PackageLocation="D:\Vishal\Package.zip"
The Configuration, PackageLocation are both properties.
I just wonder how can I know which properties are applicable? And their formal definitions?
I searched the MSBuild Reserved and Well-Known Properties, but they are not there.
And I searched the MSBuild Task, still no luck.
ADD
It seems different project types have their specific properties. For example, the PackageLocation property should be specific to a Web Application project. What I am looking for is the specific definition of these properties.
ADD 2
I have a MSBuild task as below.
> <MSBuild Targets="Clean; Package"
> Projects="$(XXXSolutionDirectory)\Web\Web.csproj"
> Properties="Configuration=$(Configuration); Platform=$(Platform);
> OutputPath=$(BinDirectory)\Web_Deployment_Package;
> PackageLocation=$(BinDirectory)\Web_Deployment_Package;
> PublishDir=$(BinDirectory); OutDir=$(BinDirectory);
> IntDir=$(IntDirectory); TfsBuild=$(TfsBuild);
> CscToolPath=$(CscToolPath); CscToolExe=$(CscToolExe);
> VbcToolPath=$(VbcToolPath); VbcToolExe=$(VbcToolExe);
> TargetProfile=$(XXXConfiguration)"></MSBuild>
The properties such as PackageLocation are placed within the Properties attribute of MSBuild task. Rather than in a PropertyGroup definition. And this is the only place it shows up in the build proj file. So where can I find its definition to understand its intended usage?
Ok, let's start first with the bit of fundamental processing pipeline of MSBuild.
When msbuild engine parses your proj file - it takes all
c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.CSharp.targets
around line 379 you can see
<Import Project="Microsoft.Common.targets" />
this means - in the final big script - instead of line 379 you'll see the content of
c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets
then in the next phase - msbuild will calculate all Global Properties and Items values.
It has some rules on which value (because you may have multiple property declarations with different values which will end up in a property with single value - usually last one or global one wins) will be assigned to property, but I'll omit these details here.
And the properties you specified in msbuild command line also participating in this process.
Particular property declaration can be in more than one .targets file but that really doesn't matter. What's matter is - what value this property will have at the end of global property processing phase.
But if you really want to know where is particular property is defined - you need to manually search through all imported .targets files and find property declaration tag.
Targets files can be in your .NET Fw folder or in installed SDKs (if you have specific project types like Azure .ccproj ones)
For example - let's take most popular property "Configuration".
I sought in all .targets files text <Configuration and Microsoft.Common.targets line 132 has this entry:
<Configuration Condition=" '$(Configuration)'=='' ">Debug</Configuration>
As you can see - there is a condition which is saying - set configuration to Debug if it's not yet defined.
Because you specified this property's value as a command line parameter - your property will have higher priority and will cause this condition to be false, thus your value will be the final value of this particular property.
Same for PublishDir - Microsoft.Common.targets line 425:
<!-- Output location for publish target. -->
<PropertyGroup>
<PublishDir Condition="'$(PublishDir)' != '' and !HasTrailingSlash('$(PublishDir)')">$(PublishDir)\</PublishDir>
<PublishDir Condition="'$(PublishDir)'==''">$(OutputPath)app.publish\</PublishDir>
</PropertyGroup>
and so on.
Some properties (especially for custom project types ) can be defined in it's own SDK .targets files, but if you'll open that custom .zzProj file and may find project properties there OR you can manually follow all <import directives - and eventually will find where every specific property is defined. And usually along with definition - you can trace how this property is being used by targets (search for $(MyPropertyName) ) and tasks, thus - alter it for your own needs or spot bugs or weird usages.
Hope this helps you.
First pre-process the MsBuild script to flatten and consolidate all imported scripts into a single MsBuild file.
MsBuild.exe MyProject.proj /pp >Output.xml
Now, open Output.xml in Notepad and search for instances of $(Configuration) and $(PackageLocation).
$(Configuration) is one of the base default properties you'd find in most MsBuild projects and you'd see it used in Microsoft.Common.CurrentVersion.Targets in targets that are designed to fail the build if an invalid or unexpected Platform or Configuration property is used.
PackageLocation is specific-to ASP.NET projects and the import taxonomy would include Microsoft.Web.Publishing.targets which contains several targets dedicated to parsing and validating that property as part of the web publication workflow.
Is it possible to load values for infinispan-config.xml file from some property file so that we can get rid of hard coded values. If possible then can somebody show me the way how i load property file in infinispan-config.xml file because there is no Pre defined tag for configuration.
This is possible by setting respective system properties.
For example here is one specific Infinispan configuration file which is using this approach: https://github.com/infinispan/infinispan/blob/master/core/src/test/resources/configs/string-property-replaced.xml
and here is a test which is working with that file: https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/config/StringPropertyReplacementTest.java
This looks to be the most straightforward way how to achieve this.
The last thing which needs to be done is to simply read all lines in your configuration file and put them correctly to system properties.
We have a standard MSBuild project file that is used for our different deployment stages (pre-stage, stage, live, etc). Since each deployment stage is performed on a different server we introduced a server parameter called $SourceDatabaseServer and used this extensively in each of the targets inside the project file. Note: This database server name could be different from the server name on which the build is run.
To assist us with the customization of this parameter, we created a response file for each deployment stage and subsequently defined a value for this parameter in the response file, e.g. /p:SourceDatabaseServer=SRC_DB_NAME.
This worked fine, until we created a new deployment stage in which this value had to be the current computer name. So we thought by using the $(COMPUTERNAME) reserved property in the response file (/p:SourceDatabaseServer=$(COMPUTERNAME)), this would do the trick, but it seems like this value is interpreted literally by MSBuild, and we consequently get an error that server $(ComputerName) could not be found.
Interestingly, when the $(COMPUTERNAME) property is used directly in the proj file it works, but as stated above, we do not necessarily want to use the computer name in all the cases.
Is there a way to still use the $(COMPUTERNAME) property in the response file and get MSBuild to interpret this correctly?
What if you use %COMPUTERNAME%?
$(VAR) is the syntax for variable expansion when you're "inside" the MSBuild system, but coming from the outside, I believe you'd have to use the shell environment variable expansion syntax, %VAR%.