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

[Design of POJO Server] - Handling more complex properties in a ManagedComponent

by bytor99999

So currently there are just Simple ManagedProperty(s) in a ManagedComponent. So for DataSource, properties like jndi-name, and connection-url can easily be handled. However, support for a property like connection properties cannot be handled. Since there can be 0-many connection properties defined in a DataSource, the ManageProperty object might need to have more than one value, and is not currently supported. As an Example, in the Oracle XA datasource in the docs dir has three <xa-datasource-property> tags. the name, attribute is what distinguishes the property. <connection-property> is another tag example. | <xa-datasource-property name="URL">jdbc:oracle:oci8:@tc</xa-datasource-property> | <xa-datasource-property name="User">scott</xa-datasource-property> | <xa-datasource-property name="Password">tiger</xa-datasource-property> | Some other ManagedComponents and Templates might have other similar type of properties. Some might require just a List of Properties, whereas some might require a Map of Properties. So a LoginModule can have many module-options, So if there was a Map for the module-options, the key being the name attribute value, and the value in the Map is the value of that module-option. An example of a List property might be the URIList of the VFSDeploymentScanner. Can this change be made? Mark View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041165#4041165 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041165

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

by weston.price＠jboss.com

Can we have a call about this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041163#4041163 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041163

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

by weston.price＠jboss.com

Can we have a call about this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041162#4041162 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041162

19 years, 2 months

1
0
0 / 0

[Design of OSGi Integration] - Re: OSGi Bundle Repository

by alesj

Whatever makes Maven happy. :-) My point is to keep the core MC modules equal, I don't really care about external source APIs, specially the one's that are there for APIs sake. But I agree with you on the artifacts - it should be as easy as possible to create them - and use/reference them in other MC modules. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041161#4041161 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041161

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

by timfox

"clebert.suconic(a)jboss.com" wrote : "Tim Fox" wrote : But the problem is how to signal that to the session - I can't see how to do that. | | Couldn't we use (sessionState.getListener() instanceof ServerSession) to determine that? | | From my understand from what I just read about JMS Spec Secion 8.6 on Application Server Facilities a ServerSession would be used on that context. I don't think so. Implementing MessageListener on the ServerSession is just how JBoss implements ASF, but it's an implementation detail - not mandated by the spec. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041159#4041159 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041159

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

by clebert.suconic＠jboss.com

I have tested the instanceof ServerSession, and an integration tests where I had a redeliver test (when an exception happened) was failing before the change, and passed after the change. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041151#4041151 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041151

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

by clebert.suconic＠jboss.com

"Tim Fox" wrote : But the problem is how to signal that to the session - I can't see how to do that. Couldn't we use (sessionState.getListener() instanceof ServerSession) to determine that? >From my understand from what I just read about JMS Spec Secion 8.6 on Application Server Facilities a ServerSession would be used on that context. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041150#4041150 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041150

19 years, 2 months

1
0
0 / 0

[Design of OSGi Integration] - Re: OSGi Bundle Repository

by scott.stark＠jboss.org

Having the apis under a varia/src project does not allow for separate artifacts though. You need a maven project source tree per artifact. It would have to be something like: | mc ---> varia | | | |-> osgi-api ---> repository / pom.xml | | | |-> <other apis> / pom.xml | |-> [some]-api / pom.xml | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041148#4041148 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041148

19 years, 2 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: JBREM-63, configuration pojofication

by ron.sigal＠jboss.com

I've made some progress on this issue, so I want to take a minute to describe what I've done. 1. As a first step in the evolution of Remoting configuration, I thougt I would try to minimize the changes, so I've written an XMl schema that describes the current Connector mbean. The only necessary changes are to add a namespace attribute and a serialDataType attribute. So, e.g., | <server> | <mbean code="org.jboss.remoting.transport.Connector" name="jboss.remoting:service=TerranceAndPhillip,transport=bisocket" display-name="TandP"> | | <attribute name="Configuration"> | | <config> | <invoker transport="bisocket"> | ... | <attribute name="timeout" isParam="true">0</attribute> | ... | </invoker> | <handlers> | <handler>...</handler> | </handlers> | </config> | </attribute> | </mbean> | </server> | would become | <server> | <mbean code="org.jboss.remoting.transport.Connector" name="jboss.remoting:service=TerranceAndPhillip,transport=bisocket" display-name="TandP"> | |  | <attribute name="Configuration" | xmlns="http://www.jboss.org/remoting/connector.xsd" | serialDataType="jbxb"> | | <config> | <invoker transport="bisocket"> | ... | <attribute name="timeout" isParam="true">0</attribute> | ... | </invoker> | <handlers> | <handler>...</handler> | </handlers> | </config> | </attribute> | </mbean> | </server> | 2. The schema causes JBossXB to unmarshall the Configuration attribute into an org.jboss.remoting.transport.Configuration object. I've changed the ConnectorMBean.setConfiguration(Element xml) method to ConnectorMBean.setConfiguration(Configuration conf), and left the legacy Connector.setConfiguration(Element xml) method in place, though deprecated. The result is that JBossAS Remoting descriptors will have to be updated, but legacy application code that uses the old version of Connector.setConfiguration() will continue to work. I also have some questions. 1. Does what I've done conform to what JBREM-63 calls for? 2. I've used a "filename" namespace, "http://www.jboss.org/remoting/connector.xsd", which works for org.jboss.xb.binding.sunday.unmarshalling.DefaultSchemaResolver, and I've put the schema in jboss-remoting.jar. Is that OK? 3. anonymous wrote : | Connector object itself seemed superfluous as its just aggregating configuration and parsing | I suppose the goal is to configure the server invokers as independent pojos, but a problem is that server invokers are created by a factory method in org.jboss.remoting.InvokerRegistry, which is called by Connector. In this particular case, I could change things so that server invokers are created by constructors that register the new invoker with InvokerRegistry, but it seems like a general issue, and I'm wondering if there is a general solution. -Ron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041143#4041143 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041143

19 years, 2 months

1
0
0 / 0

[Design of OSGi Integration] - Re: OSGi Bundle Repository

by alesj

"scott.stark(a)jboss.org" wrote : Sounds fine. | I proposed different 'strategy'. I don't like the idea of equal MC modules being at different source levels. So I would keep the current osgi-int and add a new 'varia' module, where I would keep all external APIs: | mc --> varia --> src | --> osgi-api | --> [some]-api | "scott.stark(a)jboss.org" wrote : One thing I saw was that the osgi-int code had explicit dependencies on felix implementation classes. Such code should also be separated from the osgi-int project. That was the initial / old code, in a separate osgi project under jbossas/projects. Not part of MC/OSGi-int. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041137#4041137 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041137

19 years, 2 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 April 2007