August 2008 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: JBoss with spaces in the directory name

by dimitris＠jboss.org

I want to create a new jboss-common-core release and saw the failing PropertyEditorsUnitTestCase so I changed it to agree with the changes in JBCOMMON-60 and make it pass. Can you guys check this is really how this is expected to behave? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172599#4172599 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172599

17 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Message Chunking Performance problems

by ataylor

anonymous wrote : We can aways calculate how many bytes we need to send any of our packets. On ClientMessages, we just get the getEncodeSize(), and add a few bytes You're right to a certain degree, however different transport implementations may write some objects to their internal buffers slightly differently, i.e strings, utf etc. but yes we could make an educated guess as to the size of buffer we need. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172597#4172597 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172597

17 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Message Chunking Performance problems

by clebert.suconic＠jboss.com

anonymous wrote : as long as we don't allocate buffers to later dispose then I mean... as long as we don't need to allocate buffers to increase the size of a buffer. anonymous wrote : | Ive just tried running with 1k initial buffer and 1k max buffer size with remoting-tcp-nodelay set to false and the performance is good, in fact same as trunk. For instance, a 1K message (used on perfSender) will require a buffer bigger than 1K. The Buffer will need 1K to carry the message.body + extra bytes required by the encoding. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172594#4172594 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172594

17 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Message Chunking Performance problems

by clebert.suconic＠jboss.com

Why do we still need PacketImpl.INITIAL_BUFFER_SIZE? We can aways calculate how many bytes we need to send any of our packets. On ClientMessages, we just get the getEncodeSize(), and add a few bytes... Most of the other Packets have constant sizes. Looking at RemotingConnectionImpl: private void doWrite(final Packet packet) | { | if (destroyed) | { | throw new IllegalStateException("Cannot write packet to connection, it is destroyed"); | } | | MessagingBuffer buffer = transportConnection.createBuffer(PacketImpl.INITIAL_BUFFER_SIZE); | | packet.encode(buffer); | | transportConnection.write(buffer); | } | | We could add the getEncodeSize() on the Packet interface... a parameter with the size on doWrite... any other similar thing as long as we don't allocate buffers to later dispose then. At the rates we are achieving with JBossMessaging the Buffer alloc times really matters (on the tests I have made so far). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172592#4172592 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172592

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-336; empty string failure

by alex.loubyansky＠jboss.com

"adrian(a)jboss.org" wrote : "alex.loubyansky(a)jboss.com" wrote : adrian wrote : Maybe there should be some kind of @JBossXmlValue | | | annotation where we can say we want the empty string even for complex types. | | | | This alone doesn't make sense to me. I.e. the property could always be initialized to an empty string and if there was actual data it would override it. | | | | You could have the case (not this one) where you have a mixed | complex type and you want to know the value is "" | But with that annotation the value always will be "" (unless of course there is actual text data), won't it? adrian wrote : anonymous wrote : | | adrian wrote : I'd suggest an element on the annotation where you say you don't want | | | the empty string data if there are child xml elements? | | | | Yes, I was thinking you needed this one. | | | | An alternative could be a way to specify the default value (which in your case would be an empty string) in case there is no content. | | | | Except in this case, we don't to apply the default when there are other elements. | Yes, that's what I meant. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172579#4172579 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172579

17 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Management operation over JBM 2 Core API

by jmesnil

