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

[Design of POJO Server] - Re: Relating configuration and monitoring

by scott.stark＠jboss.org

I would just view this as a quality/annotation of the existing ManagedProperty notion. A configuration type of property has: - Realtime, RequriesRestart in terms when it can be applied - The edit information, min, max, allowed values, ... A statistic type of property has: - type, expected range? The management interface of a component should include both configuration and statistics type properties. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012859#4012859 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012859

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Relating configuration and monitoring

by charles.crouch＠jboss.com

I want to use this thread to begin discussion of the issues around how to associate configurable properties with monitorable properties (also I think referred to as runtime properties in previous discussions) e.g. the number of connections from a pool which are currently in use. Right now we have the concept of a ManagedComponent which supports being listed, updated, removed, created and its configurable properties queried. This component represents a user/administrator oriented feature of the app server, for example a Datasource. Its not unreasonable that such components could have monitorable attributes just as they have configurable properties, e.g. An administrator wants to know how many connections this datasource has open to the DB. Given this, some questions arise: 1) If there is a separate object, (call it a MonitoredComponent just to differentiate it) to hold these monitorable attributes then what will be the association between this new object and a ManagedComponent . How will you be able to find the one from the other. 2) Which of the two concepts will be authoritative for determining what is actually deployed to the server? Should one ask for a list of ManagedComponents or a list of MonitoredComponents in order to know how many DataSource's are available? If there is always a one to one mapping then I guess it doesn't matter. 3) Where will these MonitoredComponents be obtained from? Registered in an mbeanserver? Retrieved from some monitoring equivalent of the ProfileService? Before we start trying to answer these questions, lets see if they first make sense and if there are other more fundamental questions which need to be answered. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012825#4012825 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012825

19 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Re: DB test matrix

by prabhat.jha＠jboss.com

The latest run has only 5 failures and all are related to wsrp. So, DB tests are 100%. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012784#4012784 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012784

19 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Text nodes in SOAP messages

by alex.guizar＠jboss.com

The above extract allows me to complete the checklist: SOAP-1.2 Envelope: whitespace only, insignificant Header: whitespace only, insignificant HeaderElement: any character, significant Body: whitespace only, significant BodyElement: any character, significant Fault: whitespace only, insignificant Detail: whitespace only, significant DetailEntry: any character, significant SOAP 1.1 does not explicitly allow or disallow them. The BP 1.2 explicitly disallows DTDs and PIs, but not text nodes. The only source of information on text nodes is the schema. All SOAP-1.1-defined elements have an element-only content type. Considering the validation rules from the XML Schema Part 1 (see below), SOAP-1.1 elements allow text nodes in the same way as their 1.2 counterparts, except that whitespace is always insignificant. anonymous wrote : 3.4.4 Complex Type Definition Validation Rules | [...] | If the {content type} is element-only, then the element information item has no character information item [children] other than those whose [character code] is defined as a white space in [XML 1.0 (Second Edition)]. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012781#4012781 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012781

19 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Text nodes in SOAP messages

by alex.guizar＠jboss.com

In the earlier post I missed the following extract from the SOAP 1.2 spec: anonymous wrote : 5. SOAP Message Construct | [...] | Element information items defined by this specification that only have element information items defined as allowable members of their [children] property can also have zero or more character information item children whose character code is amongst the white space characters as defined by XML 1.0 [XML 1.0]. Unless otherwise indicated, such character information items are considered insignificant. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012750#4012750 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012750

19 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Text nodes in SOAP messages

by alex.guizar＠jboss.com

According to the SOAP 1.2 section you quoted, text nodes are accepted in Body, but only if they are whitespace. The CTS actually adds non-whitespace text to a Body in the 1.2 namespace. SOAP 1.1 does not mention CIIs in Body, but that does not necessarily mean they are disallowed. Comparing the two schemas, neither seems to allow text context, unless it is white space for pretty-printing purposes. The CTS adds non-whitespace text to a Body in the 1.1 namespace as well. SOAP 1.1 Schema <xs:element name="Body" type="tns:Body"/> | <xs:complexType name="Body"> | <xs:sequence> | <xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax"/> | </xs:sequence> | <xs:anyAttribute namespace="##any" processContents="lax"/> | </xs:complexType> SOAP 1.2 Schema <xs:element name="Body" type="tns:Body"/> | <xs:complexType name="Body"> | <xs:sequence> | <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> | </xs:sequence> | <xs:anyAttribute namespace="##other" processContents="lax"/> | </xs:complexType> Do we want to validate that only whitespace text is added? Furthermore, that SOAP 1.2 section specifies that unqualified elements and attributes are invalid. We do not currently check for that. How far do we want to go with validation? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012743#4012743 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012743

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: recursing directories on deployment

by scott.stark＠jboss.org

The JARStructure either recoginizes a jar or it does not. It should not go searching subdirectories for that. If you want that either uses an explicit structure declaration, or add an option to the FileStructure to traverse into directories similar to what we have in the URLDeploymentScanner.RecursiveSearch behavior. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012730#4012730 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012730

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - recursing directories on deployment

by bill.burke＠jboss.com

I'm having a problem where I deploy a directory to the kernel and a .jar in a nested directory isn't getting deployed: foo/lib/deployme.jar I'm created a deployment context with "foo" as the root. The structure code successfully processes the foo/ directory. Mainly because the JARStructure deployer has determined that "foo/" is a top level directory, and so, it must process the children. Now, when lib/ is processed, the JARStructure deployer determines it is neither a "archive" nor a top level directory, so it does not process lib's children. Why do we do this? I can think of one reason. Maybe we don't want to process every single entry of every Jar file? If that doesn't really matter we could move directory processing out of JARStructure and into FileStructure. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012704#4012704 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012704

19 years, 2 months

1
0
0 / 0

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

by weston.price＠jboss.com

The JCA/JMS adatper is *ready* to move from the experimental stage at this point. I wanted this for 4.2. The only real issue at this point is the lack of a management API for the JCA/JMS adapter. It would be easy to dummy something up in the manner of the JMSContainerInvoker allowing for JMX management that simply delegates to the underlying JMSActivation. The only problem I see with this is how to uniquely identify a listener deployment. Current the JMSContainerInvoker uses the listener/jndi name combination. Obviously we don't have this with the adapter and I am not all that sure that this is the right approach. Of course the JBossMessageEndpointFactory could pass this info along in the ActivationSpec, but something just seems wrong with this. Adding fuel to the fire is that there are two JBossMessageEndpointFactories: one for EJB3 and one for EJB2(X) deployments. We should probably combine these two and go with one approach. This is independent of the above issue. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012680#4012680 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012680

19 years, 2 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-1437 RARMetaDataRepository

by weston.price＠jboss.com

anonymous wrote : | If you are doing this in two phases (parse/runtime) it should be automatic? | | The parsing stage populates the repository, the runtime stage (the actual | construction/configuration of the MBeans/Pojos) should have all the parsed rar information | in the repository by then? | No, that's the issue. The ManagedConnectionFactory deployer is being invoked before the RAR deployer, as a result, the ConnectorMetaData hasn't been added to the repository yet. The 'hack' in place right now is to establish the dependency via the ServiceDependencyMetaData. This is basically just emulating the OldRARDeployment mess from the XSL deployer which is what I am trying to move away from. This of course *works* but it suffers from the same failings as the old implementation. Of course, it does actually solve the programmatic part, just the dependencies need to be reconsidered in the context of the MC. I will take a look at the visitor callback. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012676#4012676 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012676

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 February 2007