December 2006 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Valve on HAAspect

by clebert.suconic＠jboss.com

I have implemented a Valve (class org.jboss.jms.util.Valve) which will prevent two threads to enter in the same block, where the second thread will just ignore the routine. Valve.open will return true only once... and it will wait until the first thread to execute open calls a close. I have implemented this routine into HAAspect::handleConnectionException, however I don't know what to do if two subsequent failures happen, but not at the same time. If two failures happen at the same time the method I added is ok, but if a second failure happens seconds after the method is done, then the method will assume another failover is happening. On that case hpping logic should take care of that. Ok.. I guess I'm drunk and maybe my explanation is too confused. Let me explain through an example: Example I: - Thread A and B, both got an IOException at the same time from ConnectionListener. On this case the valve will ignore one of the exceptions and will perform the client failover in only one exception - Thread A get an exception... - Failover happens - Thread B get an exception after failover on client is done - Failover will be called again, and I'm expecint hopping will be smart enough to ignore the second failover event. if you could please take a look at the code (Ovidiu, Tim, contributors) to verify if the implementation is correct. Maybe you thought about something I didn't think. Cheers, View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993214#3993214 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993214

19 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - MainDeployer changes to reflect deployment structure

by scott.stark＠jboss.org

Rather than simply add a parent notion to the DeploymentUnit, I want to change the notion of a top-level deployment to be a org.jboss.util.graph.Graph and have the deployment unit relationships mirrored in the various views: - Structural deployers produces a Graph rather than a StructureMetaData instance of ContextInfo. - StructureBuilder produces a Graph from the Graph - MainDeployer.process produces a Graph - The management view of a Graph is a Graph - The diff between the base Graph and application of a admin change set in terms of a Graph is a Graph This should really only affect the StructureDeployers, MainDeployer and ProfileService. Deployers would still operate on a DeploymentUnit, and existing usage of the DeploymentUnit.getDeploymentContext.getParent() would simply use the Graph. This would be accessible from the DeploymentUnit. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993209#3993209 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993209

19 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Other IoC containers support

by scott.stark＠jboss.org

It along with many others are already in the jboss5 config of the jbossxb layer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993207#3993207 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993207

19 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: Serialization Compatibility Tests

by ryan.campbell＠jboss.com

Let's go with 1. We really should move the org.jboss.tools classes to the test module, and have jbosscache depend on the test module. But for now, let's just get the test in place. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993191#3993191 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993191

19 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: Serialization Compatibility Tests

by pavel.tsekov＠redhat.com

SearialVersionUID contains mostly copy/paste code. It is possible and even necessary to make it configurable. And I have taken such approach - i.e. reading certain properties which drive it. So, yes, I think SerialVersionUID can be common class between Jboss AS and JBossCache. Anyway, this can be changed at any time ... So how should I proceed for this particular case . View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993188#3993188 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993188

19 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: Serialization Compatibility Tests

by bstansberry＠jboss.com

The tests under tests/compatibility/org/jboss/cache/compatibility sounds fine. The varia part seems odd. That creates a whole new directory structure just for two classes. How about tests/compatibility/org/jboss/tools instead? Also, packaging the 2 classes (I assume we're talking about ClassVersionInfo and SerialVersionUID) under org.jboss.tools is a bit strange. I understand the desire to do that -- it's the same classes as the ones under the AS codebase. But actually, it's not the same classes -- it's a copy. It's not going to automatically be developed/maintained along with the AS version. So, I'd say 1) If it's QA's intent to someday unify this stuff by doing something like putting these classes in the test project where they can be shared by AS and JBC, then leave them in org.jboss.tools. Even if you guys think you might do that someday, go ahead and leave them in org.jboss.tools. 2) Otherwise, they should be packaged in org.jboss.cache.compatibility. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993185#3993185 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993185

19 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: Serialization Compatibility Tests

by pavel.tsekov＠redhat.com

I wan to start adding source files related to the SVUID tests to the source tree. There is this tool that builds a database of SVUIDs called SerialVersionUID. It consist of two source files and I've put them under varia/src/org/jboss/tools/ under the JBossCache root locally. Then there is the test itself which I put under tests/compatibility/org/jboss/cache/compatibility/. Is this acceptable ? If not - please, propose a proper directory structure so I can move forward. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993180#3993180 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993180

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: JACC: Policy Configuration needs to be linked with child

by anil.saldhana＠jboss.com

I have this coded and my final testing with the tck is looking good. I will have this checked in, in few hours. You can review the code then and then give me some feedback. Basically, have a a) central place (JaccPolicy service bean) to create the jacc permissions given the metadata, link the policy configuration to the top-level pc etc. b) security deployer to take care of the service metadata for the Jacc Policy for top-level deployments. c) The component deployers have dependence on the JaccPolicy. Over further iterations, I can get this straight. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993162#3993162 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993162

