I am not certain if I should put a check in JSPs that use taglibs to check if the cache has been updated or not. This might be solvable by serialization and such, but it is a complex issue. So as a rule of thumb do not change the TagLibrary deployment where the bean code is in the deployment jar itself without bouncing the server. This package is not needed to generate the Java files, but code accessing this package will show up in the generated scripts. Even request time attributes for extraneous attributes are forwarded to the bit bucket unless the spec states that the attribute is part of the expected set.
All information is introspected at translation time.
Appropriate bean code is inserted into the generated servlet code. Besides, after the first time a servlet is run the info will become static inside the JVM until the page is reloaded on the server. Step 3 the java.lang.ClassCastException raised shall be raised at the level of the page, thus letting it fall through if the page has no handling for ClassCastException. This will likely cause a request time page error. It appears that this is what the spec states should happen.