Scheming Solutions

I have a 2006 BMW 330xi and the doors stopped unlocking about a 2 weeks ago.

• Doors won’t unlock with the remote (2 remotes).
• I could only gain access to the car through the driver’s door with the physical key (located inside the remote).
• The lock/unlock button on the dashboard would only lock the car.  There was still no way to unlock it from inside.
• BMW Hazard:  From what I can tell, there is absolutely no way to unlock the rear doors and front passenger door when they are locked.  I can’t imagine what would happen if you got into a bad accident and your passengers were trapped inside the car.  A bit scary to think the Germans missed this while designing the car.

First thing to check are the fuses.  Typically if these are all good you most likely have a failed door actuator.  Luckily for me it was only a blown fuse.  The E90’s have 5 fuses that control the door locks.  In my case it was fuse #57 that was blown and needed to be replaced.  This is a 15amp** mini fuse that can be picked up from any local automotive store.

How to check/replace the fuses

This was the hardest task of the job.  The fuse box is located behind the glove box.  Without being able to open the passenger door your access the the fuse box becomes greatly restricted.  I had to completely recline the passengers seat to create more room.  The fuse panel cover is really just the back wall of your glove box.  To remove this you need to open your glove box (remove any contents) and back side of the glove box has 2 quick release screws on the top of each corner.  Once you take out this panel you will see a card on the back side of it.  This is your fuse diagram.

Before touching the fuses I highly recommend unplugging your car battery in the trunk.  Just taking off the negative terminal lead will be good enough.

My problem was it was near impossible for me to get my hands back far enough with the limited space to reach and pull a fuse.  Even long needle nose pliers wouldn’t do the trick.

Read more…

Phil Uncategorized

My turn finally came around…I had to complete online driving school for a speeding ticket.

I had to take the online drivers education course at http://www.driversed.com, which is the only online traffic school accepted by Santa Clara County.

Important test taking facts (it’s smart to read them all):

1. You can take the tests as many times as you want.
2. If you fail a test they provide you with the correct answers and then you can retake it.
3. Each test is 4 questions.  It appears that the database only has 6 available questions.  On each test retry a new question is introduced.  After failing the test 3 times you will have all the questions and answers to pass the test on the 4th try.
4. Important: Take the HTML version (not the flash).  Fact #5 explains in detail why.
5. In order to take a test you have to click through several pages of text which all have timers associated to them.  For example, a full page of text may be a 2 minute timer which prevents you from continuing until you have stayed on the page for a minimum of 2 minutes.  This is an attempt to make sure you actually read the content on each page.  It is very annoying, and painful.  If you have to wait for all of the timers I’m guessing it will probably take 8 hours to complete the online driving school.  After waiting for about 10 minutes I realized I better find a solution to this.  I viewed the page source and noticed the timer is client side based javascript.  Great news, lets disable Javascript in the browser!  In Firefox click on Tools -> Options… -> Content tab, uncheck the ‘Enable Javascript’ checkbox, click Ok.  Voila, no more timers!!
6. If you ever get a blank page while taking this course, you should enable javascript again.  There are a few movies to watch which require javascript.  Just enable it and refresh the page.
7. Movies can’t be skipped.  I suggest watching your own movie on TV while the lame driver’s ed movie is playing in your web browser.  Just remember to mute the volume
8. You can always quit and resume the test at a later time.  Your work won’t be lost.

Read more…

Phil Uncategorized

I had several problems while attempting to set up a samba share.  Well, actually setting up the share was the easy part, but the client wasn’t able to do much.  I’m going to list the configuration which ended up working for me.

Step 1 - Edit /etc/samba/smb.conf

[public]
        comment = Public Stuff
        path = /var/share
        public = yes
        writable = yes
        browsable = yes
        printable = no
        write list = +nobody
        guest ok = Yes
        guest account = nobody

Step 2 - Create the shared directory and set proper permissions

mkdir /var/share
chown -R nobody /var/share
chgrp -R nobody /var/share
chmod -R -u +rwx /var/share

Step 3- The most important step that caused me a headache…

chcon -R -t samba_share_t /var/share/

SELinix, which I have a lack of knowledge on, adds a security context (label) to files and directories. In order to get this running you have to change the label to “samba_share_t”

The other option is to disable SELinux, but it’s probably not a good idea if your box will be available publicly.

Step 4 - Restart SAMBA

service smb restart

Phil Uncategorized

This will probably be an ongoing post as I begin to use the spring form taglibs more and more. I’ll try to post examples and hints here.

Lesson #1 - the options tag

If you are using a Map as your “items” then the itemLabel and itemValue attributes are ignored. The option value will be automatically populated with your map key and the option label will be populated with your map value.  Don’t waist your time trying to use the itemLabel and itemValue.  If you need to change the default behavior try using collection of simple beans instead, or extend the options tag so it will make use of itemLabel and itemValue for Maps.

Phil Uncategorized

I recently had to develop a web service based application, and decided to use jax-ws with the Metro stack on Jboss.

It took me some time to figure out all the rules when using the @WebService annotation on an interface.
After some trial an error, and with the help of this IBM document I think I have most of it figured out.   I put together this short post on my findings and I hope someone will  find it useful.

Declaring @WebService on an interface

• All public methods in your web service interface will be exposed as a web method.  You can’t use the “exclude” attribute on the @WebMethod annotation inside the web service interface.  This means you need to declare the method as private or completely remove it from your interface if you don’t want the WSDL generated for it.
• The attributes portName and serviceName are not allowed on the @WebService annotation declared on the interface.  If you plan to use them, they belong on the web service implementation class.
• The actual implementation class must contain @WebService with the required attribute endpointInterface.  The endpointInterface needs to be the fully qualified name of your web service interface.
• The web service implementation class can not contain @WebMethod
• It is not mandatory to have your implementation class “implement” the interface.

