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

[Design of JBoss jBPM] - Re: Services -changed from List to Set

by camunda

Perfect, thanks! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213870#4213870 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213870

15 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Job.configuration property

by camunda

I think too. But I would keep it and just add a javadoc. It is quite handy if you need to store something together with the Job. And in this case you can just exchange the hibernate mapping in your project... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213868#4213868 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213868

15 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - ExpandableBuffers and HTTP

by clebert.suconic＠jboss.com

Andy: As we talked today: If you change NettyConnection: public MessagingBuffer createBuffer(final int size) | { | + return new ChannelBufferWrapper(org.jboss.netty.buffer.ChannelBuffers.buffer(size)); | - return new ChannelBufferWrapper(org.jboss.netty.buffer.ChannelBuffers.dynamicBuffer(size)); | } | | org.jboss.messaging.tests.integration.http.NettyHttpTest would have a bunch of failures: Exception in thread "pool-3-thread-23" java.lang.ArrayIndexOutOfBoundsException | at org.jboss.netty.buffer.HeapChannelBuffer.setBytes(HeapChannelBuffer.java:130) | at org.jboss.netty.buffer.HeapChannelBuffer.setBytes(HeapChannelBuffer.java:123) | at org.jboss.netty.buffer.AbstractChannelBuffer.writeBytes(AbstractChannelBuffer.java:411) | at org.jboss.netty.buffer.AbstractChannelBuffer.writeBytes(AbstractChannelBuffer.java:406) | at org.jboss.netty.buffer.AbstractChannelBuffer.writeBytes(AbstractChannelBuffer.java:399) | at org.jboss.messaging.integration.transports.netty.HttpAcceptorHandler$ResponseRunner.piggyBackResponses(HttpAcceptorHandler.java:202) | at org.jboss.messaging.integration.transports.netty.HttpAcceptorHandler$ResponseRunner.run(HttpAcceptorHandler.java:181) | at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) | at java.lang.Thread.run(Thread.java:619) | You probably need to call netty.Buffers.dynamic directly instead of using NettyConnection.createBuffer, or maybe we should create another method on Connection for createDynamicBuffer. (I don't know if it would be possible to know the size of the buffer you need, since this will probably using HTTPEncoding) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213867#4213867 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213867

15 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Buffer Refactoring...

by clebert.suconic＠jboss.com

It's been committed now. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213856#4213856 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213856

15 years, 2 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: TCK testcases for JCA spec 10 chapter - WorkManager

by ALRubinger

Hey Jeff: So I see you're using the EmbeddedTestMcBootstrap[1] for the tests. Thought I'd offer some notes: This class is a hacky, simplified view of MC for use in testing only. Very simply, its job is to: * Start up an KC Kernel * Start up the virtual deployment framework * Allow you to deploy MC XML into it (Like the *-jboss-beans.xml format used in AS) * Do installs/lookups into MC Objects that you install via the bootstrap really get installed into MC, and also take advantage of the MC lifecycle callbacks. Any futher questions on its usage, reply here and I'll see what I can do to answer them. S, ALR [1] http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/test/src/main/... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213843#4213843 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213843

15 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Buffer Refactoring...

by clebert.suconic＠jboss.com

I have done these following changes, as part of of MessagingBuffer refactoring, per https://jira.jboss.org/jira/browse/JBMESSAGING-1394 I have stripped down org.jboss.netty.buffer a bit, for what we needed. I'm basically providing three types of buffers that exist on the original netty.buffer: - HeapChannelBuffer - Which is a byte[] backed Buffer - DynamicChannelBuffer - Which is using HeapChannelBuffer, and auto-extending it - ByteBufferBackedChannelBuffer - Which will have a ByteBuffer inside. All these classes are implementing ChannelBuffer and MessagingBuffer. For creating a new buffer, you should use the methods provided by ChannelBuffers: buffer(int capacity) - This method will create a fixed size MessagingBuffer dynamicBuffer(final int estimatedLength) - This method will create a SelfExpandable MessagingBuffer dynamicBuffer(final byte[] initialBuffer) - This method will create a SelfExpandable MessagingBuffer, but reusing the initialBuffer. Be careful though, the reference will be directly used on the createdBuffer. If your buffer will be used by other operations, you should instead create a new buffer and perform a write. buffer(final int capacity) - This method will create a fixed size MessagingBuffer wrappedBuffer(final byte[] array) - It will create a Buffer, with writePosition at the end, and readPosition at 0 wrappedBuffer(final ByteBuffer buffer) - It will wrap a Bytebuffer on a MessagingBuffer. The position on this buffer won't affect the position on the inner buffer We are now using dynamicBuffers on the MessageBody. And in a few places, where we are reading the body, we are wrapping a byte[] on a dynamicBuffer, avoiding this way an extra copy. Also, there is one difference on the old ByteBufferWrapper, and the "new" ByteBufferBackedChannelBuffer. ByteBufferWrapper would aways refer to the positioning inside the ByteBuffer, while the new one will have an independent positioning, and because of that I had to make a few changes on Journal and Paging, as we used ByteBufferWrapper since we need to play with ByteBuffer because NIO and AIO SequentialFiles. I'm writing some of this information on the package.html, and I should commit shortly as soon as I finish some latest tests. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213829#4213829 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213829

15 years, 2 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: TCK testcases for JCA spec 10 chapter - WorkManager

by jesper.pedersen

I don't see a problem of using EasyMock 2.4+ in our test suite, so feel free to include it. I know that you can pull it from a Maven repository like our other dependencies. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213826#4213826 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213826

15 years, 2 months

1
0
0 / 0

[Design of PVM (Process Virtual Machine)] - Re: Me, Myself and Spring Integration

by alex.guizar＠jboss.com

Welcome, Andries! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213821#4213821 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213821

15 years, 2 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: [JBAS-5221] tx-connection-factory/no-tx-connection-facto

by scott.stark＠jboss.org

This looks out of date at this point as the config-property is common across all of the jca deployment types and handled by the custom ConnectionFactoryProperty. I don't see any related failures in the profile service tests. As Emanuel notes, there are some issues with essentially duplicate properties with different names when config-property is an alias for specifying another metadata property. Ideally the config-property would have those specified in a consistent manner as a MapCompositeType, and would incorporate cf specific property descriptions from the rar metadata, but that is another issue. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213820#4213820 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213820

15 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Job.configuration property

by alex.guizar＠jboss.com

No, must be a legacy artifact. It is not persisted, so its value is kinda limited from my point of view. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213819#4213819 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213819

15 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2009