In addition to be able to manage JBM2 using JMX, it must be possible to manage a JBM server by sending "management" messages using its core API . I've some working code to do that in my local box. The idea is that the user creates a temporary queue that he will use to send management messages. | SimpleString mngmntQueue = new SimpleString("admin.MyOwnAdminQueue"); | clientSession.addDestination(mngmntQueue, false, true); | clientSession.createQueue(mngmntQueue, mngmntQueue, null, false, true); | He then create such management messages using the ClientSession: | ClientMessage msg = clientSession.createManagementAttributesMessage( | ManagementServiceImpl.getQueueObjectName(queue, queue), | "MessageCount", "Durable"); | The semantics are the same than JMX: the message above means "retrieve attributes MessageCount and Durable on the Queue identified by the ObjectName". He then sends the message: | producer.send(msg); | After that, he consumes a message on the *same* temporary queue: | ClientMessage m = consumer.receive(5000); | The message he received then contains the value of the attributes: | ManagementHelper helper = new ManagementHelper(m.getBody()); | System.out.println("MessageCount=" + helper.getProperty("MessageCount")); | System.out.println("Durable=" + helper.getProperty("Durable")); | It works almost the same to invoke a management operation: | message = clientSession.createManagementOperationMessage( | ManagementServiceImpl.getQueueObjectName(queue, queue), | "listAllMessages"); | producer.send(msg); | ... | m = consumer.receive(5000); | ... | helper = new ManagementHelper(m.getBody()); | System.out.println("operation succeeded? " + mngmntHelper.hasOperationSucceeded()); | if (!helper.hasOperationSucceeded()) | { | System.out.println("exception: " + helper.getOperationExceptionMessage()); | } | else | { | TabularData msgs = (TabularData) helper.getTabularDataProperty("listAllMessages"); | MessageInfo[] infos = MessageInfo.from(msgs); | for (MessageInfo info : infos) | { | System.out.println(info); | } | } | The result of an operation is available has a property identified by the name of the operation "listAllMessages" above. Additionally, we must check if the operation has succeeded and if not, we have a exception message to report to the user. The implementation is straightforward: the "so-called" management messages are simple ClientMessages using well known headers to identify management attributes and operations (+ 1 header to flag the message as a management message). When the message is routed by the PostOffice on the server, we check if it is flagged as a management message. If that's the case, we pass it to the ManagementService. This service will invoke management operations and fetch attributes and put the values in the message. Then the message continues to be routed as any other message. To sum up: - management operations over JBM 2 core API uses JMX semantics - on the server, they're intercepted and processed by the management service, then routed normally - the user workflow is to create a temp queue, create management messages, send them, consume them and process the results The advantage of this implementation is that it is simple and not intrusive. The disadvantage is that the management code will be brittle since a lot is done by reflection: you've to double-check the ObjectNames you use, the attributes spelling, the types required by the management operation. Besides to know what can be done on the management side, you have to look at our MBeans to check the available attributes and operations. I still need to add support for notifications but i'll save that for another post on the dev forum View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172578#4172578 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172578

17 years, 7 months

1
0
0 / 0

[Design of JBoss Deployment Framework] - Re: Persistence unit deployers are not invoked for WEB-INF/l

by alesj

"wolfc" wrote : | I just need something that triggers this deployer. | You could check all WEB-INF/lib jars for it and create something useful. Or create new structure - PersistenceUnitStructure. I'm saying this w/o having any idea what the spec requires. ;-) "wolfc" wrote : | Maybe the WARStructure can fire something off? | Hmmm, could be probably extended. Or new PersistenceUnitStructure, but I dunno how would that play with existing WARStructure --> PUS's deployment ~ WS's classpath entry. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172574#4172574 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172574

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-336; empty string failure

by adrian＠jboss.org

"alex.loubyansky(a)jboss.com" wrote : adrian wrote : Maybe there should be some kind of @JBossXmlValue | | annotation where we can say we want the empty string even for complex types. | | This alone doesn't make sense to me. I.e. the property could always be initialized to an empty string and if there was actual data it would override it. | You could have the case (not this one) where you have a mixed complex type and you want to know the value is "" anonymous wrote : | adrian wrote : I'd suggest an element on the annotation where you say you don't want | | the empty string data if there are child xml elements? | | Yes, I was thinking you needed this one. | | An alternative could be a way to specify the default value (which in your case would be an empty string) in case there is no content. | Except in this case, we don't to apply the default when there are other elements. Do you always have only one child? Or there could be more? It's a mixed type with one optional child that is a choice from a group (like I said before, the cdata and the valueGroup are really mutually exclusive in our case, but you can't say that in xsd :-). | <xsd:complexType name="valueType" mixed="true"> | | <xsd:complexContent> | | <xsd:extension base="plainValueType"> | | <xsd:sequence> | | <xsd:choice minOccurs="0"> | | <xsd:group ref="valueGroup"/> | | </xsd:choice> | | </xsd:sequence> | | </xsd:extension> | | </xsd:complexContent> | | </xsd:complexType> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172571#4172571 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172571

17 years, 7 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-5171 - New metadata - track-connection-by-tx

by jesper.pedersen

Yeah, create a new version called jboss_ds_5_0.dtd like Adrian suggested. That way users wont confuse it with something related to JCA 1.6 and other projects in the AS has used the same naming convention (jboss-service_5_0.dtd and so on). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172570#4172570 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172570

17 years, 7 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-5171 - New metadata - track-connection-by-tx

by alex.loubyansky＠jboss.com

I'd think it makes sense to create a new version of the DTD since if I modify the existing one there could be a document that would be valid according to the DTD in JBoss 5 and invalid according to the same DTD version in the previous JBoss releases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172569#4172569 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172569

17 years, 7 months

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 August 2008