January 2007 - jboss-dev-forums - Jboss List Archives

[Design of JCA on JBoss] - Re: JBAS-1434 Part 2

by weston.price＠jboss.com

Technically, it would be nice to eliminate the JMSProviderAdapter all together and just extend the JmsActivationSpec to include the necessary information to acquire the connection factory, destination etc. This would eliminate another semi non-portable mechanism. Again, this doesn't solve the auto create destination thing (which again, I think is just a bad idea to begin with), but it would go a long way to making the JMS/JCA adapter more relevant in other environments. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008870#4008870 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008870

17 years, 3 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-1434 Part 2

by adrian＠jboss.org

"weston.price(a)jboss.com" wrote : | Also, as we all know, the old JMSContainerInvoker allowed for creating destinations when a listener was being deployed without one. EJB3 carries this tradition over for EJB3, but for EJB 2.x the JMS/JCA adapter will not. | Its turned off by default in JBoss5 since it is JBossMQ specific. There is a feature request somewhere to allow JCA admin objects to be defined in jboss.xml which would replace this bad feature with something more portable. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008863#4008863 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008863

17 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JGroups configuration for clustering testing

by clebert.suconic＠jboss.com

We don't need to change code for this... just config files. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008858#4008858 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008858

17 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Issues with passivation of nested SFSBs

by bstansberry＠jboss.com

StatefulBeanContext already has a "removed" field, and already has a ref to all its (non @Remote) children. Those children already have a ref to the parent. So it should be quite easy to just change the caching code to not de-cache the parent while any children are alive. Then StatefulInstanceInterceptor just checks the removed field to ensure the parent is no longer accessible (should probably do that anyway). That seems easier than moving data around from one bean to another. It's a quick and dirty improvement, if such a thing is wanted for RC10/4.2. But, a general problem with making XPCs and managed entities part of the replicated state of any SFSB is the possibility of something like this: 1) Parent A has nested children B and C. 2) A exposes getters for B and C, and 3 separate clients have refs to A, B and C. 3) All 3 clients make concurrent requests that result in a need to replicate. This can result in one thread attempting to serialize the bean instances, calls to @PrePassivate, etc. while another thread is actively operating on the bean. Yuck! Encapsulating the shared state in something like an XPCHolder might help with that, if the XPCHolder could be cached and replicated independently of the bean instances. This assumes that one thread serializing the XPC and managed entities while another thread is using them is not a problem. A separate caching infrastructure for XPCHolder would take quite a bit of time, as I'm sure there are hidden gotchas. Another potential workaround to the concurrent replication problem is to modify StatefulInstanceInterceptor to require a lock on the parent bean before an invocation can proceed. Serialize the requests to A, B, C. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008849#4008849 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008849

17 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Web console changes - IMPORTANT

by david.lloyd＠jboss.com

"david.lloyd(a)jboss.com" wrote : | | | <ui:fragment> | | | | This should be: | <ui:component> | | Sorry about the mixup. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008835#4008835 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008835

17 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JGroups configuration for clustering testing

by ovidiu.feodorov＠jboss.com

OK. That's what I saw in the code, too. However, trying to use multiplexer doesn't work, so right now we're resorting to the good old channels. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008832#4008832 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008832

17 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JGroups configuration for clustering testing

by clebert.suconic＠jboss.com

I have done this per Brian's suggestion. If we were running messaging on JBoss 4.0 or 4.2 (not defined yet I guess if we will have or not the multiplexer) we would use regular channels. If jboss-5 -> multiplexer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008817#4008817 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008817

17 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JGroups configuration for clustering testing

by clebert.suconic＠jboss.com

Our services are verifying the existence of multiplexer MBean (configured on the postOffice) ... if available, we use multiplexer, if not we use the config on clustered-mysql-persistence-service.xml (I mean.. .regular channels). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008812#4008812 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008812

17 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Support for Bean Scripting Framework (BSF)

by estaub

I'm planning to implement support for BSF and will contribute it back if it's wanted. (BSF supports pluggable scripting engines and pluggable domain classes.) I'm posting this here, rather than on the forum, to make sure we don't end up with duplicate efforts. If this was the wrong thing to do, apologies in advance. My current plans are to just provide a way to configure a global scripting engine via jbpm.cfg.xml. In the future, it would be desirable to make this settable in the Process Definition. I'll make sure this works with BeanShell and Groovy - other folks will have to vet Rhino, etc. Current estimate is "before end of February". Any thoughts? Requests? Is this useful to others? I haven't seen much about it on the forums. This was originally misposted on JIRA as http://jira.jboss.com/jira/browse/JBPM-830. Tom Baeyens responded there: anonymous wrote : good idea. i mainly would be interested to know how you could enhance the current scripting support to BSF without braking backwards compatibility. | | if this could be done with adding a language attribute to the script tag that has the default value of 'bsh', I'm all ears :-) Backward compatibility is certainly a requirement. As for "how", it superficially looks easy; I'll know more shortly. A <script language="bsh"> attribute sounds good; folks also might want to set a default language in the process definition or even in the config file. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008798#4008798 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008798

17 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Mixing schemas WildcardBinding exception

by alex.loubyansky＠jboss.com

For some reason an extension of the DefaultElementHandler is used for a wildcard. I haven't looked at the schema and initialization yet. But this happens for a repeated wildcard. Have a look at org.jboss.test.xml.AnyComplexTypeUnitTestCase. Maybe it'll give you an idea. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008785#4008785 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008785

17 years, 3 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 January 2007