[Design of Messaging on JBoss (Messaging/JBoss)] - Re: creating integration layer
by ataylor
I've checked in the refactoring for the new integration layer etc. Each layer is compiled separately and the result added to a separate jar, so we have.
JBM core, Core now has no dependencies on anything else. The resulting classes are archived in jbm-core.jar and jbm-client-core.jar. The latter still needs tidying up as it still contains some classes that probably should only be server side.
Transports. The netty and mina implementations of remoting now live under org.jboss.messaging.integration.transports. They depend on core and obviously netty and mina for compilation. These are the archived to jbm-transports.jar. I've left the invm transport in core i wasn't sure whether to do that or move it as well. If i do move then at least the pckage names would be consistent, wdyt?
Security, The jbossas security manager has been moved to org.jboss.messaging.integration.security. Again I've left the basic security manager in core as it has no dependencies, I'll move this if we decide to move the invm transport to be consistent.
Logging, Logger now uses java.util.Logger. I've also added to handlers under org.jboss.messaging.logging, one for the jboss logger and one for log4j. These can be used by changing the handlers configured in logging.properties under jre/lib. Ive added one under src/etc that uses the jboss logge We need this for when we bootstrap using the MC since if we don't provide a jboss logger plugin, aop defaults all of its logging to stdout. the tests/examples etc use the default java.util.logger.
I still have a bit more tidying up to do, i need to test all the examples etc still work. Any issues let me know.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188751#4188751
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188751
17 years, 4 months
[Design of JBoss Web Services] - Maven Dependencies Real Problem
by richard.opalka＠jboss.com
Relates to: JBWS-2376
Current Solution:
JBossWS allows to deploy multiple SOAP stacks (Metro, CXF and Native) to multiple JBossAS servers (4.2.x and 5.0.x).
To easily integrate different SOAP stacks with different AS versions we have a deploy magic implemented in each stack. This deployment magic consists of two steps:
* deploy-artifacts directory creation (containing jar files and other artifacts that will be deployed)
* deploy procedure using the artifacts created in previous step that integrates SOAP stack to particular AS
We also reuse this integration magic in AS code base:
* where step 1 is omited there because deploy-artifacts directory is AS/thirdparty directory in such case
* step 2 is slightly modified to don't deploy container integrations jars (these are created in JBossAS webservices module build process)
Identified problem:
We have to emulate AS/thirdparty directory structure to have full control of the jars that will get deployed to AS (because of reused macro).
AS/thirdparty dir is created by maven-buildmagic-thirdparty-plugin that copies all dependencies to thirdparty dir. This leads to multiple artifacts with the same name present in different directories (e.g. jaxb-api.jar).
Thus our deployment macro is error prone because:
* we need to watch for changes in AS/thirdparty/pom.xml and any new mappings introduced there must be applied to all three stacks deploy macros (because we have to emulate AS thirdparty directory structure)
* deployment macro have to use groupId/artifactId includes instead of wildcars **/artifactId (to match particular artifact and to allow us to have the control over the jars that will get really deployed)
Questions:
How to do it properly? Any opinions or suggestions?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188749#4188749
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188749
17 years, 4 months
[Design of Messaging on JBoss (Messaging/JBoss)] - JBMESSAGING 1.4 Test failures -- JGroup upgrade issue?
by gaohoward
Hi guys,
I'm running tests in jbm14 branch. The tests are ok when i set integration.base=EAP4. But when I set integration.base=AS5, some tests failed, mostly in clustering tests. I found the some stack trace (see below), and i'm thinking may be it's the JGroup problem (I see we use 2.4.4.GA-brew for EAP4 and 2.6.6.GA for AS5).
Can anyone shed some light on it? Thanks.
Stack:
###################################### Start IN-VM test: testClusteredBindUnbind
[junit] @main 17:29:45,346 INFO [ServiceContainer] Starting arjuna tx mgr
[junit] @main 17:29:45,346 INFO [InVMContext] Binding java:/TransactionManager obj Transaction: unknown rebind false
[junit] @main 17:29:45,346 INFO [InVMContext] Binding UserTransaction obj org.jboss.tm.usertx.client.ServerVMClientUserTransaction@b9e45a rebind true
[junit] @main 17:29:45,347 INFO [ServiceContainer] connection url:jdbc:mysql://localhost/messaging
[junit] @main 17:29:45,347 INFO [ServiceContainer] driver:jdbc:mysql://localhost/messaging
[junit] @main 17:29:45,347 INFO [ServiceContainer] username:sa
[junit] @main 17:29:45,347 INFO [ServiceContainer] password:null
[junit] @main 17:29:45,372 INFO [InVMContext] Binding DefaultDS obj org.jboss.resource.adapter.jdbc.WrapperDataSource@3251c7 rebind true
[junit] @main 17:29:45,372 INFO [WrapperDataSourceService] Bound ConnectionManager 'jboss.jca:name=DefaultDS,service=DataSourceBinding' to JNDI name 'java:/DefaultDS'
[junit] @main 17:29:45,372 INFO [ServiceContainer] DELETING ALL DATA FROM DATABASE!
[junit] @main 17:29:45,383 INFO [ServiceContainer] creating server for: bisocket://localhost:6296/?marshaller=org.jboss.jms.wireformat.JMSWireFormat&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat&dataType=jms&socket.check_connection=false&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&serverSocketClass=org.jboss.jms.server.remoting.ServerSocketWrapper&numberOfCallRetries=1&pingFrequency=214748364&pingWindowFactor=10&stopLeaseOnFailure=true&clientLeasePeriod=10000&validatorPingPeriod=10000&validatorPingTimeout=5000&timeout=0&connectionWait=10&JBM_clientMaxPoolSize=200
[junit] @main 17:29:45,411 INFO [InVMContext] Binding messaging-securitydomain obj org.jboss.test.messaging.tools.container.MockJBossSecurityManager@fa7cd3 rebind false
[junit] @main 17:29:45,412 INFO [ServiceContainer] Could find multiplexer config
[junit] @main 17:29:45,415 INFO [ServiceContainer] Remoting type: .............. bisocket
[junit] @main 17:29:45,415 INFO [ServiceContainer] Clustering mode: ............ NON-CLUSTERED
[junit] @main 17:29:45,415 INFO [ServiceContainer] Persistence config file: .... server/default/deploy/mysql-persistence-service.xml
[junit] @main 17:29:45,423 INFO [ClusteredPostOfficeTest] Creating clusteredPostOffice node 1
[junit] @main 17:29:45,427 INFO [ServiceContainer] Persistence config file: .... server/default/deploy/mysql-persistence-service.xml
[junit] @main 17:29:45,432 INFO [JChannel] JGroups version: 2.6.6.GA
[junit] @main 17:29:45,434 INFO [JChannel] JGroups version: 2.6.6.GA
[junit] @main 17:29:45,436 WARN [UDP] could not bind to /228.11.11.11 (IPv4 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6).
[junit] Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details).
[junit] Exception was: java.net.BindException: Cannot assign requested address
[junit]
[junit] -------------------------------------------------------
[junit] GMS: address is 127.0.0.1:54015
[junit] -------------------------------------------------------
[junit] @main 17:29:47,439 INFO [GroupMember] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener@584ce6 got new view [127.0.0.1:54015|0] [127.0.0.1:54015], old view is null
[junit] @main 17:29:47,439 INFO [GroupMember] I am (127.0.0.1:54015)
[junit] @main 17:29:47,439 INFO [GroupMember] New Members : 1 ([127.0.0.1:54015])
[junit] @main 17:29:47,439 INFO [GroupMember] All Members : 1 ([127.0.0.1:54015])
[junit] @main 17:29:47,440 WARN [MPING] could not bind to /228.6.6.6 (IPv4 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6).
[junit] Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details).
[junit] Exception was: java.net.BindException: Cannot assign requested address
[junit]
[junit] -------------------------------------------------------
[junit] GMS: address is 127.0.0.1:7900
[junit] -------------------------------------------------------
[junit] @main 17:29:52,444 INFO [ClusteredPostOfficeTest] Creating clusteredPostOffice node 2
[junit] @main 17:29:52,447 INFO [ServiceContainer] Persistence config file: .... server/default/deploy/mysql-persistence-service.xml
[junit] @main 17:29:52,451 INFO [JChannel] JGroups version: 2.6.6.GA
[junit] @main 17:29:52,453 INFO [JChannel] JGroups version: 2.6.6.GA
[junit] @main 17:29:52,454 WARN [ClusteredPostOfficeTest] org.jgroups.ChannelException: failed to start protocol stack
[junit] org.jgroups.ChannelException: failed to start protocol stack
[junit] at org.jgroups.JChannel.startStack(JChannel.java:1555)
[junit] at org.jgroups.JChannel.connect(JChannel.java:365)
[junit] at org.jboss.messaging.core.impl.postoffice.GroupMember.start(GroupMember.java:139)
[junit] at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.start(MessagingPostOffice.java:357)
[junit] at org.jboss.test.messaging.core.PostOfficeTestBase.createClusteredPostOffice(PostOfficeTestBase.java:98)
[junit] at org.jboss.test.messaging.core.PostOfficeTestBase.createClusteredPostOffice(PostOfficeTestBase.java:162)
[junit] at org.jboss.test.messaging.core.postoffice.ClusteredPostOfficeTest.testClusteredBindUnbind(ClusteredPostOfficeTest.java:217)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:585)
[junit] at junit.framework.TestCase.runTest(TestCase.java:164)
[junit] at junit.framework.TestCase.runBare(TestCase.java:130)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:124)
[junit] at junit.framework.TestResult.run(TestResult.java:109)
[junit] at junit.framework.TestCase.run(TestCase.java:120)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:230)
[junit] at junit.framework.TestSuite.run(TestSuite.java:225)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
[junit] Caused by: java.lang.IllegalStateException: cluster 'MessagingPostOffice-CTRL' is already connected to singleton transport: [MessagingPostOffice-CTRL, dummy-1226482192453]
[junit] at org.jgroups.stack.Configurator.startProtocolStack(Configurator.java:88)
[junit] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:410)
[junit] at org.jgroups.JChannel.startStack(JChannel.java:1552)
[junit] ... 21 more
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188727#4188727
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188727
17 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Netty HTTP transport
by trustin
I have reviewed the code and made some quick modification by myself (mostly renaming and access modifier changes):
http://fisheye.jboss.org/changelog/Netty/branches/Branch_HTTP
I think there's only a couple issues left now.
1) What I meant was actually that HttpRequest.getUri() should be retained and all parameter accessor methods need to be removed. Then, HttpRequestEncoder and HttpRequestDecoder won't need to build or decode an URI at all. Just calling URI.toString() and new URI(String) would be enough.
Now assuming that we don't have any parameter accessor methods but URI property, how do we encode / decode a query in JBM? There are a few choices:
1a) Use GET method and append a usual query string to the URI. The query string is encoded by QueryStringEncoder, which replaces UriBuilder.
1b) Use POST method and put the query string into the content of the HttpMessage. The query string is encoded by QueryStringEncoder, which replaces UriBuilder.
1c) Use REST style URI and use regular expression matching. (No need for UriBuilder, UriQueryDecoder, etc)
QueryStringEncoder should be pretty much same with UriBuilder except that it builds a query string part only - it's just renaming and removing several lines.
Also, UriQueryDecoder should be renamed to QueryStringDecoder and modified to start to decode the specified String or URI from the first occurrence of '?'.
The removal of the parameter accessor methods makes HttpRequest closer to the original HTTP request message model specified by the relevant standards. There's no restriction in how a query string should look like, and we can't assume that a query string always exists in the URI - it can even exist in the content in case of POST, and actually it's entirely up to how a user wants to use HTTP. That's why I'd like to isolate query string (or parameter) processing from the core classes. A user can always use utility classes (QueryStringEncoder/Decoder) if necessary.
2) (optional - UTF-8 only support is fine at this moment) QueryStringEncoder and QueryStringDecoder should consider charsets. A sensible default could be UTF-8, but some people might want something like EUC-JP. Adding an optional charset parameter to the constructor would be just fine.
Please let me know if I am missing something.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188685#4188685
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188685
17 years, 5 months