How to add a FileSystem Task to Delete a file while providing FlatFileConnection name as SourceConnection?
below code doesn't work
<FileSystem Operation="DeleteFile" Name="FST-Delete File once It Is Loaded">
<FileInput ConnectionName="FCM_LogIDMapping_LDW"></FileInput>
</FileSystem>
it gives error:
Could not resolve reference to 'FCM_LogIDMapping_LDW' of type 'FileResource'. 'ConnectionName="FCM_LogIDMapping_LDW"' is invalid. Provide valid scoped name. Property FileConnection.
To work with a Flat File as the input, you need to use FlatFileInput
<FileSystem
Operation="DeleteFile"
Name="FST-Delete File once It Is Loaded">
<FlatFileInput ConnectionName="FCM_LogIDMapping_LDW" />
</FileSystem>
The FileInput is used for something like Excel
Related
Is it possible to configure a non-static value for the metadata field in the wildly json-formatter?
I didn't find anything about it in the wildfly documentation- it only has a simple static field example (meta-data=[#version=1])
For example, I would like to have a field "simpleClassName" - The class of the code calling the log method.
I also tried to use a similar syntax to pattern-formatter(example below) but it doesn't work
<formatter name="JSON">
<json-formatter>
<meta-data>
<property name="simpleClassName" value="%c{1}"/>
</meta-data>
</json-formatter>
</formatter>
No the meta-data is only static information. However what you're looking for seems to be the details of the caller. Note that this is an expensive operation should you should use it with caution. What you'd want to do is change the print-details to true. In CLI it would be something like:
/subsystem=logging/json-formatter=JSON:write-attribute(name=print-details, value=true)
I have a problem with Nuxeo, when I want to import my files with their attachements. It's necessary to adopt the parameters of The nuxeo CSV. For example : They define "dc:title" for title and "dc:description" for description.
here is how it works :
"name","type","dc:title","dc:description","file:content","dc:creator"
"nuxeo-csv-userdoc","File","Nuxeo CSV User documentation","This is the user guide for Nuxeo CSV","C:/../nuxeo-csv-userdoc.pdf","user"
My file is different, and I want to choose my parameters. For example, I have a date, society name, supplier, ID...which is different from what suggest Nuxeo.
Do you have any idea how to do this.
"Type","Title","Society","Year","ID","Path","supplier"
"RAPPORT","CENTRIFUGAL PUMPS","EMTECH-E LIST OF PARTS","2005","1767","file.pdf","XY"
Thanks
You must map the import with the custom type that you defined. Have you read https://doc.nuxeo.com/nxdoc/how-to-enable-csv-import-on-a-custom-document-type/ ?
you'll probably want to enable CSV import on the document types you defined, either in Studio or with some code. Here is how to do that.
(...)
<require>org.nuxeo.ecm.platform.actions</require>
<extension target="org.nuxeo.ecm.platform.actions.ActionService"
point="filters">
<filter id="importFile" append="true">
<rule grant="true">
<permission>AddChildren</permission>
<type>YourCustomTypeID</type>
</rule>
</filter>
</extension>
We have an ant build file running jasmine unit tests
<parallel>
<antcall target="-test-base-jasmine-unit">
<param name="karma-conf-file" value="test1.conf.js" />
</antcall>
<antcall target="-test-base-jasmine-unit">
<param name="karma-conf-file" value="test2.conf.js" />
</antcall>
....
and outputting a report junit-noframes.html.
In the report, each separate target conf file is in it's own section, with a header at the top.
Our headers all display 'TestCase 0)'
Current State: all 0)
I would like them to display some unique identifier instead of the 0) like in this found example. Each target has descriptive name
I haven't found anything in the documentation. I've tried adding likely sounding params but to no avail.
Thanks in advance for any advice!
I have a problem figuring out the permission set to get Directory.GetFiles() to work in an assembly used by SQL Server reporting services.
Background
Basically, I use this assembly to perform two things:
read images from a file share
enumerate all images in a folder on that share.
Feature 1: Reading an image (works fine)
Reading images works using a custom permission set:
<PermissionSet class="NamedPermissionSet"
version="1"
Name="MyCustomImagePermissionSet"
<IPermission class="FileIOPermission"
version="1"
Read="\\MyServer\MyFolder"/>
<IPermission class="SecurityPermission"
version="1"
Flags="Assertion, Execution"/>
</PermissionSet>
and referencing this permission set in a custom code group:
<CodeGroup class="UnionCodeGroup"
version="1"
PermissionSetName="MyCustomImagePermissionSet"
Name="MyImageCodeGroup"
<IMembershipCondition class="UrlMembershipCondition"
version="1"
Url="C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\MyProject\MyProject.Reports.Code.dll"
/>
</CodeGroup>
(Snippets taken from RSPreviewPolicy.config)
In my code, I use an assertion before opening a FileStream:
private Image LoadOriginalImageByPath(string path)
{
new FileIOPermission(FileIOPermissionAccess.Read, path).Assert();
Image originalImage;
using (var imageStream = new FileStream(path, FileMode.Open, FileAccess.Read))
{
originalImage = Image.FromStream(imageStream);
}
return originalImage;
}
Feature 2: Enumerating files in Directory (does not work)
Enumerating all the files in a subdirectory on the file server always results in a SecurityException:
System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
at System.Security.CodeAccessPermission.Demand()
at System.IO.Directory.InternalGetFileDirectoryNames(String path, String userPathOriginal, String searchPattern, Boolean includeFiles, Boolean includeDirs, SearchOption searchOption)
at System.IO.Directory.GetFiles(String path, String searchPattern, SearchOption searchOption)
at System.IO.Directory.GetFiles(String path, String searchPattern)
at MyProject.Reports.Code.ImageTools.GetImagesFullPaths(String searchDirectory, Int32 registerNr)
The action that failed was:
Demand
The type of the first permission that failed was:
System.Security.Permissions.FileIOPermission
The Zone of the assembly that failed was:
MyComputer
Here's the code:
public static IEnumerable<string> GetImagesFullPaths(string searchDirectory, int registerNr)
{
var pattern = string.Format("M{0:00000}?.jpg", registerNr);
new FileIOPermission(FileIOPermissionAccess.PathDiscovery | FileIOPermissionAccess.Read, searchDirectory).Assert();
return Directory.GetFiles(searchDirectory, pattern);
}
Workaround: Using FullTrust
The only way I found to get around the problem is to use FullTrust for the custom assembly. But obviously, that makes the admin uneasy.
The Question
What am I missing to get the Directory.GetFiles() work without using the FullTrust permission set?
Edit
Thanks to the accepted answer, the solution is adding the PathDiscovery attribute to the permission element resulting in
<PermissionSet class="NamedPermissionSet"
version="1"
Name="MyCustomImagePermissionSet"
<IPermission class="FileIOPermission"
version="1"
Read="\\MyServer\MyFolder"/>
PathDiscovery="\\MyServer\MyFolder"/>
<IPermission class="SecurityPermission"
version="1"
Flags="Assertion, Execution"/>
</PermissionSet>
Thx!
Enumerating files requires FileIOPermissionAccess.PathDiscovery on the target path. You need to add this to your custom permission set.
BTW, asserting the permission is essentially useless since the assert will not work unless your code already has the permission. (Assertions are only useful if you want your code to execute something that its calling code does not have permissions to do.)
If I've got a variable that contains the fully-qualified name of a file (for example, a project file), should it be called projectFile, projectFileName or projectPath? Or something else?
I usually go with these:
FileName for the file name only (without path)
FilePath for the parent path only (without the file name)
FileFullName for the fully qualified name with path
I don't think there is such a thing as an accepted standard for this. I depends on your (team's) preferences and whether you need to differentiate between the three in a given situation.
EDIT: My thoughts on these particular naming conventions are these:
intuitively, a "Name" is a string, so is a "Path" (and a "FileName")
a "Name" is relative unless it is a "FullName"
related variable names should begin with the same prefix ("File" + ...), I think this improves readability
concretions/properties are right-branching: "File" -> "FileName"
specializations are left-branching: "FileName" -> "ProjectFileName" (or "ProjectFileFullName")
a "File" is an object/handle representing a physical object, so "ProjectFile" cannot be a string
I cannot always stick to these conventions, but I try to. If I decided to use a particular naming pattern I am consistent even if it means that I have to write more descriptive (= longer) variable names. Code is more often read than written, so the little extra typing doesn't bother me too much.
System.IO.Path seems to refer to the fully qualified name of the file as the path, the name of the file itself as filename, and its containing directory as directory. I would suggest that in your case projectPath is most in keeping with this nomenclature if you are using in the context of System.IO.Path. I would then refer to the name of the file as fileName and it's containing directory as parentDirectory.
I don't think there's a consensus on this, just try to be consistent.
Examples from the .NET Framework:
FileStream(string path...);
Assembly.LoadFrom(string assemblyFile)
XmlDocument.Load(string filename)
Even the casing of filename (filename / fileName) is inconsistent in the framework, e.g.:
FileInfo.CopyTo(string destFileName)
You should title it after the file it is likely to contain, ie:
system_configuration_file_URI
user_input_file_URI
document_template_file_URI
"file" or "filename" is otherwise mostly useless
Also, "file" could mean "I am a file point" which is ambiguous, "filename" doesn't state whether or not it has context ( ie: directories ), fileURI is contextwise unambiguous as it says "this is a resource identifier that when observed, points to a resource ( a file ) "
Some thoughts:
projectFile might not be a string -- it might be an object that represents the parsed contents of the file.
projectFileName might not be fully-qualified. If the file is actually "D:\Projects\MyFile.csproj", then this might be expected to contain "MyFile.csproj".
projectPath might be considered to be the fully-qualified path to the file, or it might be considered to be the name of the parent folder containing the file.
projectFolder might be considered to hold the name of the parent folder, or it might actually be an implementation of some kind of Folder abstraction in the code.
.NET sometimes uses path to refer to a file, and sometimes uses filename.
Notice that “filename” is one word in English! There's no need to capitalize the “n” in the middle of the identifier.
That said, I append Filename to all my string variables that contain filenames. However, I try to avoid this whole scenario in favour of using strongly typed variables in languages that support a type of files and directories. After all, this is what extensible type systems are there for.
In strongly typed languages, the need for the descriptive postfix is then often unnecessary (especially in function arguments) because variable type and usage infers its content.
All of this depends partly on the size of the method and if the variables are class variables.
If they are class variables or in a large complicated method, then follow Kent Fredric's advice and name them something that indicates what the file is used for, i.e. "projectFileName".
If this is a small utility method that, say, deletes a file, then don't name it "projectFileName". Call it simply "filename" then.
I would never name it "path", since that implies that it's referring to the folder that it's in.
Calling it "file" would be OK, if there were not also another variable, like "fileID" or "filePtr".
So, I would use "folder" or "path" to identify the directory that the file is in.
And "fileID" to represent a file object.
And finaly, "filename" for the actual name of the file.
Happy Coding,
Randy
Based on the above answers of the choices being ambiguous as to their meaning and there not being a widely accepted name, if this is a .NET method requesting a file location then specify in the XML comments what you want, along with an example, as another developer can refer to that if they are unsure of what you want.
It depends on naming conventions used in your environment e.g. in Python the answer would be projectpath due to naming conventions of os.path module.
>>> import os.path
>>> path = "/path/to/tmp.txt"
>>> os.path.abspath(path)
'c:\\path\\to\\tmp.txt'
>>> os.path.split(path)
('/path/to', 'tmp.txt')
>>> os.path.dirname(path)
'/path/to'
>>> os.path.basename(path)
'tmp.txt'
>>> os.path.splitext(_)
('tmp', '.txt')