Spring equivalent for CDI's Instance, or Guice's Provider

Created on Friday, 11 May 2012 11:40

Written by Super User

In CDI you can define an object that will give you items of a certain type, using:

@Inject
Instance<MyObject> myObjectInstance;
//...
MyObject myObjectInstance.get();

Similarly in Guice you can do:

@Inject
Provider<MyObject> myObjectInstance;
//...
MyObject myObjectInstance.get();

So after a lot of digging around I found out that Spring supports JSR-330. This JSR defines a simple API - the whole spec is literally just this API - that standardizes several dependency injection interfaces, annotations and behaviors.

Unlike Spring's FactoryBean the javax.inject.Provider interface doesn't throws Exception on getting the bean reference. Furthermore, you would still need to define this FactoryBean in some place (read XML, or @Configuration class, and this is suboptimal).

Due to a bug, in current Spring 3.1.1, the javax.inject.Provider does not work. It does work in Spring 3.1.0.

In order to use it you simple need to include the javax.inject jar - if you use maven you can simply add this dependency:

<dependency>
    <groupId>javax.inject</groupId>
    <artifactId>javax.inject</artifactId>
    <version>1</version>
</dependency>

Spring will detect it, and from that moment on you can simply use:

@Autowired // you can also use @Inject now.
Provider<MyObject> myObjectInstance;
//...
MyObject myObjectInstance.get();

like in the Guice example, since it is the same API.

Spring will create the provider automatically, so you don't need to add any code or extra configuration.

Hope it helps.

Four Ideas For Firefox

Created on Thursday, 10 May 2012 21:28

Written by Super User

1. Make sure each page has its own process. I am tired for the whole browser to stutter just becase some page / plugin decides it would be a good idea to just hug the CPU. Or the dialog thingie with the "script is not responding" after the browser was frozen for several good seconds? God how I hate it.

2. Change the current design.Yes, really. I haven't seen anyone liking it. Ever. Just pick this theme¹ and be done with it. It is the most used theme that has light colors on it, so your current users - yours truly included - won't be alienated. I understand I have the option to change it, but for crying out loud, do a poll or something and make it the default. There is only one first impression, and Firefox is not exactly the winner on that one.

3. Make Firebug a supported Firefox plugin. It is one of the main reasons why a lot of web developers are using your browser. Whenever that thing has issues, indirectly you have issues. It's awesome that you can see in the default DOM inspector stuff in 3D, but also not really needed.

4. Change the update system. I hate it when I click my FF icon, and wait, and wait, and finally get a dialog that Firefox is updating, and then some more wait, just to restart after, and then get warnings regarding plugins, some more wait, and then the browser is up. I literally one day opened another browser while Firefox was updating, checked the stuff I wanted to see, closed it, and FFox was barely finishing updating itself.

These would be the four things I hate most on Firefox.

¹ FYI: I don't know the designer of the theme, nor his company, nor am I affiliated in any way with him. It doesn't have to be that one, but pick one from the most used ones.

How to install OpenVPN with StoneVPN on CentOS 5.8

Created on Wednesday, 21 March 2012 21:57

Written by Super User

I assume the server is freshly installed and does not have any keys preinstalled.

First things first:

1. Install stonevpn and openvpn

# yum install -y openvpn stonevpn

If you now try to run stonevpn, you will see it gives some errors, so...

2. Fix your openssl config file.

# vim /etc/pki/tls/openssl.cnf

In particular fill the sections req_distinguished_name and in CA_default the dir location. I set mine to /etc/ssl/CA (you need to create this hierarchy).

3. Create the index.txt and serial files.

# cd /etc/ssl/CA

# touch index.txt

# touch serial

When running stonevpn -a we should get an empty list of client certificates. If you're here, so far so good.

4. Generate the server's certificate that will be used to sign all the other client certificates (steps taken from here). Do these in /etc/openvpn since this is by default in the /etc/stonevpn.conf. The names are also server.key and server.crt so it is better to just use these ones.

# cd /etc/openvpn

# openssl genrsa -des3 -out server.key 2048

# openssl req -new -key server.key -out server.csr

# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

5. Next we need to update the pyOpenSSL to have support for X509Extensions. We can see that a simple test run will fail:

==================================================================
Warning: your version of pyOpenSSL doesn't support X509Extensions.
Please consult the README file that came with StoneVPN in order to
fix this. This is not trivial. The certificate will be generated.
==================================================================

Traceback (most recent call last):
  File "/usr/bin/stonevpn", line 18, in ?
    sys.exit(app.main() or 0)
  File "/usr/lib/python2.4/site-packages/StoneVPN/app.py", line 310, in main
    s.run()
  File "/usr/lib/python2.4/site-packages/StoneVPN/app.py", line 434, in run
    self.makeCert( self.fname, self.cname )
  File "/usr/lib/python2.4/site-packages/StoneVPN/app.py", line 997, in makeCert
    cert = self.createCertificate(req, (cacert, cakey), curSerial, (0, 24 * 60 * 60 * int(defaultDays)))
  File "/usr/lib/python2.4/site-packages/StoneVPN/app.py", line 799, in createCertificate
    cert.set_notBefore(now)
AttributeError: set_notBefore

So we need to download and build pyOpenSSL.

# wget https://launchpad.net/pyopenssl/main/0.11/+download/pyOpenSSL-0.11.tar.gz

# yum install gcc python-devel openssl-devel

# cd pyOpenSSL-0.11

# ./setup.py install

6. Now we're good to go.

A better event system (for JavaScript)

Created on Tuesday, 28 February 2012 17:45

Written by Super User

I've seen a lot of APIs that have the bad habbit of having the event types described as String. jQuery (JavaScript) and SWT (Java) are two popular examples that allow extensions of the event system using String names. Generally the API is composed by 2 methods:

1. the Add Listener method: on / addPropertyChangeListener
2. the Fire Event method: fire / notifyPropertyChange

While the naming conventions are different, in spirit they do the same thing. The problem with this approach that if you do instead of:

element.on("click", function() { ... });

this

element.on("clickl", function() { ... }); // invalid event type

you won't even notice it unless many hours of pointless debugging have passed.

So I believe that JavaScript APIs (in particular) should go in a different direction, where you could see the problem the moment you try to listen to an event that does not exist, by throwing an exception on the Add Listener method. Thus, another method would be needed to actually register the event type to the specific element, so we will have:

1. the Register Event method: event / addEvent (?)
2. the Add Listener method: on / addPropertyChangeListener. Note that this will now throw an exception if an invalid listener will be registered.
3. the Fire Event method: fire / notifyPropertyChange. This now can also throw an exception if the event was not registered.

Since we're developers here, some API calls would look like:

var element = $("#whatever");
 
// wrong
element.on("customevent", function() {...}); // throws exception
 
// good
element.event("customevent"); //now only we can register listeners to it.
// later ...
element.on("customevent", function() {...}); // works just fine.

Note, that it doesn't mean this should be the final API. Personally I think the best looking API is something along the way that after the registration, you could call the API only via members of the on object. Something like this:

element.on.customevent.addListener(function() {...});
element.on.customevent.removeListener(func);
element.on.customevent.notify(eventData); // trigger the actual event
 

But I am convinced that the actual event types should be tied to the object that can generate them.

Advantages

In my opinion this approach has these advantages:

• Faster time from the error introduced in the code, to the error report. (we won't generate non existing events, nor listen to non existing ones).
• The possibility of interrogating an object on what events it can raise at runtime.

The only drawback I can think of, is that you can't listen to events before they are registered, but I haven't yet seen any real life application where this actually happens.