19 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Other IoC containers support

by alesj

Found the problem. I needed to put xml.xsd into my classpath. So we should do this also in our dist or is this already in? Or you can reference it some other way? --------------------------- <?xml version='1.0'?> <xs:schema targetNamespace="http://www.w3.org/XML/1998/namespace" xmlns:xs="http://www.w3.org/2001/XMLSchema" xml:lang="en"> <xs:annotation> <xs:documentation> See http://www.w3.org/XML/1998/namespace.html and http://www.w3.org/TR/REC-xml for information about this namespace. This schema document describes the XML namespace, in a form suitable for import by other schema documents. Note that local names in this namespace are intended to be defined only by the World Wide Web Consortium or its subgroups. The following names are currently defined in this namespace and should not be used with conflicting semantics by any Working Group, specification, or document instance: base (as an attribute name): denotes an attribute whose value provides a URI to be used as the base for interpreting any relative URIs in the scope of the element on which it appears; its value is inherited. This name is reserved by virtue of its definition in the XML Base specification. id (as an attribute name): denotes an attribute whose value should be interpreted as if declared to be of type ID. The xml:id specification is not yet a W3C Recommendation, but this attribute is included here to facilitate experimentation with the mechanisms it proposes. Note that it is _not_ included in the specialAttrs attribute group. lang (as an attribute name): denotes an attribute whose value is a language code for the natural language of the content of any element; its value is inherited. This name is reserved by virtue of its definition in the XML specification. space (as an attribute name): denotes an attribute whose value is a keyword indicating what whitespace processing discipline is intended for the content of the element; its value is inherited. This name is reserved by virtue of its definition in the XML specification. Father (in any context at all): denotes Jon Bosak, the chair of the original XML Working Group. This name is reserved by the following decision of the W3C XML Plenary and XML Coordination groups: In appreciation for his vision, leadership and dedication the W3C XML Plenary on this 10th day of February, 2000 reserves for Jon Bosak in perpetuity the XML name xml:Father </xs:documentation> </xs:annotation> <xs:annotation> <xs:documentation>This schema defines attributes and an attribute group suitable for use by schemas wishing to allow xml:base, xml:lang, xml:space or xml:id attributes on elements they define. To enable this, such a schema must import this schema for the XML namespace, e.g. as follows: <schema . . .> . . . Subsequently, qualified reference to any of the attributes or the group defined below will have the desired effect, e.g. <type . . .> . . . will define a type which will schema-validate an instance element with any of those attributes</xs:documentation> </xs:annotation> <xs:annotation> <xs:documentation>In keeping with the XML Schema WG's standard versioning policy, this schema document will persist at http://www.w3.org/2005/08/xml.xsd. At the date of issue it can also be found at http://www.w3.org/2001/xml.xsd. The schema document at that URI may however change in the future, in order to remain compatible with the latest version of XML Schema itself, or with the XML namespace itself. In other words, if the XML Schema or XML namespaces change, the version of this document at http://www.w3.org/2001/xml.xsd will change accordingly; the version at http://www.w3.org/2005/08/xml.xsd will not change. </xs:documentation> </xs:annotation> <xs:attribute name="lang"> <xs:annotation> <xs:documentation>Attempting to install the relevant ISO 2- and 3-letter codes as the enumerated possible values is probably never going to be a realistic possibility. See RFC 3066 at http://www.ietf.org/rfc/rfc3066.txt and the IANA registry at http://www.iana.org/assignments/lang-tag-apps.htm for further information. The union allows for the 'un-declaration' of xml:lang with the empty string.</xs:documentation> </xs:annotation> <xs:simpleType> <xs:union memberTypes="xs:language"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value=""/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> </xs:attribute> <xs:attribute name="space"> <xs:simpleType> <xs:restriction base="xs:NCName"> <xs:enumeration value="default"/> <xs:enumeration value="preserve"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="base" type="xs:anyURI"> <xs:annotation> <xs:documentation>See http://www.w3.org/TR/xmlbase/ for information about this attribute.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="id" type="xs:ID"> <xs:annotation> <xs:documentation>See http://www.w3.org/TR/xml-id/ for information about this attribute.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attributeGroup name="specialAttrs"> <xs:attribute ref="xml:base"/> <xs:attribute ref="xml:lang"/> <xs:attribute ref="xml:space"/> </xs:attributeGroup> </xs:schema> View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993134#3993134 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993134

19 years, 4 months

1
0
0 / 0

[Design of Kosmos] - Re: Project Status

by aron.gombas

> If this project's still got life in it, I can help out with a Russian translation. Well, if there's contribution, there's life in it. The decision is yours. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993132#3993132 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993132

19 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 December 2006