Skipping the WebSerivce interface, and directly annotating the implementation class:

• @WebService should be declared on the class.  You can not use the “endpointInterface” attribute since there is no reference interface.
• @WebMethod needs to be declared on all methods, use the “exclude=true” attribute if you don’t want it to be part of the web service.  If you don’t declare @WebMethod then all public methods will be exposed, including any inherited methods.

Another useful note on @WebMethod: To ensure interoperability with Windows Communication Foundation (WCF) clients, you must specify the action element of @WebMethod in your endpoint implementation classes. WCF clients will incorrectly generate an empty string for the Action header if you do not specify the action element.

Development Platform: JBoss 4.2.3.GA with the JAX-WS RI Metro 2.1.4 stack.

Phil java, jax-ws @WebMethod, @WebService, endpointInterface, jax-ws, Web Service

By default the ResourceBundleViewResolver will attempt to load your resource bundle by searching the root of your classpath - in a web application this will be WEB-INF/classes

If you get the error java.util.MissingResourceException: Can’t find bundle for base name views it’s caused because your resource bundle can’t be loaded.

The quick fix is to place your resource bundle inside WEB-INF/classes and you will be good to go.

However, if you tend to be more organized and would like to store them in a custom directory you need to change the “basename” value to reflect this accordingly.  Assume you want to store public-views.properties in WEB-INF/classes/spring-config/views.  Your basename should be a dot/period separated string denoting the location of your resource bundle from the root of your classpath.

Here is a sample:

<bean id="propertiesViewResolver"
      class="org.springframework.web.servlet.view.ResourceBundleViewResolver">
   <property name="order" value="1"/>
   <property name="basename" value="spring-config.views.public-views"/>
</bean>

Hope someone finds this useful.

-phil

Phil Spring java.util.MissingResourceException, resource bundle can't be loaded, ResourceBundleViewResolver, Spring

This is my first blog, so I will do my best to help you other java/spring geeks out there.

The other day I was trying to configure a DispatcherServlet to include two view resolvers.

1. UrlBasedViewResolver for returning Tile views
2. InternalResouceViewResolver for returning JSTL views (or just some jsp pages with no controllers)

Both implement the Order interface so I immediately assumed to place an order on the tilesViewResolver as 0 and an Order on the jstlViewResolver as 1.  My thinking was a Tiles view would first be attempted to be resolved, and if it failed (return null) it would pass control to the next view resolver in the chain which was my jstlViewResolver (InternalResourceVieewResolver).

Ok…done, lets give this a whirl.

I hit the web page and BAM!

Request processing failed; nested exception
is org.apache.tiles.definition.NoSuchDefinitionException

What happened was the view wasn’t resolved by the tilesViewResolver (UrlBasedViewResolver) and instead of continuing down the view resolver chain it threw this Exception.
So I checked into the java docs and found this interesting note:

Note: When chaining ViewResolvers, a UrlBasedViewResolver always needs to be last, as it will attempt to resolve any view name, no matter whether the underlying resource actually exists.

The InternalResourceViewResolver is a subclass of UrlBasedViewResolver so now I need to figure out how both of these view resolvers can coexist since they both need to be “last” in the chain.

I dug into the source code:

protected View createView(String viewName, Locale locale) throws Exception {
   	// If this resolver is not supposed to handle the given view,
   	// return null to pass on to the next resolver in the chain.
   	if (!canHandle(viewName, locale)) {
   		return null;
   	}
        ...
}

So the first part is to notice the canHandle() method.  If canHandle() returns false then the view resolver will return null and the next view resolver in the chain will be executed.  Now lets dig into the canHandle() method:

protected boolean canHandle(String viewName, Locale locale) {
	String[] viewNames = getViewNames();
	return (viewNames == null || PatternMatchUtils
                                     .simpleMatch(viewNames, viewName));
}

The bell went off here. I can inject a pattern for the viewNames in my XML configuration. If this pattern isn’t met then it will return null and attempt to resolve the view using the InternalResourceViewResolver.

As a best practice I have always prefixed my Tiles views with a period (.index, .login, etc). So for me it was straight forward to accomplish by creating a pattern “.*”
So the key in the configuration of the tilesViewResolver is to add in <property name=”viewNames” value=”.*”/>

Here is my final configuration:

<bean id="tilesViewResolver"
      class="org.springframework.web.servlet.view.UrlBasedViewResolver">
    	<property name="order" value="0"/>
    	<property name="requestContextAttribute" value="requestContext"/>
    	<property name="viewClass"
    		value="org.springframework.web.servlet.view.tiles2.TilesView"/>
    	<property name="viewNames" value=".*"/>
</bean>
<bean id="jstlViewResolver"
		class="org.springframework.web.servlet.view.InternalResourceViewResolver">
		<property name="order" value="1"/>
		<property name="viewClass">
			<value>org.springframework.web.servlet.view.JstlView
			</value>
		</property>
		<property name="prefix">
			<value>/WEB-INF/jsp/public</value>
		</property>
		<property name="suffix">
			<value>.jsp</value>
		</property>
</bean>

Now if I’m visiting a page that isn’t in the Tiles Definition the UrlBasedViewResolver will gracefully return null and the InternalResourceViewResolver will attempt to resolve the view.

No coding, just configuration (…and following a naming convention for your Tiles). Hope this helps others out there.

Phil Spring, java apache tiles, internalresourceviewresolver, java, org.apache.tiles.definition.NoSuchDefinitionException, Spring, urlbasedviewresolver