Turn off variable replacement in SQL+

set define off;

Drop Column

alter table <tablename> drop column <column_name>
Also look here.

Rename Column

alter table <tablename> rename column <column_name_old> to <column_name_new>;

Using SQL+ Command Line tool

Connect:

connect scott/tiger

Excecute a sql-file

@path/to/myscript.sql
also see this

The Logfiles then hinted me, that Hibernate chose the SequenceHiLoGenerator for ID Generation.

Looking through the web here, here and here , I came  close to understanding the algorithm.

The idea is to not touch the DB everytime an ID is needed but to “reserve” a block of numbers, using 50 as a default block size. Reservation is done by: 50*CurrentSequenceValue. Then Hibernate adds 1 to this base value everytime a new id is needed. When it has added 50 times, a new block is reserved using a fresh sequence value.

Perhaps this picture makes it clearer:

All of this configurable of course. I am a little surprised that this is the Hibernate default though.

@EJB(beanName="MyStalelessSessionBean")
public void IMyStalelessSessionBean (IMyStalelessSessionBean myStalelessSessionBean ) {
this.myStalelessSessionBean = myStalelessSessionBean ;
}
}

Looked quite ok to me, deployment on the Weblogic server went well. So I should be ready to rock!
But, after I put something meaningful in my queue, onMessage() was not called, instead I was greeted by:

#### <> <> <> java.lang.IllegalArgumentException: argument type mismatch.
java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.bea.core.repackaged.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:121)
at com.bea.core.repackaged.springframework.jee.inject.MethodInjection.apply(MethodInjection.java:47)
at com.bea.core.repackaged.springframework.jee.inject.Jsr250Metadata.applyInjections(Jsr250Metadata.java:233)
at com.bea.core.repackaged.springframework.jee.inject.Jsr250Metadata.inject(Jsr250Metadata.java:218)
at weblogic.ejb.container.injection.EjbComponentCreatorImpl.injection(EjbComponentCreatorImpl.java:131)
at weblogic.ejb.container.injection.EjbComponentCreatorImpl.getBean(EjbComponentCreatorImpl.java:74)
at weblogic.ejb.container.manager.BaseEJBManager.createNewBeanInstance(BaseEJBManager.java:216)
at weblogic.ejb.container.manager.BaseEJBManager.allocateBean(BaseEJBManager.java:233)
at weblogic.ejb.container.manager.MessageDrivenManager.createBean(MessageDrivenManager.java:286)
at weblogic.ejb.container.pool.MessageDrivenPool.createBean(MessageDrivenPool.java:165)
at weblogic.ejb.container.pool.MessageDrivenPool.getBean(MessageDrivenPool.java:90)
at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:434)
at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:371)
at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:327)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4072)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:3964)
at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:4490)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:464)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)

IllegalArgumentException while calling onMessage! WTF! I was quite lost!
Tweaked the @MessageDriven-annotation and doublechecked the correct signature of onMessage. But no success!
After a while I set an ExceptionBreakpoint for IllegalArgumentException and found myself in the middle of JEE internals. Reflection all the way!

Eventually I found the culprit:
The stateless session bean I wanted to be injected seemed to be null.
Removed that code temporarily. And bang! onMessage was called. After fixing the injection everthing worked well.

But to cut a long story short:
What does an IllegalArgumentException do to help me under that circumstances. My mistake had no obvious connection to the onMessage-method.
Something more meaningful would be highly appreciated and would have saved me a lot of time.
But still it is always a little fun to me, to finally get my head around something like that ;)

• Check your IDs
• Check them again
• Does your product contain all nessesary Plugins/Features
• Does your run-configuration (the one generated by selecting Run on your product) contain all your plugins? Did you press Add required plugins
• If you use features, check them! Are all plugins present?
• Help system: If your help system does not show: Double check that the Plugin-Editor did not swallow your context definitions. They are often gone if I simply open the editor. Topics do not disappear…
• Check if all help system dependencies are present in your run-configuration. Start by adding all *help*-plugins, continue with *jetty* and *servlet*. Then press Add required plugins. That should do the trick.

If you know of any other helpful tricks, please let me know!

Apologies for not updating this blog lately.

As I want to talk a little bit about my experiences with Eclipse RCP, I think it is suitable if I tried to write in english. Perhaps this can be helpful for non-german speakers aswell, as information/documentation about E-RCP is a little sparse.

So… lately I had the chance to be a part of a Eclipse RCP project, which I greatly looked forward to! As I took a deep-dive into the concepts, I noticed that things work very differently compared to web-applications or even Swing applications.

In case you are interested, I mostly refered to 2 books, namely

• Die Eclipse Rich Client Platform: Entwicklung von erweiterbaren Anwendungen mit RCP
• Eclipse Rich Client Platform: Designing, Coding, and Packaging Java Applications

Additionally there is one blog by a guy called Lars Vogel, which I appreciate very much! Thanks for the great effort Lars!

By now, our project has produced a niffty little prototype of the soon-to-be greatest RCP-application. Though none of our design decisions are written in stone yet (e.g. I am not sure whether we should use editors for our inputs or just views), I think/hope I have more or less understood the framework.

But there is at least one thing, that bothers me time and time again:

The ubiquitous Plugin ID. I cannot complain much about the basic concept: Of course a plugin has to have an unique identifier, and when you refer to a specific plugin, you have to use this Plugin ID. But again and again I have spent ages looking for some error/non-functional bits while finally noticing that I used the wrong ID.

So I could just end up blaming me. What I am missing though is some kind of assistance from the framework itself, saying “Man! You are looking for a plugin named this.is.wrong, but I only know the following plugins:…” I think that would save us a lot of time.

Lately I was implementing context-sensitive help. But I could not figure out, why hitting f1 on a text field did not do anything. This blog then showed me, where to place a proper breakpoint to take a peek into the help-listener. It showed that the context-arrays where simply empty. So no context help could be seen. At least I saw that the keybinding worked. After debugging a few hours I was basically stuck. I made a few steps back and made a small sample project. At first I experienced the same issues… is Ganymede broken? I then realized that I did not provide the Plugin ID but the package name (which had a different case). I changed cases and voila it worked. Again I debugged to the help-listener and behold: The context array had one element.

What I am asking myself right now is: Why doesn’t Eclipse tell me that it does not register my context (or puts it somewhere only it knows). Life would be easier! :) It is seldom obvious to me what happens internally, when Eclipse executes a specific functionallity. At least I need an easier way to find places to debug to.

Perhaps I’m just missing some point…

Until then I only can repeat what the aforementioned books told me before:

BE  VERY CAREFULL WHEN YOU USE PLUGIN-IDS as there is no safety net!

In einem Fehlerfall (bspw. bei einer klassischen IOException) ist diese Art Exception-Handling doch eigentlich ganz sinnvoll. Selbstverständlich haben Exceptions nichts im Kontrollfluss verloren. Ich habe vielleicht den Punkt auch noch nicht verstanden.

Sollte ich irgendwann verstehen warum (oder warum nicht), versuche ich daran zu denken, hier nochmal was zu schreiben.

Muss ich mir die Tage mal näher anschauen.