I am registering components using Castle Windsor and the
Classes.FromAssemblyInDirectory
directive to load all the implementations of a service in a given directory. This works great. One of the features I'd like to add is to dynamically drop-in new assemblies to a running process (the process is a Windows Service.)
Now, my first thought is just to add a FileSystemWatcher and manually remove / register services whenever the files in the directory change. Which is fine, and I'm sure would work.
But before I wrote anything, it occurred to me that Windsor might have something like this already built-in. Which would be neat and save me some coding.
Googling didn't turn up anything obvious, but, well, I'm new to Windsor and do not perhaps know all the correct terminology.
Is anyone aware if this functionality exists?
No, this is not the kind of functionality that Windsor supports. It's not something IoC container is meant to do.
Related
I want to modularize a monolithic application by using Java modules (introduced by Project Jigsaw).
Unfortunately I'm currently stuck to use Java 8. I would like to build those modules (jar files) anyway, but without the feature of using a module-info.java file for declaring the dependencies and the exported API.
Some weeks ago I stumbled upon an API/framework which allows to define nearly the same things that you can do in a module-info.java file. It could be used in JUnit tests in order to enforce module's not to use the internal's of another module and that module's only can access modules they explicitly depend on.
Of course you do not have any assistence from the compiler or the IDE, but you can enforce the access by JUnit. Unfortunately I do not find the project which provides the API any more.
Can anyone help?
Btw. if there is another good approach beside a unit test, please let me know, too!
https://www.archunit.org/ is what I have been looking for.
the only IDE I've used for many years was Flash Builder. Sadly the 4.7 version is in a poor state, so, I started looking at other IDE's lately.
I'm trying IDEA, but I don't know how to add a library to my project.
In FB it was simple, I go to the compiler settings and I just add a folder or swc. But here, it seems like there are 2 options, one under the "Libraries" tab and other is creating a new module, however, this new module requires a main app, SDK, and a lot of other stuff that doesn't make any sense to have in a library.
So, what is the equivalent of adding a library path here?.
Thanks.
"Libraries" is the correct way to do it. There are two kinds of libraries: libraries and global libraries. Global libraries can configured once and used in every project. Libraries are configured for each project. See http://www.jetbrains.com/idea/webhelp/configuring-project-and-global-libraries.html
Officially, BlazeDs can only be used "with Flex and AIR". This comment is puzzling in itself since Flex is a set of Actionscript development tools, while AIR is a "mode" in which Flash can operate.
Ultimately, I am starting a new project and I want to use BlazeDS for a Flash CS5.5 (or CS6)-based project. Is this possible? Has anyone used this combination in the past?
If you actually read the article you linked to, you'll soon find that it is absolutely okay to use BlazeDS with any technology that can communicate with a web socket - its message format (AMF3) is an open standard.
So yes, it can be used with Flash (or rather, pure ActionScript), but it is a little less convenient than with MXML, where everything is set up by the framework, because it takes more "under the hood" configuration to be able to run all the necessary parts for remoting. And you will still need the Flex SDK, of course - there's no getting around that.
Once you have the Flex SDK set up with your Flash IDE, you have to manually initialize the Flex remoting classes needed before you can access a BlazeDS service. There is a sample class that has all the required calls and some additional information in this blog post.
I have also written an extensive tutorial about getting RemoteObject wired up and working, as well as setting up a simple "Hello World" web service on my blog. The article series I wrote is intended for use with FDT and RobotLegs 2, but at least the first part (setting up a Java WAR project to deploy as web service) should be helpful to you, nonetheless.
Finally, I would recommend you rethink using Flash as your primary IDE - in my experience, it... well, frankly, it sucks (pardon my French) for anything but animations and setting up asset libraries. If you don't want to pay for a better IDE, you should consider using FlashDevelop (unless you're on a Mac - OS X is not supported). Or maybe give FDT a try - it is much, much more convenient for coding, even if you don't buy the Max license.
I often find the quote "InstallUtil.exe" is an ugly pattern or "Don't use InstallUtil.exe" and that I should use native WIX or Installation package patterns and I still don't understood why.
I stepped away from using InstallUtil to install a .NET service as I finally learnt that writing registry keys for such an action should be an un-install-able action - and I've come to terms with this as correct.
As I've been working through my WIX installer for a relatively complex product, I have found myself in need of creating or updating SQL Server databases, creating or updating IIS Applications and finally updating or creating configuration files.
Each of my components (features) are optional, but they all share the same configuration file. As my product uses unity, its important to note that this library contains strong support for reading/updating/removing components from the Unity Configuration block, therefore it seems fairly smart to me that I should take advantages of these blocks via Installation Components (i.e. InstallUtil) to create or update my configuration file at installation time.
Just to be clear here, my installer does not natively contain a configuration file for my application: at installation time, the installer has no idea as to the shape of it as its based on the features selected. Surely I should be embedding this knowledge into each of the modules that are to be deployed and not in the remit of the installer which is now a completely independent project? Wouldn't this break O-O principals even if we are talking about installation?
I'd really appreciate some guidance as to whether this is good practise or not? Am I reading 'InstallUtil' is bad for installing services, or is it that using 'InstallUtil' is bad full-stop? If so, what are my options for smart updating of configuration files?
The main reason for avoiding InstallUtil is that it runs outside of the installation transaction, so Windows Installer cannot keep track of what it's done.
I have used InstallUtil on a few occasions, when I just couldn't get Wix to do what I needed and didn't have time to write a custom action. In this case I called the InstallUtilLib version as I feel this is a cleaner approach.
I used the this blog as a guide as to how to achieve this.
I am trying to write some simple Java web services so we can call Java code from .NET. So far, I got a proof-of-concept working under Glassfish. Pretty straightforward when the IDE does all the work.
Now I'm really bogging down on stuff in Java that should be really simple. For example, I want to externalize my configuration so I can change stuff like connection strings/usernames/application variables/etc without recompiling.
In .NET, you would just stick some strings in the web.config file in the root of the web site and use: ConfigurationManager.AppSettings["whateverIwant"];
I can get java.util.Properties to do what I want (from a standalone client), but I can't figure out where to put the .properties file and how to get the path to it from within the web service.
I need my approach to work within WebSphere Application Server as well. Thanks!
As others have mentioned, it greatly depends on the container, but almost always dynamic configurations are stored in a database instead of XML or .properties files.
As I see that this is just like a proof of concept, here's a quick and dirty solution: (don't do this for production code) use System Properties.
Disadvantage: with every change you need to reboot the container, but you don't need to recompile the app.
To use system properties in Glassfish you can go to the section "Configuration -> System Properties" and add properties there. Then from inside your application just call
String myValue = System.getProperty("myProperty");
To get the value. All java applications support these properties, but I don't know how to configure them in Websphere.
Alas, Java EE has a giant hole in the head when it comes to application configuration.
Your best bet is to either:
use JNDI to store config in the application server environment. This is hard to do portably, painful, and an absolute nightmare for the user to do any configuration. Configuration UI depends on which app server and version is in use and may be a command-line-only utility specific to that app server.
Use the Preferences API to store your configuration, and produce your own UI to edit it. This is OK ... except that you can't control when your settings are flushed and re-inited. Some app servers will do this when your app is re-deployed, which you probably don't want.
All in all, the situation absolutely stinks. There's no clean, sensible way for an app server to provide an app with a simple properties map and UI to edit it using the app server's admin tools.
I tried to work around this using web context parameters, but found that they too were buggy. Glassfish was ignoring more than the first web context parameter that was being set, and they were hard to access without having a servlet context so you couldn't really get to them easily across the whole app.
If anyone has a better answer I'd love to hear it, because the situation as it stands seems downright amazing for a spec that's been through several major iterations.
see also: Storing and editing configuration for Java EE applications
Application configuration is unfortunately container dependent. In general you access your configuration through JNDI. The approach I've recently used was the following:
Make a database available to your app (through JNDI, use the Glassfish database "wizard"). This is part is container dependent.
Create an entity bean that deserializes your settings from the database. The simple solution here is to have something like this:
#Entity
public class Setting {
#Id
private String name;
private String value;
...
}
Then it's a question of doing em.find(Setting.class, "whateveriwant").getValue(). Alternatively, you could create a single entity bean with all the settings as attributes.
Either way, this approach reduces the container dependency to a minimum.
The best solution I've found so far is "EAC4J (External Application Configuration For Java)". I've used successfully in many projects.
Put the following code in the contextInitialized method of a ServletContextListener:
ServletContext sc = sce.getServletContext();
Properties systemProps = System.getProperties();
String path = sc.getRealPath("WEB-INF/application.properties");
systemProps.load(new FileInputStream(path));
This reads from application.properties from the the WEB-INF folder of your web app when it starts. This will require a restart every time the configs change, but in my opinion, that is as it should be.