Igor Kromin |   Consultant. Coder. Blogger. Tinkerer. Gamer.

The 1934 Packard Twelve Convertible is a model kit from the vehicles collection over at Fascinations/Metal Earth. This is a fairly advanced level kit and certainly takes time to put together. There's some very impressive detail included too - it has both the exterior and the interior of the car modelled, very nice!

The end result is very cool and the deep red paint finish combined with the cream cover and interior really make this model stand out.
IMG_2949.jpg


So what's in the kit? Well it's a two and a half sheet kit and there are two sheets worth of instructions. Instructions are fairly sparse compared to other bigger kits, but that doesn't mean there isn't much to do when assembling this model.

IMG_2922.jpg IMG_2924.jpg


The half metal sheet in this kit is different to the two full sheets in a way that it is thicker. Parts from this sheets are used to make the interior and wheel white-walls, so the extra thickness helps make more rigid sections. I actually rather liked how thick these parts were because details, especially on the interior were etched deeper.

IMG_2925.jpg IMG_2926.jpg


Continue reading...  

, ,

When trying to log into a website recently I've ran into an error - Bad Request - Size of a request header field exceeds server limit: Cookie. Immediately I opened the developer console and skipped over to the storage tab (in Safari). It showed me a thriving population of cookies living in my browser cache for the domain that website was running on.
badreq_1.png


The number of cookies was out of control and one was fairly large. Overall the total size of the cookies was well over 4kb. This doesn't seem like much, but RFC6265 only provisions for numbers in this area.
badreq_2.png


So I deleted the largest cookie and then was able to log in. Easy.
badreq_3.png


This kind of error bothers me though because it could have been very easily prevented. There are multiple parties that can be blamed in this case - the application developer, the server administrator, the web browser developer. Who is really to blame though? I say the majority responsibility is with the application developer but other parties can also help to improve user experience.

At least there is a way forward by manually deleting cookies! 🍪

Continue reading...  

, ,

Swap space, it's needed at times and can be a real pain at others. It is a necessary evil that has to be put up with however. I've recently had to monitor how much swap space various processes have been using on a Linux system and found that top was the best and quickest option for doing so.

By default however, top does not show swap space details...
top_1.jpg


That's easily remedied by pressing the 'F' (capital f) key followed by 'p' and then enter.
top_2.jpg


This tells top to sort processes using the swap space column and at the same time this also displays the swap space usage. Neat!
top_3.jpg


Continue reading...  

,

While migrating both JAX-RS and JAX-WS web services from WebLogic 12.1 to 12.2 I've come across an issue during deployment. The error "java.util.ServiceConfigurationError: javax.xml.stream.XMLInputFactory: Provider com.ctc.wstx.stax.WstxInputFactory not a subtype" kept on coming up. The particular service in question wasn't using StAX but we've played around with changing various providers during this upgrade so I thought that was the root cause. It wasn't.

Here's a redacted version of the error message seen during deployment...
 Error
Failed to execute goal com.oracle.weblogic:weblogic-maven-plugin:12.2.1-3-0:deploy (wls-deploy) on project zzzz: weblogic.Deployer$DeployerException: weblogic.deploy.api.tools.deployer.DeployerException: Task 75 failed: [Deployer:149026]deploy application zzzz on zzzz.
Target state: deploy failed on Server zzzz
java.util.ServiceConfigurationError: javax.xml.stream.XMLInputFactory: Provider com.ctc.wstx.stax.WstxInputFactory not a subtype
at weblogic.Deployer.run(Deployer.java:76)
at weblogic.Deployer.mainWithExceptions(Deployer.java:63)
at weblogic.tools.maven.plugins.deploy.DeployMojo.execute(DeployMojo.java:342)
...
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)


Turned out the issue was to do with class loading and specifically what weblogic.xml contained. Because these services were using Oracle Coherence from WebLogic 12.1 they were providing a tangosol-coherence-override.xml file as part of the WAR package. This required the prefer-web-inf-classes element in weblogic.xml to be set to true. This caused the StAX exception to be thrown.

Setting prefer-web-inf-classes to false resolved the issue...
 weblogic.xml
<container-descriptor>
<prefer-web-inf-classes>false</prefer-web-inf-classes>
</container-descriptor>


So either something in the WLS class loader structure changed between 12.1 and 12.2 or some other dependencies changed, I've not tried to track it down too hard. What about Coherence and the override file? Well it looks like due to these changes in WLS 12.2 that certain services are not able to make use of this feature any more. I'll have a separate article on that and a couple of workarounds to deal with it too.

-i

, , , ,