[IronJacamar] - Embedded JCA with Glassfish
by John SMITH
stackpeek [http://community.jboss.org/people/stackpeek] created the discussion
"Embedded JCA with Glassfish"
To view the discussion, visit: http://community.jboss.org/message/573451#573451
--------------------------------------------------------------
Hi,
I'm working on the integration of IronJacamar (1.0.0.Beta3) with Glassfish (2.1.1). The aim being to use something else than Glassfish (maybe Tomcat) and continue to use our JCA connectors.
The problem I get even if I try to configure the *naming.xml* file in order to use the local JNDI context is the following exception:
Caused by: *+com.github.fungal.spi.deployers.DeployException+: Installing bean NamingBeanImpl*
at com.github.fungal.impl.DeploymentDeployer$BeanDeployer.run(DeploymentDeployer.java:300)
... 6 more
Caused by: *+javax.naming.NamingException+: java:comp namespace cannot be modified*
at com.sun.enterprise.naming.java.javaURLContext.rebind(javaURLContext.java:262)
at org.jnp.server.NamingBeanImpl.start(NamingBeanImpl.java:184)
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:597)
at com.github.fungal.impl.DeploymentDeployer$BeanDeployer.createBean(DeploymentDeployer.java:521)
at com.github.fungal.impl.DeploymentDeployer$BeanDeployer.run(DeploymentDeployer.java:286)
I modified different implementations in order to not rebind the java namespace, but when I deploy my archive (.rar), I can't find it in the JNDI context.
And when I specify a xxxxx*-ra.xml* with a *jndi-name* property in the *connection-definition* attribute, I get a +*NotSerializableException*+ from *CachedConnectionManager*.
Any idea ?
Thanks
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/573451#573451]
Start a new discussion in IronJacamar at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
[JBoss Tools] - Re: JBoss Tools 3.2.0 - ESB 4.9 - Helios - questions / problems
by Rob Stryker
Rob Stryker [http://community.jboss.org/people/rob.stryker%40jboss.com] created the discussion
"Re: JBoss Tools 3.2.0 - ESB 4.9 - Helios - questions / problems"
To view the discussion, visit: http://community.jboss.org/message/573300#573300
--------------------------------------------------------------
For item 1, I'm not sure what type of server you're using. You mention in step 2 that you are using a jboss 5.1 server type and it works. What type were you using in step 1? The only server types which supported esb 4.9 are JBoss AS 5.1, 6.0, and EAP 5.x. Other server types do not support the esb 4.9 module.
If you were using the deploy-only server type, that one also did not support esb 4.9, but, I've opened a jira and committed a fix to that. ( https://jira.jboss.org/browse/JBIDE-7743 https://jira.jboss.org/browse/JBIDE-7743)
For item 2, what do you mean the publishes aren't showing up on the server? Are the class files actually being changed in the deploy directory? Has the timestamp changed? If the timestamp has changed, Typically runtimes do not accept changed class files without restarting the module. You can do this by right-clicking the module in the server's view and selecting FULL PUBLISH. Only seam applications accept hot-code replacements without a module restart, and web projects do too for changes to jsp files or static html / xml files.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/573300#573300]
Start a new discussion in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
[JBoss Cache] - EvictionTimer Thread disapears with no log - nodeEventQueue_ growth to 100%
by Redbox Capgemini
Redbox Capgemini [http://community.jboss.org/people/redbox] created the discussion
"EvictionTimer Thread disapears with no log - nodeEventQueue_ growth to 100%"
To view the discussion, visit: http://community.jboss.org/message/573426#573426
--------------------------------------------------------------
Hi,
It's been two weeks that I have a problem with the jboss cache library.
I don't know why but it seems that one of my *EvictionTimer's Thread* just disapears without logging anything.
Normally, this thread has to empty an nodeEventQueue_ (BoundedLinkedQueue class) every N seconds.
This queue reaches 100% occupation (static int *200 000*) and then, all the threads of my application are *blocked* due to the fact that one thread tries to put an event in this already full queue and is stuck in the *Timed_Waiting* status.
This things appears several time per day, I can see that the thread is working by checking his log and sometimes, it just stops logging and if I do a Thread Dump, the thread is no more in the Thread Dump. I have noticed that each day I have the problem, this is always the same thread that disapears (in my cas Timer-10).
I've tried to tune my log4j to log some INFO and WARN but I didn't get anything interesting so far.
I've tried to put a Try Catch (RunTimeException) in the Run() method of the EvictionTimerTask but it didn't catch anything.
Stack of the thread that wants to put an event in this full queue :
Thread: http-0.0.0.0-8080-4 : priority:5, demon:true, threadId:1800, threadState:WAITING, lockName:EDU.oswego.cs.dl.util.concurrent.BoundedLinkedQueue@249c4a
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:485)
EDU.oswego.cs.dl.util.concurrent.BoundedLinkedQueue.put(BoundedLinkedQueue.java:303)
org.jboss.cache.eviction.Region.putNodeEvent(Region.java:141)
org.jboss.cache.interceptors.EvictionInterceptor.doEventUpdatesOnRegionManager(EvictionInterceptor.java:149)
org.jboss.cache.interceptors.EvictionInterceptor.updateNode(EvictionInterceptor.java:122)
org.jboss.cache.interceptors.EvictionInterceptor.invoke(EvictionInterceptor.java:97)
org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:206)
org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:379)
org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:174)
org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:138)
org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5919)
Do you have any ideas why the EvictionTimer Thread just stop working ?
*Jboss : 4.2.3 GA*
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/573426#573426]
Start a new discussion in JBoss Cache at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
[JBoss Tools] - Re: error in hot deployement 'Error renaming..'
by Rob Stryker
Rob Stryker [http://community.jboss.org/people/rob.stryker%40jboss.com] created the discussion
"Re: error in hot deployement 'Error renaming..'"
To view the discussion, visit: http://community.jboss.org/message/573404#573404
--------------------------------------------------------------
It seems as if you're using a mix of maven commands and wtp publishing. When you click the 'publish' icon inside the servers view, this will do what is called an "Incremental Publish". This means it will only publish whatever files have changed in the workspace since the last publish event. If you right-click on your module in the servers view, however, you can click "FULL PUBLISH" to republish the entire module.
So, if you do a full publish, you wil note all resources should now be synchronized and all files should have been deployed. All files should have a timestamp of t at that point. If you then wait 1 minute, modify a java file, save it, and use the publish icon or incremental publish buttons, you will note in the deploy folder that *ONLY* your .class file has changed its timestamp, and all other resources have the previous timestamp.
If you then go to the deploy folder and delete all files for this deployment, return to your eclipse workspace, modify a file or two, and click publish again (incremental), you will see that *only* the two changed files have been published. This is in fact a user-error. If the user manually deletes a publish folder and its contents outside of eclipse, there is no way for the tooling to know or expect this. This includes if the user uses some other tool such as maven which may have deleted the module's deploy folder as well. In these cases, the tooling will again try to simply do an incremental publish of only the changed files.
I'll need to look into your first problem, with the error renaming, but it seems like either there was a file lock (which would be a jboss-as problem) or the destination folder did not exist. I really don't think the folder not existing is a problem, however, because for our local copy handler, we have the following code:
if (!safeRename(tempFile, file, 10))
with safeRename doing the following:
File dir = to.getParentFile();
if (dir != null && !dir.exists())
dir.mkdirs();
So if this *is* the problem, that hte folder does not exist, it is a problem with your filesystems permissions, such that jbosstools cannot create these directories without the OS complaining. If that's the case, there doesn't seem to be much I can do. The javadoc for java.io.File.mkdirs() is the following:
/**
* Creates the directory named by this abstract pathname, including any
* necessary but nonexistent parent directories. Note that if this
* operation fails it may have succeeded in creating some of the necessary
* parent directories.
*
* @return <code>true</code> if and only if the directory was created,
* along with all necessary parent directories; <code>false</code>
* otherwise
The best I can do here is capture the return value and try to return a slightly more relevant error message, but really the java.io.File api does not tell me WHY the mkdirs failed, or why the renameTo failed... so really there's nothing I can change the error message to to make it more clear than it already is. All *I* can know is that the rename / mkdirs failed... but the API does not allow me to know why.
Hopefully the first half of this post gives you some hint as to what is going on in your current situation, but for the mkdirs / renameto error, there's not much more I can do aside from ask you to look into permissions in the folders.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/573404#573404]
Start a new discussion in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
