"scott.stark(a)jboss.org" wrote : and I see you updated JSR77SpecUnitTestCase, great.
It's not yet fully enabled.
The component parts - servlets, ejbs, ... - are still disabled.
If we can somehow extract info within those 2 TODOs in AbstractJSR277Deployer,
everything should fall in place.
You mentioned managed view.
Then I guess we would need to add new @JSR77Name annotation to jboss-man?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182921#4182921
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182921
"scott.stark(a)jboss.org" wrote : By just generating the names off of the deployment names, and metadata. It does not need to match or be derived from any mbeans that may be generated by the deployers. There are 3 parts to the jsr77 namespace:
| - hierarchy - that should be known from the deployment + the top level domain
| - module type - known from the metadata
| - component type - known from the metadata
|
I've committed this part.
And it surprisingly works. :-)
See AbstractJSR277Deployer for the missing TODOs,
extracting root and components mbeans / ObjectNames.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182914#4182914
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182914
Ok so I'm implementing it using a queue then theres no change at all to the consumer code. a couple of slight issues are that when i create the new queue i need to copy the references out of the actual queue before allowing the new queue to start receiving messages. Ive added a createQueueCopy method on session to do this. Also since queue browsers don't need the connection(session) to be started I'm adding a flag on consumer to ignore the stopping/starting of the session and start straight away.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182896#4182896
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182896
Committed revision 79633.
I tested it works with JBoss AS trunk rev79434
Btw, I'm seing the following suspicious files in tools/lib:
org.eclipse.jdt.core_3.2.3.v_686_R32x.jar
junit.jar
jdtCompilerAdapter.jar
jbossbuild.jar
pretty.jar
bsf.jar
resolver.jar
I think that these better go to the new lib-ext directory and be included in the required tasks' classpaths. No idea where are these used though. As well if the whole build and test suite get moved to maven eventually, these will go away with it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182890#4182890
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182890
| // Putting back the size on pagingManager, and reverting the counters
|
|
| if (message.incrementReference(message.isDurable() && queue.isDurable()) == 1)
| {
| pagingManager.addSize(message);
| }
|
I don't understand why this code is necessary. Surely paging happens *before* routing.
So any cancellation shouldn't effect any counters. After all, after cancellation it doesn't get paged again, it's still routed.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182889#4182889
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182889