How do I set system properties for raw Java classes used from C# code through IKVM?
I am dealing with some Java code that has been ported to C# using IKVM. Some of the classes have been wrapped in C# classes, but not all of the Java API yet. So I have two versions of some classes, and because only a small part of the API has been wrapped, I have to use the raw Java classes directly in my C# code.
When I use the C# wrapped version, I can parse UTF-8 encoded XML files correctly. When I try to use the underlying Java class directly, I get parsing errors ("content not allowed in prolog") which indicate the wrong charset is being used to parse.
In Java we solve encoding issues by setting -Dfile.encoding=UTF-8, and I am trying to do the same in C# as follows:
static FeedSample()
{
java.lang.System.setProperty("file.encoding", "UTF-8");
}
This setting is picked up when I use the C# wrapper class. When I use the underlying Java class directly, the system property is not picked up. I think I am missing something obvious here. I also tried putting -Dfile.encoding as a command line argument but that did not help.
Related
I automatically generate schema for my classes using Json.NET Schema and it works great for validation. I wanted to add the ability for my classes to provide snippets directly and emit them into a (presumably separate) schema file, for use in Visual Studio Code.
https://code.visualstudio.com/docs/languages/json#_define-snippets-in-json-schemas
This is a non-standard schema extension of course. From the source code of Json.NET Schema, it looks like I cannot override the class that is used to serialize the schema to JSON, so I can't figure out how to make this work.
The only approach I have considered is to emit the schema, read it back as dumb JSON and then edit in the snippets. The resulting file could be a .vsschema or something like that and presumably no longer valid in the schema validator, so I would store it next to the "clean" one. Is there any nice way to do this that doesn't require me to path through the resulting JSON and make edits that way?
1) We are using OpenEJB (both embedded and standalone) with a few deployed EJBs. We would like to specify some simple static business rules and values (example: icon_size=200). Normally, we would put them in a regular properties file (example: rules.properties). Since we shouldn't access the file system directly while inside the application server, is is possible to place those key-value pairs somewhere inside the ejb-jar.xml?
2) If not, is there a standard mechanism to do this? What is it?
Thanks
Use env-entry. In XML:
<env-entry>
<env-entry-name>icon_size</env-entry-name>
<env-entry-type>java.lang.Integer</env-entry-type>
<env-entry-value>200</env-entry-value>
</env-entry>
In annotation:
#Resource(name="icon_size")
int icon_size;
I personally just use a .properties file; well a TernarySearchTree which reads in .properties and .XML files and allows quick retrieval. These files are available at application level. However you can in EJB 3 inject env-entry elements into your EJB. This link explains it in good detail Injection of env entry
There are some OpenEJB extensions here that might be useful.
env-entries.properties
Check out the Custom Injection example which is basically allows the <env-entry> to be specified as plain properties in a META-INF/env-entries.properties file. Nice for collapsing all those name & value pairs into a simple properties file. Internally, we just generate the xml for you using those properties. The default type is always java.lang.String, which is good for this next part.
java.beans.PropertyEditor support
Any <env-entry> which is of <env-entry-type> java.lang.String will automatically have its type converted using the VM java.beans.PropertyEditor for the target type. That's also how Spring does the converting. There are few built-in converters, such as #Resource java.util.Date myDate and #Resource java.io.File myFile
The question's simple: how could one use embedded resources in asp.net applications? What are the steps to include a resource in the assembly, and how to reference it? What are the gotchas that could be encountered?
Edit: For a version without referencing Page and ClientScript, see What is the right way to handle Embedded Resources on a Razor View?
After spending a half of a day I've learned these:
to embed a resource one needs to set it's Build Action to Embedded Resource (in VS Solution Explorer rightclick the file -> Properties)
next AsssemblyInfo.vb must be modified to make this resources available for WebResource queries. Add [Assembly: System.Web.UI.WebResource("MyWebResourceProj.Test.css", "text/css")] to AssemblyInfo.vb located in MyProject folder of the project.
The name consists of root namespace/assembly name +'.'+filename. To be 100% sure of the name, use the following code snippet to look it up:
Dim resNames = Assembly.LoadFile("YourDll.dll").GetManifestResourceNames()
Note that the assembly's Root Namespace must be the same as the Assembly Name (this took me about 4 hours to realize. At least with .Net v4 that is the case)
If there are references inside the css ( <%=WebResource("NS.image.jpg")%> ) than pass PerformSubstitution:=true for that css's WebResource attribute.
Referencing the resource can be done with Page.ClientScript.GetWebResourceUrl(GetType(MyWebResourceProj.ConssumingPage), "MyWebResourceProj.Test.css")
Note that instead of GetType(Typename) one could use Me.GetType(), but again, that won't work if the class is inherited, so beware!
Resources:
Debugging ASP.NET 2.0 Web Resources: Decrypting the URL and Getting the Resource Name
Using embedded resources through WebResource.axd is a pain in the neck, as you can see from your own answer. You have to keep assemblyinfo.vb|cs in sync, and it always seems damn near impossible to get all the namespace & assembly names right in all the right places.
When you finally get it to work, your reward is an include script line that that looks like a core memory dump.
I suggest an alternative. Write yourself a very simple web handler (e.g. MyResourceLoader.ashx. Then add a method to your class that simply serves it's own embedded resources, in whatever way you think is meaningful. You can use reflection to get the classes, like WebResource does, or just hardcode whatever you need into your loader, if it's just for a specific purpose. A public method in your class might look like:
public static Stream GetResource(string resourceName) {
// get the resource from myself, which is easy and doesn't require
// anything in assemblyinfo, and return it as a stream. As a bonus,
// you can parse it dynamically or even return things that aren't
// just embedded, but generated completely in code!
}
Or if you decide to make something more general purpose, you can get all fancy and return more data using a class, e.g.
class ResourceInfo
{
public Stream Data;
public string MimeType;
public string FileName;
}
Now you have the ability to serve up your embedded resources any way you want, e.g.
<script language="javascript" src="/MyResourceLoader.ashx/MyControlScript.js">
I think MS made a mess of that WebResource business. Luckily its' pretty straightforward to do your own thing.
when I compile some .py codefiles with no class definitions into dlls , the compiled dll is created with a "DRLCachedCode" class inside. Why is that?
When you compile IronPython code it doesn't get compiled to normal .NET code where you'd have a class at the IL level for each class you have at the source level. Instead it gets compiled into the same form that we compile to internally using the DLR.
For user code this is just a bunch of executable methods. There's one method for each module, function definition, and class definition. When the module code runs it executes against a dictionary. Depending on what you do in the module the .NET method may publish into the dictionary a:
PythonType for new-style classes
An OldClass for old-style classes
A PythonFunction object for function
definitions
Any values that you assign to (e.g.
Foo=42)
Any side effects of doing exec w/o providing a dictionary (e.g. exec "x=42")
etc...
The final piece of the puzzle is where is this dictionary stored and how do you get at it? The dictionary is stored in a PythonModule object and we create it when the user imports the pre-compiled module and then we execute the module against it. Therefore this code is only available via Python's import statement (or the extension method on ScriptEngine "ImportModule" which is exposed via IronPython.Hosting.Python class).
So all of the layout of the code is considered an internal implementation detail which we reserve the right to change at any point in time.
Finally the name DLRCachedCode comes because the DLR (outer layer) saves this code for us. Multiple languages can actually be saved into a single DLL if someone really wanted to.
This link answers the question: http://www.ironpython.info/index.php/Using_Compiled_Python_Classes_from_.NET/CSharp_IP_2.6 how to access an IronPython class from C#.
Manual compilation: \IronPython 2.7\Tools\Scripts>ipy pyc.py /out:MyClass /target:dll MyClass.py did not work. Only when I used SharpDevelop with IronPython it worked as in the post.
In a previous question I mentioned some work with a 3rd party DLL whose interface uses a series of XML inputs that are defined using DTDs. Everything has gone smoothly so far, but I still have this nagging issue with resolving the Document Type Declaration in the generated input values.
What I can't figure out is what the deciding factor is in determining where to look for the referenced DTD file. If I have a declaration that looks like this:
<!DOCTYPE ElementName SYSTEM "ElementName.dtd">
My initial thinking was that the application's current execution path is where a parser would look for the DTD. However, when I attempt to use an XML control in ASP.Net, the error I get baffles me...
Could not find file 'c:\Program Files\Microsoft Visual
Studio
9.0\Common7\IDE\ElementName.dtd'
Why is it looking for the DTD there?
Are there any XML gurus out there who can help me out on this one. I really don't have any control over the XML that is returned from this DLL so what am I supposed to do. Is there a way to "register" a DTD with the operating system? Like the GAC?
Unfortunately the library that generated the XML used a relative url for the dtd rather than a fully qualified one. As such the XmlControl's XmlDocument is using an XmlResolver class to convert the relative path to a fully qualified one. By default it uses an XmlUrlResolver (that is a concrete XmlResolver). This will try to map the location of the dtd to a location it thinks is relative to the Xml document. Trouble is, where is the XmlDocument? Probably in memory which is not relative to anything and the XmlUrlResolver is using the process location instead which in your case is Visual Studio which is located at 'c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe'.
So what can you do? Well I suppose you have to crate you own XmlResolver that inherits from XmlUrlResolver an overrides the ResolveUri method and does something appropriate. Having done that you will have to:
Create an XmlReaderSettings class and set the XmlReolver property to the class you just created.
Create an XmlReader using XmlReader.Create() passing in your document and the XmlSettings object.
Create an XmlDocument and call Load passing in the XmlReader and finally.
Set the XmlDocument property of your XmlControl to the XmlDocument.
Frankly that is all a bit of a pain, so if it where me I would just use string.Replace to remove the DTD declaration from the document before processing it into XML.
If you are feeling really brave you can create a resolver that inherits directly from XmlResolver. Once you have done that you can override the GetEntity method and then you can get the dtd document from wherever you like. I wrote one once that got dtds from files embedded as resource files, but unfortunately, I don't have the code any more :-(
If you do not actually care about validating each and every document against its DTD, you could set the XmlResolver property to null on your XmlTextReader (or XmlDocument) to ignore the DTD altogether.