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

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Privileged Blocks Issue : JBAOP-675

by anil.saldhana＠jboss.com

Kabir will need to release aop when he comes back on Monday. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191389#4191389 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191389

17 years, 4 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JAX-WS RI 2.1.5/Metro 1.4 Released

by safaq

Hi, When is the jboss metro stack supporting 1.4 scheduled to be released? Or how can we use the metro 1.4 stack with Jboss currently. I'm using Jboss 4.2.3 GA with jboss metro distribution jbossws-metro-3.0.4.GA. Thanks Saniya View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191388#4191388 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191388

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: 1.4.1.GA ready

by anil.saldhana＠jboss.com

Messaging folks, we are waiting for an AOP release which should happen on Monday. Once that happens, please use the aop released version and release messaging. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191387#4191387 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191387

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Register EventListener on JbppmContext

by camunda

Damn it, submitted too early, now in the train (with a bit of fresh air in between) I had two additional thoughts: 1.) I think the single listener would enough. If we want to have something like a dispatcher it can be configured as Listener knowing a list of other listener it notifies. 2.) The EventListener is maybe really not important at the moment. I think the same thing is already supported by hook in an own LoggingService. This LoggingService gets all important events as Log as well, right? Or does anybody already dived deeper into it and knows something which is missing there? So I can extend the LoggingService to serve as EventListener... I think for my purposes at the moment it should be sufficient. I will check that out on Monday morning.... So I think I started an unnecessary discussion, sorry for that! But finally it helped at least me to come to a solution ;-) Keep you posted about how I meet our BAM requirements... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191376#4191376 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191376

17 years, 4 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Privileged Blocks Issue : JBAOP-675

by anil.saldhana＠jboss.com

AOP/Messaging issues are resolved. I will attempt to make an aop release as Kabir has changed release stuff in Branch_2_0 and Flavia is not fully aware of what those changes are . https://jira.jboss.org/jira/browse/JBAOP-678 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191372#4191372 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191372

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Large message code review

by timfox

Here are the results of the large message code review: 1. Need some tests that show pre-commit acks working with large messages 2. Need some tests show in large messages failover. 3. We should use SessionSendMessage for sending both large and normal messages. We should then have a new packet called SessionSendMessageContinuation for sending extra chunks. 4. We should use SessionReceiveMessage for receiving both large and normal messages, with continuations in a different packet. 5. Chunk messages are currently always sent blocking. Instead only the last chunk should be sent blocking, and then, only if sendBlocking = true 6. Replication for large messages needs to be implemented 7. ClientConsumeImpl::handleChunk should be synchronized and have closing check like handleMessage() 8.ClientConsumerImpl shouldn't use instanceof to determine FileMessage, instead use isFileConsiumer() 9.Flow control - for large message flow control should be called before adding adding to buffer APART from last chunk which should have flow control called before consumption, otherwise could flood the buffer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191362#4191362 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191362

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: xml persistent format for attachments

by emuckenhuber

"scott.stark(a)jboss.org" wrote : | I'm not really following. You have the marshalled form of the ManagedObject and build it back up, to apply to the deployment attachment or are you talking about something else? | Basically what i meant is that if we do something like: | ManagedObject mo = managedObjectFactory.createManagedObject(SomeClass.class, null); | ManagedProperty p = result.getProperty("objectName"); | p.setValue(SimpleValueSupport.wrap("jboss:service=Hypersonic,database=profileserviceTestDB")); | | SomeClass object = mo.getAttachment(); | So if SomeClass is properly annotated and we persist actually everything needed, we could use this as predetermined attachment; as those changes are already updated in the metadata model through the WritethroughManagedPropertyImpl. If we want to just update the delta then the ManagedComponent from the ManagementView should actually only contain the changed values. We then would need to merge those changes with the xml (if it already contains some previous values), and apply this during deployment to the metadata itself. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191361#4191361 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191361

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Handling of null native values

by scott.stark＠jboss.org

Yes, its a primitive. It looks like we also know whether the value is a primitive at the TypeInfo layer of reflection, so that is why I'm asking whether this applies to non-managed uses like injecting a null value into a primitive bean property. Maybe that already works but is handled at the a layer above the PropertyInfo.set call? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191359#4191359 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191359

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Handling of null native values

by alesj

"scott.stark(a)jboss.org" wrote : a native valued property | You mean primitive? "scott.stark(a)jboss.org" wrote : | Is this something that the PropertyInfo implementation should be handling, or should this have been handled when the null MetaValue was unwrapped? | I think it could be either one of them. But perhaps better if we put it into SimpleMetaData/Type, since we know there what is primitive and what not. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191355#4191355 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191355

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Register EventListener on JbppmContext

by camunda

Okay, here my proposal. Add to GraphElement: | /** | * notify configured external event listeners of fired event. | * | * The notification is done BEFORE the event gets processed by jbpm | * internally (meaning actions are executed), so it is visible | * to the listeners even if exceptions occur inside of the actions | * causing the stacktrace to abort | */ | private void notifyListenerOfEvent(String eventType, ExecutionContext executionContext) { | EventListenerUtil.notifyListenerOfEvent(eventType, executionContext); | } | and call this method inside of the "fireAndPropagateEvent" method. Now my first thought was, that the EventListenerUtil looks up jbpm.cfg.xnml via JbpmConfiguration to see if there is a bean "jbpm.event.listener" configured, e.g. | <bean name="jbpm.event.listener" class="MyEventListener"> | Or to create some kind of jbpm event dispatcher to support a list of listeners: | <bean name="jbpm.event.dispatcher" class="org.jbpm.NN"> | <field name="listeners"> | <list> | <bean class="MyEventListener1" /> | <bean class="MyEventListener2" /> | </list> | </field> | </bean> | The code isn't hard there, just check in the JbpmConfiguration if the listener is/the listeners are set and if then call the listener. What do you guys think? What would you prefer, simple one listener (so people with multiple listeners have to implement that themselvers) or multiple listeners? This is a really powerfull machnism to hook into jbpm and to develop generic solutions around it, e.g. for BAM.... And it is not a big deal. I would like to start on this next week, hopefully we can come to some conclusions here. When finished I can also blog about how I use this to generate the BAM events we need in the project... Cheers and have a nice weekend Bernd View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191350#4191350 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191350

17 years, 4 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 November 2008