June 2009 - jboss-dev-forums - Jboss List Archives

by swami_venkat

The Registry is a mechanism through which loose coupling and location transparency can be achieved apart from EPR availability. The Registry default provided is based on jUDDI with different embedding strategies described in the programmers and services guide. Integrations with other registries such as HP SOA Systinet do exist but lacking the embedded/local integration. Through service binding other transports can also be registered [An example would be JMS] Ideally, you should be using the ServiceInvoker abstraction and not having to deal directly with the registry View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237775#4237775 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237775

17 years

1
0
0 / 0

[Design of Management Features on JBoss] - Re: EJB3 managed component names and types

by ALRubinger

I've integrated into Branch_5_x jboss-ejb3-metrics-deployer which passes Ian's acceptance tests. Still need to: * Do the EAR tests * The MDB tests * Entity tests (as recently requested in JBAS-7008 comment). Will look into those tomorrow evening; I'm off of dev during the day this week only for RHCT training. S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237772#4237772 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237772

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBoss Reflection Questions

by flavia.rainone＠jboss.com

"alesj" wrote : But yeah, this is not a priority. | Although it would be nice to finish this once. ;-) I created a Jira issue for this one: https://jira.jboss.org/jira/browse/JBREFLECT-54 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237749#4237749 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237749

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassPool for JBoss Reflection

by flavia.rainone＠jboss.com

"alesj" wrote : I would go with choice #1. :-) Done: https://jira.jboss.org/jira/browse/JBREFLECT-3 I still think that I'm going to update this jira description once again or add commentaries, once I have a better idea of what really needs to be done. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237746#4237746 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237746

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassPool for JBoss Reflection

by flavia.rainone＠jboss.com

"kabir.khan(a)jboss.com" wrote : The classpools from asintegration-mc could be put into another jar, although I am not sure if jboss-reflect is the right place for them. Maybe they should be put into another project. This is a question whose answer I don't know. I thought it belonged to JBoss Reflect, as there is a task to create an appropriate class loader (JBREFLECT-3). Isn't those class pools all that is needed to make JBoss Reflect/Javassist to work on the AS environment? "kabir.khan(a)jboss.com" wrote : Also, due to the workings of AOP, they extend AOPClassPool from the aop project, which in turn extends ScopedClassPool from javassist. | | Ideally we should have one jar for the classpool from aop, one for the classpool from asintegration-core, one for the one from asintegration-jmx and one for asintegration-mc. | | AOPClassPool and the ClassPoolFactories have some dependencies on the AspectManager, but it should be possible to abstract that out. Yes, I can refactorate that, and extract the dependencies to a ClassPool wrapper, if we decide to go this way. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237745#4237745 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237745

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Deadlock on pinger (recent commit)

by timfox

I fixed this exact same one last week, then regressed it. Anyhow, should be fixed now. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237725#4237725 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237725

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Deadlock on pinger (recent commit)

by clebert.suconic＠jboss.com

I forgot to say, this aways happens when you run NettySynchronousCloseTest. (so it is easy to replicate it) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237723#4237723 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237723

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Deadlock on pinger (recent commit)

by clebert.suconic＠jboss.com

