I've an desktop application that implements Serializable class, but now I'm translating it to an web app with servlets, I use Netbeans for this work,I have the following code:
InputStream input = ClassLoader.getSystemResourceAsStream(file_input);
Where file_input is an bytecode fyle from an object serialized before, I don't know where I should put this file because in the desktop application I put it in the same dir where I had my classes.
(I have the file, I don't need to create it).
First of all, don't use ClassLoader#getSystemResourceAsStream() in a Java EE web application, ever. Instead, use ClassLoader#getResourceAsStream(). I would also put big question marks around using ClassLoader#getSystemResourceAsStream() in a Java SE desktop application, for sure if it's intended to be distributable, but that aside.
The ClassLoader ultimately loads resources from the classpath. So all you need to do is to make sure that the file is placed in one of the paths which are by default covered by the webapp's runtime classpath, or to add the new path to the file to the webapp's runtime classpath through a server specific configuration setting, such as shared.loader property of Tomcat's /conf/catalina.properties.
One of the default paths covered by the webapp's runtime classpath is the /WEB-INF/classes folder of the WAR. From IDE project's perspective, just drop the file in the root folder of the "Java Source" (src) folder, there where you have all your Java packages and classes. The IDE will take care that it ultimately ends up in /WEB-INF/classes of the built WAR file.
I by the way still assume that you are not creating the file from inside the webapp, as you explicitly told. That wouldn't work. If you actually need to have write access as well, you're going to need an absolute disk file system path instead. You can always make it configureable by providing it as a VM argument or environment variable, for example.
Related
I'd like to include a resource file (e.g. some xml config file) in my bundle and make it visible to all other bundles in the container. Is it possible without using the Fragment-Host manifest header? I'd like this resource file to always be visible in the classpath of all bundles running alongside my bundle, even those that do not exist yet, but will potentially be added in future.
EDIT:
To clarify - that resource must be available passively, i.e. the other bundles should be able to find it in their classpath, and not by refering to any special API or service of my bundle.
Some more background - my environment is a bit messy but I have no control over it and cannot change its existing bundles. The only way I can modify it is by adding my own bundles. That environment includes several copies of the ch.qos.logback.classic bundle. When logback starts up, it looks for specific XML config files in the classpath. If it doesn't find any of them, then its default behaviour is to print everything to stdout with debug level. This environment was previously used to host a GUI application so it didn't matter that much before, but now I am trying to adapt it so I can use some of its functionality in headless mode. So now it becomes important to me to be able to configure it in such a way that only warning and errors are printed to the console.
In general, no you cannot do this. Class-space isolation is at the heart of OSGi, but you want to put a resource in the class loader of one bundle and make it visible to all other bundles. That's not OSGi, it's the global application classpath.
The only thing you can do to add to the internal classpath of a specific bundle is to write a fragment which attaches to that bundle. A fragment can attach to multiple host bundles, but only if those hosts have the same symbolic name, i.e. because they are different versions of the same bundle. See OSGi R6 Core Specification, section 3.14.
You did however state that the bundles you want to attach are all copies of ch.qos.logback.classic. If that means they all have that exact symbolic name then perhaps a fragment will work after all.
You can not change the classpath of other bundles this way.
What you can do is retrieve the classloader of your bundle from your bundleContext. You can give this classloader to another bundle to retrieve your resource.
ClassLoader cl = context.getBundle().adapt(BundleWiring.class).getClassLoader();
Another option is to give the other bundle the URL of the resource.
As long as the resource is on the classpath, any bundle can access the resource if it can get hold of the class loader of the bundle that contains the resource.
For example:
ClassLoader classLoaderOfBundleWithResource = ...
classLoaderOfBundleWithResource.getResourceAsStream("org/example/resource.xml");
From a maintenance and API point of view, I would not recommend exposing a resource that way. Java types are much better suited therefore. Instead, let the resource bundle export a class that gives clients access to the contents of the resource.
For example:
public class XmlDocumentProvider {
public InputStream openDocument() {
return getClass().getResourceAsStream("resource.xml");
}
}
Assuming that both the resource.xml and the XmlDocumentProvider reside in the same package, openDocument will return the resource content just like in the first example.
In order to load .DLLs (under Windows) or .SOs (under Linux) we must use the environment variables PATH (Windows) or LD_LIBRARY_PATH (Linux).
The only way we could find to properly use DLLs and SOs was to define the environment variables before starting Netbeans.
Is there a way to specify those environment variables inside
Netbeans?
Is it possible to specify it inside the project
properties? That way each project could have its own definitions.
is there a way to just append to those environment variables instead of just overriding them?
Background: we are developing a Java program that uses JNI to access native libraries. Those native libraries, in turn, access other dependent native libraries. Because of that, just setting the property "java.library.path" doesn't work, as we need to set the full LD_LIBRARY_PATH (or regular PATH in the case of Windows), too.
Outside Netbeans the application runs fine, because we set the environment variables inside shell scripts.
We don't want to just place the DLLs or SOs in the usual system directories because we don't want to mess up with the operating system installation during development. In addition, we want to have the flexibility to allow any developer to simply get the project from source control (Mercurial) and have all relative paths just working.
There is already a hack on stack overflow to set environment variables programmatically in Java. However, we are looking for less hackish a solution.
You can override Ant script tasks that NetBeans uses in build.xml file (or edit it directly in the full script in nbproject/build-impl.xml, but not recommended).
The java task is used on run target. You can use env parameter to specify environment variables to the process that will run the JVM.
This is for Struts 1.x (I'm using 1.3.10).
I've noticed that Struts is unable to pick up resource bundles in the ApplicationResources.properties file if it is not placed somewhere in the default classpath (e.g., com.abc.SomePackage).
For instance, if I put the ApplicationResources.properties file in a custom folder /WEB-INF/strutsResources and configure the struts-config.xml thus:
<message-resources parameter="/WEB-INF/strutsResources/ApplicationResources"/>
I've read that the resources need to be on the classpath so I've also tried adding the /WEB-INF/strutsResources folder to the classpath. It still does not pick up the resource keys.
I've double-checked that the strutsResources folder is actually deployed to the server (I'm using Glassfish v3), so the file is there, it's just not being parsed.
P.S.
If you're wondering why I'm trying to do this, I just wanted to organize my code a little better ("better," IMO). Since the ApplicationResources.properties file is not really a class, I wanted to place it in a resources folder by itself.
I've checked that placing the ApplicationResources file in a package in the src directory works just fine.
Ultimately, the answer is yes. You can play some interesting games by configuring a custom className and/or factory and get messages however you want (including from a database) and so on. This allows you to customize whatever you want*.
I agree the resources aren't a class, but putting them on the classpath is a common practice, and allows resources to be loaded as a resource, e.g., from inside a jar. I'm sympathetic, but I'd leave it as-is.
*Like reversing all the text; a fun prank to play on your co-workers and QA department.
Its best leave it on the classpath.
It's stadard practise to include properties files on the classpath, especially if you're planning on packaging it up in your WAR/EAR. You're keeping it under WEB-INF so you gain no benefit from moving it off the classpath, and you'll just confuse other developers who have to work on the project and you've had to put a hack in to make this work.
If you want to keep your files external to your deployable WAR/EAR then that's a valid reason for not using the classpath. Typically this will require some configuration as part of your deployment to specify where the file is to reside.
For example specify the location using
a JVM argument (e.g. -Dprops.file=/config/myapp.properites)
lookup from a JNDI resource
use a PropertiesFactoryBean if you're using the Spring framework (I
use Spring's ApplicationContext with Struts 1 MVC)
read properties from a database writing your own
ApplicationPropertiesDAO class that initialises itself durnig your
applications bootstrap process (e.g. Spring application contact,
Servlet in web.xml, Listener in web.xml, etc)
I have a Spring application that is being deployed to JBoss 4.2. I can manually edit the generated WAR file and alter the jboss-web.xml file to set the context-root value and that works perfectly well. I would like to be able to do the samething via netbeans (6.9.1), but I have been unable to locate where to make the adjustment. I've tried tweaking the project's properties and setting the Context Path value. When I Run the application that value is reset to the Project's name. I've located the jboss-web.xml file in the project and changed it there, also reset upon run. So it appears that Netbeans is deciding that the value need to be set but I can't locate where. If it's of any use, the project also uses Maven2, but all the controls I can find for impacting context-root are geared towards EAR files instead of WAR.
Has anyone been able to do this or am I just in a world of making the change post build?
I had a similar problem once where netbeans was sometimes removing the context-root element from the glassfish-web.xml configuration. I have not been able to track it down exactly but you could try to remove the file nb-configuration.xml in the project root folder and see if that helps.
I have inherited a project that has class libraries written in VB.NET, some of these have ".settings" files and the others have a ".dll.config" file to store connection strings. What is the difference between these 2 methods?
EDIT: In what scenarios would I prefer one over the other?
They're basically the same thing - or strongly related, anyway. A settings file gives you strongly-typed access to entries in an app.config file, and keeps them in sync. When you compile, the app.config file is copied to the bin folder with the name of your assembly.
Note that, if you modify the .config file by hand, you can lose changes if the settings file overwrites them. In VS2008 it will prompt you, so you can choose to sync them.
I think that .settings is application wide, while the .dll.config files are specific to the assembly they are named for.
".config" files are at the core of .NET configuration system. They store the actual configuration data. In the early .NET framework, if you wanted to extend the configuration system to handle your custom configuration data, you had to do this manually. "Settings" file is a feature that allows you to visually define configuration options and use them to create a strongly typed class. This class can then be used as a method to read and manipulate the configuration data specified in application's ".config" file at runtime. They also provide some neat features automatically, such as defining per-user or per-application configuration options. They greatly reduce the hassle to manually extend the configuration system.