Jagadish and Sivakumar,
thank you for your kind help. Please find my answers inlined.
>I cannot believe that ignoring SEVERE log entries and stack traces shall really be the officially planned way to deploy embedded RARs!? Isn't >there a way to automatically create a pool and resource by just deploying the app, e. g. by providing some more information to the annotation >or to the deployment descriptor? I do not believe that our customers will be happy if I tell them they must ignore a stack trace at >deployment.
>Is this happening in an MDB ?, in any case can you post the pseudo-code of how do you inject and where the resource is being used ?
Yes this is happening in an MDB. Here is the code. Currently it is only injected but not used (usage code was removed temporarily as soon we experienced problems):
@Resource(name = "QUIPSY_KERNEL")
private KernelConnectionFactory kernelConnectionFactory;
>Also it is some kind of strange that after undeploy of my EAR the pool and resource is still there. Since in turn the embedded RAR is >undeployed, too, what sense does that make? Doesn't that lead to errors? Since it looks like the resource configuration is shared by all apps >(what must not happen with an embedded (!) RAR) that means that other apps will "see" my embedded RAR even after it got deployed?!
>resources/pools created for embedded rars are available only for the enclosing .ear. No other app. can refer to them.
But how to see the difference on the screen? I mean, I provide a JDNI name to the resource, just as I do for global ones. So is that JNDI name private to that application or what will happen if another application does lookup for that JNDI name?
>http://docs.sun.com/app/docs/doc/819-3672/bealp?a=view
>Dev Guide > Developing app & app components > developing connectors > redeploying stand-alone connector modules
>states that resources/pools can exist though .rar is undeployed. I guess, the same is applicable for embedded .rars also.
I am not redeploying but undeploying and deploying again. That's a far difference.
Thanks
Markus