[JBoss Tools] - META-INF/application.xml is not deployed to exploded ear
by Sebastian Ehlerding
Sebastian Ehlerding [http://community.jboss.org/people/sehlerding] created the discussion
"META-INF/application.xml is not deployed to exploded ear"
To view the discussion, visit: http://community.jboss.org/message/544031#544031
--------------------------------------------------------------
Hey,
I have got a problem with the deployment via JBoss AS Tools. In my workspace is a Enterprise Application Project and a referenced Dynamic Web Project. So I use JBoss AS Tools to add the Enterprise Project and the dependent Web Project to the JBoss Server. When I start the server I get the following error:
org.jboss.deployment.DeploymentException: No META-INF/application.xml found
After looking at the deployment directory I recognized that the exploded ear contains the Web Project but no folder META-INF with the application.xml inside.
So I added the folder with the application.xml manually to the exloded Enterprise Project EAR and started the server again. This time everything works fine. The server starts without errors and it is possible to run the deployed application.
Can anyone help me with this issue? Why is the application.xml excluded from deployment?
Greets,
Sebastian Ehlerding
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/544031#544031]
Start a new discussion in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 1 month
Re: [jboss-user] [JBoss Web Services] - getPort() call takes too long
by bu jo
bu jo [http://community.jboss.org/people/bujo] replied to the discussion
"getPort() call takes too long"
To view the discussion, visit: http://community.jboss.org/message/544028#544028
--------------------------------------------------------------
Hi there!
Below is an excerpt of the org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.java class which shows the method that consumes so much time in my case. What I'd like to know is, how can I prevent the if part being executed, i.e. how can I put the portName into annotatedPorts before getPort is called? Through annotation i suppose.. but where.. on the web service interface?
*private <T> T getPortInternal(EndpointMetaData epMetaData, Class<T> seiClass) {
QName portName = epMetaData.getPortName();
// Adjust the endpoint meta data according to the annotations
* if (annotatedPorts.contains(portName) == *false) { synchronized (epMetaData) { if (annotatedPorts.contains(portName) == false) { JAXWSClientMetaDataBuilder metaDataBuilder = new JAXWSClientMetaDataBuilder(); metaDataBuilder.rebuildEndpointMetaData(epMetaData, seiClass); annotatedPorts.add(portName); } } } return (T)createProxy(seiClass, epMetaData); }**
*
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/544028#544028]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 1 month
[JBoss Tools] - EAR deployment as compressed archives results in invalid jars
by Gonne Martens
Gonne Martens [http://community.jboss.org/people/gonne] created the discussion
"EAR deployment as compressed archives results in invalid jars"
To view the discussion, visit: http://community.jboss.org/message/544021#544021
--------------------------------------------------------------
Hi,
I am using JBoss Tools 3.1 with JBossAS 6.0 M3. I have tried to deploy an ear (seam project) with the deployment option "Deploy projects as compressed archives". The result was an ear which contained some invalid jars: the content of these jars was not at the root level but inside a direcotry named as the jar. It seems that all jars are affected that were determined as module jars: e.g. jboss-seam.jar as ejb-module, mvel2.jar as client module because the manifest contains a "Main-class" entry.
I have not found an issue for that so far, so I would create one with an example.
Besides that, it looks like all archives of the resulting ear are being compressed even the jars. My expectation was only an unexploded ear containing untouched third-party jars.
Kind regards,
Gonne
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/544021#544021]
Start a new discussion in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 1 month
Re: [jboss-user] [JBoss Cache] - RejectedExecutionException on distributed cache environment
by Girish Adat
Girish Adat [http://community.jboss.org/people/girishadat] replied to the discussion
"RejectedExecutionException on distributed cache environment"
To view the discussion, visit: http://community.jboss.org/message/544018#544018
--------------------------------------------------------------
I am also getting similar exceptions as follows.
1) Following exception occured during the run without calling any API of cache in current node. This happened 21 times.
ERROR [org.jboss.cache.cluster.ReplicationQueue] failed replicating 3 elements in replication queue
java.util.concurrent.RejectedExecutionException
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1477)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:856)
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:45)
at org.jboss.cache.marshall.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:210)
at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:744)
at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:712)
at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:717)
at org.jboss.cache.cluster.ReplicationQueue.flush(ReplicationQueue.java:170)
at org.jboss.cache.cluster.ReplicationQueue$2.run(ReplicationQueue.java:114)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:142)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
2) Following happened when I tried to call the removeNode operation of core cache. This happened for ~10K times on a run with approximately 6 million removeNode() operations. But I think each time the executor skipped the entire replication queue containing large number of elements. We are using removeNode() core cache API to prevent the internalFqns to stay in cache, after the pojocache.detach() operation.
ERROR [org.jboss.cache.cluster.ReplicationQueue] failed replicating 500 elements in replication queue
java.util.concurrent.RejectedExecutionException
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1477)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:856)
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:45)
at org.jboss.cache.marshall.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:210)
at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:744)
at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:712)
at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:717)
at org.jboss.cache.cluster.ReplicationQueue.flush(ReplicationQueue.java:170)
at org.jboss.cache.cluster.ReplicationQueue.add(ReplicationQueue.java:145)
at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:145)
at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:135)
at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:107)
at org.jboss.cache.interceptors.ReplicationInterceptor.handleCrudMethod(ReplicationInterceptor.java:160)
at org.jboss.cache.interceptors.ReplicationInterceptor.visitRemoveNodeCommand(ReplicationInterceptor.java:125)
at org.jboss.cache.commands.write.RemoveNodeCommand.acceptVisitor(RemoveNodeCommand.java:125)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
at org.jboss.cache.commands.AbstractVisitor.visitRemoveNodeCommand(AbstractVisitor.java:75)
at org.jboss.cache.commands.write.RemoveNodeCommand.acceptVisitor(RemoveNodeCommand.java:125)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301)
at org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283)
at org.jboss.cache.commands.AbstractVisitor.visitRemoveNodeCommand(AbstractVisitor.java:75)
at org.jboss.cache.commands.write.RemoveNodeCommand.acceptVisitor(RemoveNodeCommand.java:125)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
at org.jboss.cache.commands.AbstractVisitor.visitRemoveNodeCommand(AbstractVisitor.java:75)
at org.jboss.cache.commands.write.RemoveNodeCommand.acceptVisitor(RemoveNodeCommand.java:125)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178)
at org.jboss.cache.interceptors.InvocationContextInterceptor.visitRemoveNodeCommand(InvocationContextInterceptor.java:88)
at org.jboss.cache.commands.write.RemoveNodeCommand.acceptVisitor(RemoveNodeCommand.java:125)
at org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287)
at org.jboss.cache.invocation.CacheInvocationDelegate.removeNode(CacheInvocationDelegate.java:478)
at org.jboss.cache.invocation.CacheInvocationDelegate.removeNode(CacheInvocationDelegate.java:485)
at [removed custom code from stack trace]
I am using CoreCache 3.2.4 GA, with JGroups 2.7.0 GA. POJO Cache version is 3.0.3 GA. I am also using 4.6.0 GA of JBossTS as transaction manager for distributed transactions.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/544018#544018]
Start a new discussion in JBoss Cache at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 1 month