The latest commit on Pinger introduced a deadlock. It looks like easy to fix though. | Java stack information for the threads listed above: | =================================================== | "Thread-4 (group:JBM-scheduled-threads-331781542)": | at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.exceptionCaught(MessagingChannelHandler.java:103) | - waiting to lock <0x00007f7488dc0610> (a org.jboss.messaging.integration.transports.netty.NettyAcceptor$MessagingServerChannelHandler) | at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:147) | at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567) | at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803) | at org.jboss.netty.handler.codec.frame.FrameDecoder.exceptionCaught(FrameDecoder.java:206) | at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:129) | at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567) | at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562) | at org.jboss.netty.channel.Channels.fireExceptionCaught(Channels.java:607) | at org.jboss.netty.channel.socket.nio.NioWorker.cleanUpWriteBuffer(NioWorker.java:577) | - locked <0x00007f7488dc0848> (a java.lang.Object) | at org.jboss.netty.channel.socket.nio.NioWorker.write(NioWorker.java:326) | at org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:140) | at org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:79) | at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:791) | at org.jboss.netty.channel.SimpleChannelHandler.writeRequested(SimpleChannelHandler.java:309) | at org.jboss.netty.channel.SimpleChannelHandler.handleDownstream(SimpleChannelHandler.java:271) | at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:590) | at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:585) | at org.jboss.netty.channel.Channels.write(Channels.java:878) | at org.jboss.netty.channel.Channels.write(Channels.java:826) | at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:236) | at org.jboss.messaging.integration.transports.netty.NettyConnection.write(NettyConnection.java:128) | at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.send(RemotingConnectionImpl.java:1056) | - locked <0x00007f7488dc1ce0> (a java.lang.Object) | at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.send(RemotingConnectionImpl.java:1006) | at org.jboss.messaging.core.remoting.impl.Pinger.run(Pinger.java:122) | - locked <0x00007f7487faaef8> (a org.jboss.messaging.core.remoting.impl.Pinger) | 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) | "New I/O server worker #1-1": | at org.jboss.messaging.core.remoting.impl.Pinger.close(Pinger.java:130) | - waiting to lock <0x00007f7487faaef8> (a org.jboss.messaging.core.remoting.impl.Pinger) | at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl.closeConnection(RemotingServiceImpl.java:399) | at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:319) | at org.jboss.messaging.integration.transports.netty.NettyAcceptor$Listener.connectionDestroyed(NettyAcceptor.java:458) | at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.channelDisconnected(MessagingChannelHandler.java:85) | - locked <0x00007f7488dc0610> (a org.jboss.messaging.integration.transports.netty.NettyAcceptor$MessagingServerChannelHandler) | at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:137) | at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567) | at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803) | at org.jboss.netty.handler.codec.frame.FrameDecoder.cleanup(FrameDecoder.java:304) | at org.jboss.netty.handler.codec.frame.FrameDecoder.channelDisconnected(FrameDecoder.java:194) | at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:119) | at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567) | at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562) | at org.jboss.netty.channel.Channels.fireChannelDisconnected(Channels.java:496) | at org.jboss.netty.channel.socket.nio.NioWorker.close(NioWorker.java:520) | at org.jboss.netty.channel.socket.nio.NioWorker.close(NioWorker.java:321) | at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:307) | at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255) | at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176) | at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72) | at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49) | 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) | | Found 1 deadlock. | | I'm removing the synchronized on Pinger.close at my copy just to get the testsuite running. I will post the results here later today. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237718#4237718 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237718

17 years

1
0
0 / 0

[Design of JBoss Identity] - Re: local tx transaction or xa transaction datasource?

by anil.saldhana＠jboss.com

I will ping Jesper to comment on this one. Since we are not going to be doing any XA transactions, maybe we need local by default. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237709#4237709 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237709

17 years

1
0
0 / 0

[Design of JBoss Identity] - local tx transaction or xa transaction datasource?

by jeff.yuchang

In the JBoss idm distribution deployment. I am using the xa datasource as default, like following one as mysql one. | <?xml version="1.0" encoding="UTF-8"?> | <datasources> | | <xa-datasource> | <jndi-name>jbossidmDS</jndi-name> | | <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class> | <xa-datasource-property name="URL">@jdbc.url@</xa-datasource-property> | <user-name>@jdbc.username@</user-name> | <password>@jdbc.password@</password> | | |  | <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation> |  | <no-tx-separate-pools /> |  | <track-connection-by-tx /> | |  | <exception-sorter-class-name> | com.mysql.jdbc.integration.jboss.ExtendedMysqlExceptionSorter | </exception-sorter-class-name> | <valid-connection-checker-class-name> | com.mysql.jdbc.integration.jboss.MysqlValidConnectionChecker | </valid-connection-checker-class-name> | |  | <metadata> | <type-mapping>mySQL</type-mapping> | </metadata> | </xa-datasource> | | </datasources> | Was wondering is it better that we used the local-tx datasource as default, or use the xa-datasource as now. What do you think? Thanks Jeff View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237700#4237700 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237700

17 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2009